When a regulated website needs an agent interface—and when it does not

Begin with the task

An interface is justified by a supported task, not by the desire to display a protocol logo. Public methodology retrieval, current capability discovery, and evidence-document lookup are bounded examples. A website with static informational pages may already meet those needs through ordinary HTTPS and clear links.

Describe authority separately

A protocol connection does not confer permission to use every business capability. A public read-only surface should not expose customer records, credentials, payments, order mutations, confidential pilot records, or eligibility decisions. For age-restricted commerce, this observatory’s interfaces remain informational; they do not provide an automated purchasing path.

Reuse the same underlying contract

MCP and A2A are interfaces with their own specifications, not competing definitions of the business. We recommend that human pages, JSON discovery, and any supported protocol resolve to the same authoritative capability descriptions. Differences in transport should not produce different claims about authority, pricing, or state.

Source: Model Context Protocol specification · A2A protocol specification

Bound remote retrieval

A diagnostic that fetches user-supplied URLs introduces security concerns independent of its public interface. Use an existing hardened scanner instead of creating a second unrestricted proxy. Host validation, redirect revalidation, public-network restrictions, timeouts, response-size limits, and explicit failure outcomes belong in the retrieval layer.

Source: OWASP: server-side request forgery

Write a stopping rule

Before implementation, specify the cases in which the agent must stop: authentication required, eligibility unknown, unsupported operation, rate limit, ambiguous evidence, or unavailable service. A clear limitation is a successful contract outcome. A client that works around the boundary is not demonstrating better interoperability.