Protocols at the boundary

Sill speaks several agent-facing protocols at its edge. This page is the authoritative public status of each one: which are wired in the production verifier today, which are on the roadmap, and which signed surfaces back them. “Live” means there is a shipped adapter behind the protocol that the production verifier admits; “roadmap” means there is not.

Status at a glance

Protocol	Status	Scope today	Spec
A2A — Google Agent-to-Agent	Live	Signed per-site agent card published at the edge; advertised skills are filtered against what the site actually exposes.	a2aproject.org / a2a-project on GitHub
AP2 — Google Agent Payments Protocol	Live (boundary)	Mandate path consumes `protocol_context` (`cart_total`, `cart_currency`); a full standalone adapter is a follow-up.	ap2-protocol.org
MCP — Anthropic Model Context Protocol	Live	Per-site Streamable-HTTP MCP server at the edge (`initialize` + `tools/list` + audited `tools/call`). MCP responses themselves are not signed.	modelcontextprotocol.io
ARD — Agentic Resource Discovery	Live	Per-site signed `ai-catalog.json` (specVersion 1.0); trust manifest signed with detached ed25519 JWS; identity via `did:web`.	did-web method
ACP — Stripe agentic commerce	Roadmap (built, gated on Stripe preview)	Sill governs Stripe’s agentic checkout via the order-approval hook; Stripe owns token mint + redemption. See Agentic checkout.	Stripe agentic commerce
UCP — Universal Commerce Protocol	Roadmap (designed)	Not in the edge allowlist until a verifier + adapter ship.	Universal Commerce Protocol (UCP)
x402 — Coinbase / Cloudflare on-chain HTTP-native payments	Roadmap (deferred)	No code; not in the edge allowlist.	x402.org

The “Live” rows are exactly the three values the production edge admits today: a2a, ap2, mcp. A mandate signed with any other protocol value is rejected by the verifier as protocol_unsupported. ARD is “live” in the sense that the signed catalog endpoint is in production, but ARD is a discovery surface — it is not a mandate protocol and does not appear in the mandate allowlist.

How the boundary is gated

The edge mandate engine runs the same verifier + policy + enqueue pipeline regardless of ingress (the canonical POST /v1/m/{site_key}/mandate, or MCP tools/call on place_order). At verify time, the verifier checks the mandate’s protocol_context.protocol against a small protocol allowlist. A protocol is in the set if and only if there is a shipped inbound adapter behind it.

flowchart LR
  A[Agent submits mandate] --> B{Protocol in allowlist?}
  B -->|a2a / ap2 / mcp| C[Verify ed25519 signature]
  B -->|other| D[Reject: protocol_unsupported]
  C --> E[Evaluate policy]
  E --> F[Enqueue signed audit draft]

The fail-closed posture is deliberate: an unwired protocol is rejected, not silently trusted. Adding a protocol means landing its adapter and adding its identifier to the allowlist in the same change.

Live protocols

A2A — Agent-to-Agent

Sill publishes a per-verified-site, A2A-compatible agent card at:

GET https://edge.sill.so/v1/agent-card/{site_key}.json

The card uses protocol_version: "a2a/1.2", lists A2A-conformant skills[], and carries transport-flag capabilities. Advertised skills are filtered against what the site actually exposes — Sill does not overclaim. Each card is signed with an ed25519 envelope; the signing key is published at Sill’s public JWKS so any third party can verify the card without Sill in the loop. See Agent card and Verify a signature.

At the mandate layer, agents that have read the card can sign mandates with protocol_context.protocol: "a2a"; the edge verifier accepts them.

AP2 — Agent Payments Protocol

AP2 (Google’s mandate format) is consumed today at the policy layer. Mandates with protocol_context.protocol: "ap2" and an AP2-shaped protocol_context (cart_total, cart_currency) flow through the live Stripe rail (and the Shopify rail in test mode); the policy engine’s per-cart and per-currency rules read those fields directly.

