Protocols at the boundary

Sill speaks several agent-facing protocols at the edge. This page is the authoritative status of each one — which are wired in the production verifier today, which are roadmap, and which signed surfaces back them. The goal is honesty: an “active” protocol here means there is a shipped adapter behind it that the production verifier admits; a “roadmap” protocol means it is not.

The canonical source for this status is the edge’s protocol allowlist in apps/edge/src/mandate/pipeline.ts (the PROTOCOL_ALLOWLIST constant) and the dashboard’s protocol registry in apps/dashboard/src/config/protocols.ts. This page mirrors them.

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 backing-filtered.	a2aproject.org / a2a-project on GitHub
AP2 — Google Agent Payments Protocol	Live (boundary)	Mandate path consumes `protocol_context` (`cart_total`, `cart_currency`); full adapter formalization 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 Shared Payment Tokens	Roadmap (built, dormant)	Adapter merged behind a default-off flag; verifier rejects `acp` mandates as `protocol_unsupported` unless the flag is enabled.	Stripe Shared Payment Tokens
UCP — Universal Commerce Protocol	Roadmap (designed)	Removed from the edge allowlist until a verifier + adapter ship.	the 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 ReadonlySet<string> — the 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 / Shopify rails; 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 Shared Payment Tokens

The ACP adapter is built and merged but dormant. The vault, executor, escalation lifecycle, and the flag-gated acp enable are all on main. The edge admits acp only when the environment flag ACP_PROTOCOL_ENABLED is the exact string 'true'. Default unset / wrong-value leaves acp out of the allowlist and the verifier rejects with protocol_unsupported (the same fail-closed posture as the live-Stripe master switch).

Enabling ACP in production is a founder-gated operational decision. ACP charges against Stripe-minted Shared Payment Tokens; the live-token-sourcing flow between Sill and Stripe’s agentic-commerce surface is the remaining gate, not OpenAI’s discontinued ChatGPT Instant Checkout channel. SPT acceptance via Stripe is self-serve and persists independently of any agent-app marketplace.

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 C1 mapper as separate changes.

x402 — On-chain HTTP-native payments

Deferred. No code in the repo, 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. The acp value is admitted only when the ACP_PROTOCOL_ENABLED flag is set to the exact string 'true'. Any other value — including unset, '1', 'TRUE', 'yes', or garbage — leaves acp out and the verifier rejects.

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 do I add a new protocol?

Land an inbound adapter (verifier path, shape validators, any rule-side fields), add the protocol identifier to PROTOCOL_ALLOWLIST in apps/edge/src/mandate/pipeline.ts, and update the dashboard registry in apps/dashboard/src/config/protocols.ts in the same change so the capability grid reflects the new state.