Back to homepage

Agent Access for business websites

Make your website accessible to AI agents – with clear control

Agent Access combines better discoverability with clear boundaries: content is published in a structured way, known actions stay limited, and every inquiry can be reviewed visibly by a person.

Book an initial consultationSee the visitor perspective

Agent Access is a controlled publication layer

A business website already contains valuable information. Agent Access makes that information easier for supported AI assistants to discover and use without turning the website into an uncontrolled agent endpoint.

Content, allowed actions, and form data are treated separately. The published catalog remains traceable, remote access is read-only, and prepared inquiries still require visible human review.

Four control points for a dependable agent access layer

01

Better discoverability

A shared page catalog, structured content, and discovery hints help assistants place relevant offerings in context.

02

Known actions

Browser agents receive only explicitly defined navigation and preparation actions.

03

Read-only by default

External clients can read published content; writes, submits, and arbitrary cross-origin actions are not part of the surface.

04

Visible responsibility

Validation, time and size limits, and human review keep the final decision with the right people.

A pragmatic rollout path

Agent Access starts with published content and grows only where value, ownership, and control fit together.

  1. 01

    Organize content

    Relevant pages, offers, and next steps are described in a dependable, localized catalog.

    Illustrative example · Publish selected pagestypescript
    async function publishSelectedPages() {  const catalog = defineAgentCatalog({    locale: "en",    pages: ["/wissen", "/agent-access", "/rag-architektur"],  });  await publication.validate(catalog);  return catalog;}
  2. 02

    Bound access

    Browser actions, read-only content, and form preparation are released separately and validated.

    Illustrative example · Bound allowed actionstypescript
    function defineBoundedAccess() {  const access = {    read: ["catalog", "page", "section"],    prepare: ["contact-draft"],    write: [],  } as const;  policy.assertAllowed(access);  return access;}
  3. 03

    Test with control

    Schema, runtime, origin, and output controls are checked with real browser and API flows.

    Illustrative example · Require human reviewtypescript
    async function requireHumanReview(preparedDraft: unknown) {  const validation = await request.validate(preparedDraft);  const review = await humanReview.request(validation);  return {    readyForManualSubmission: review.approved,    submitted: false,  };}
  4. 04

    Observe the effect

    The publication evolves from concrete visitor questions and qualified inquiries, not unsupported ranking promises.

01

One shared publication catalog

The sitemap, llms.txt, WebMCP, and read-only remote resources use the same typed catalog for public page information. Titles, locales, sections, and available actions therefore stay aligned.

  • German and English variants are maintained as separate, real publications.
  • Discovery hints provide guidance, not a guarantee of ranking, indexing, or citation.

02

Three controlled agent surfaces

WebMCP supports defined actions in the active browser. An optional Remote MCP surface remains read-only. AI Discovery adds structured hints for systems that search and interpret content.

  • Same-origin navigation and known tool names bound browser access.
  • A disabled remote surface is not advertised as available.

03

Reversible preparation instead of submission

Contact, checklist, and Academy forms can be prepared visibly for a smoother user experience. The action triggers no submit, sends no webhook, and requires human review before transmission.

  • Abort, timeout, unmount, or validation failure rolls prepared values back.
  • Personal data is not returned as a tool result.

04

Operational and rollout boundaries

Schema projection, input and output validation, execution budgets, origin checks, and size limits are part of the access layer. Normal website operation remains independent of it.

  • Experimental browser support is feature-detected and replaceable.
  • The v1 surface uses bounded, traceable controls instead of additional distributed infrastructure.

Further perspectives

Agent Access overviewReturn to the shared entry point for both audiences.All AI GuidesPlace the technical guides in context.Agent Access for visitorsUnderstand concrete use cases and visible boundaries.Safe AI agentsGo deeper into controlled agent workflows and explicit stops.RAG architecturePlace knowledge access and data quality in the wider architecture.

Questions decision-makers ask

Is Remote MCP automatically public?

No. The read-only Remote MCP surface is an explicit operational choice. When disabled, it is neither published as available nor advertised through discovery.

Can an agent run arbitrary website actions?

No. Browser agents receive only known, explicitly published actions. Remote reading and browser actions are separate surfaces with separate boundaries.

How are contact inquiries protected?

An agent action may prepare visible fields but cannot submit them. Consent and human review remain required; failed or aborted preparation is rolled back.

Do we need to run a new platform for Agent Access?

The v1 architecture uses the existing website catalog and bounded, best-effort runtime controls. New distributed infrastructure is considered only after demonstrated need.

Does Agent Access guarantee more visibility in AI systems?

No. Structured publication and discovery make content easier for supported systems to interpret, but do not guarantee discovery, indexing, citation, or placement.

Find the right starting point for your website

Together, we can clarify which content, actions, and control boundaries fit your offering and operating model.

Book an initial consultationRead the visitor perspective