Site owners — GAA-enable a door

Let governed agents act through your site without widening what anyone may do on it.

Only the specification is normative; this page is a reading order. The seam you are implementing is §9 (Site-Integration): a governed door is an endpoint that admits agents under their Principal's granted authority, refuses everything else, and leaves a verifiable record.

1 · Publish a discovery descriptor

The descriptor is how an agent finds your door and learns its shape before anything acts. Per GAA-SITE-1, a site advertises "GAA-enabled" via a discovery descriptor — the OpenID Connect .well-known analogue — naming its door endpoint, the verbs and scopes it accepts, the required authority shapes, its seal/verify endpoint, and its human/agent co-presence policy. The same clause states the ground rule for the door itself: it is deny-by-default.

Two related items ride the proposal track rather than the specification text today, and are recorded honestly as proposals: the six-field machine-readable descriptor schema (GAP-2) and the explicit data-appetite declaration (GAP-3).

2 · Require the authority presentation

An arriving agent does not present an identity and get a session; it presents its authority. Per GAA-SITE-2, the agent shows the scope of authority relevant to your site — granted verbs, counterparty and resource limits, the 2-axis limits, the escalation rule — and a verifiable reference to its Mandate, never the grant secret. Your door checks the presentation against what it published in step 1 and refuses anything outside it.

3 · Seal every interaction

Per GAA-SITE-3, every action through the door is a sealed interaction: decision → action → site response is hash-chain-sealed, a receipt is minted, and the interaction re-derives from the sealed record alone via a public verify endpoint. Your visitors — and yours alone, no third party's say-so — can then check what an agent did on your site.

4 · Declare your scope and classes

Conformance is scoped to the verbs you declare (§12). GAA-CORE-1 requires an implementation to express the Principal, the Mandate, the agent's class, and — for any multi-party interaction — Governed Mediation. GAA-CLASS-1 requires a conforming implementation to treat the agent-class registry as extensible, and says it SHOULD declare each agent's class. Say which sections you implement; do not imply the ones you do not.

5 · State your posture honestly

Two requirements carry the register's honesty into your copy: GAA-POST-1 — an implementation MUST NOT present demonstration or simulated results as production results, and MUST NOT call anything "proven" that is only mechanism-proven; GAA-POST-2 — where a control is detective (tamper-evident) rather than preventive, an implementation MUST say so and MUST NOT label it otherwise. And on the boundary that outlives every incident write-up: GAA-SEC-1 — conformance governs authority at the governed seam and MUST NOT be presented as sandboxing, kernel hardening, or infrastructure egress control.

6 · Claiming conformance

Conformance is by honest self-attestation against the published criteria; GAA-CONF-1 — an implementer MUST NOT state or imply that the steward has certified, tested, endorsed, or approved a product. Name the version and sections you conform to — by requirement ID, which survives renumbering.

Informative example

The founder's reference implementation realizes this seam as a live mechanism (its products remain demonstrations). It is one implementer among equals: naming it here is informative only, and per GAA-CTRL-8 any conforming implementation MAY realize a control differently.