A full standalone AP2 adapter — separating AP2-specific shape validation from the shared mandate pipeline — is a follow-up. The protocol value itself is admitted and consumed in production. See Signed mandates and the Policy engine for how mandate fields are evaluated.

MCP — Model Context Protocol

Sill runs a per-verified-site Streamable-HTTP MCP server at:

POST https://edge.sill.so/v1/mcp/{site_key}

It implements initialize and tools/list (exposing the site’s backed skills as MCP tools — the same set the agent card advertises) and records tools/call invocations in the signed audit log. Connector-wired skills dispatch through Sill’s connector layer; money-movement skills (for example, place_order) require a signed mandate and run the same verifier + policy + audit pipeline as the canonical mandate endpoint.

Scope, honestly bounded:

MCP server responses are not signed. Only the agent-card pointer to the MCP endpoint is signed.
Skill invocation is conditional. Skills without a wired backing fall back to observe-only; money-movement skills are gated to the signed-mandate path.

See MCP server and Discovery skills.

ARD — Agentic Resource Discovery

Sill publishes a per-site signed ai-catalog.json at:

GET https://edge.sill.so/v1/catalog/{site_key}.json

The catalog is specVersion 1.0, with host.identity = did:web:{domain} (did:web method). Each trustManifest carries a compact detached ed25519 JWS (alg: EdDSA, per RFC 8037) over the RFC 8785 (JCS) canonical manifest. The signing key is at Sill’s public JWKS.

What the signature attests is the trust manifest — host identity and provenance. Per-entry url, capabilities, and description fields are not inside the signed payload; their integrity rests on did:web + TLS per the ARD specification. A reader cannot infer A2A or MCP readiness from the ARD signature alone — they must verify each surface independently.

See ARD catalog and Verify a signature.

Roadmap protocols

ACP — Stripe agentic commerce

Sill’s ACP integration is the seller-side governance of Stripe’s agentic commerce: when an AI agent checks out through Stripe, Stripe calls Sill’s order-approval hook before charging, and Sill records a signed identity-and-intent trail after. Stripe owns the Shared Payment Token — minting and redemption both; Sill never holds or redeems it. The full flow (three-party model, SPT lifecycle, the 4-second budget, the post-charge enrichment) is documented in Agentic checkout (Stripe ACP).

The ACP order-approval handler is in design (ADR-0139, status: proposed); the implementation slice is unmerged and security review is outstanding. No merchant has ACP enabled. See Agentic checkout (Stripe ACP) for the intended design.

UCP — Universal Commerce Protocol

Designed but not wired. The previous placeholder entry was removed from the edge allowlist because there was no adapter behind it; readmission requires landing the verifier path and the shape mapper as separate changes.

x402 — On-chain HTTP-native payments

Deferred. No code, not even a type placeholder. Readmission would require a real on-chain adapter and a decision to take that scope on.

Common questions

Which protocol values does the edge admit today?

a2a, ap2, and mcp. Any other value is rejected as protocol_unsupported.

What happens if an agent submits a mandate with a protocol value not in the allowlist?

The verifier returns protocol_unsupported. At the agent-facing surface this is coalesced into identity_check_failed (anti-fingerprinting); the granular reason is persisted in the sanitized rejection draft in the merchant’s audit log.

Is the agent card endpoint the same as A2A?

A2A is the protocol; the agent card is the per-site signed JSON that publishes a site’s capabilities in an A2A-compatible shape. The card lives at https://edge.sill.so/v1/agent-card/{site_key}.json and can be verified against the public JWKS using only standard tooling.

Are MCP responses signed?

No. MCP responses themselves are not signed — that was a deliberate scope choice. Only the agent-card pointer to the MCP endpoint is signed. Mandates that flow through tools/call (for example, place_order) are signed mandates and are verified the same way as mandates submitted to the canonical endpoint.

How does Sill add a new protocol?

Support for a new protocol ships as an inbound adapter (verifier path plus shape validators) together with a matching dashboard registry update, so the capability grid always reflects what the edge actually enforces.