Changelog
A curated changelog of notable changes to Sill’s public, agent-facing surfaces: the embed script, the per-site signed agent card, the per-site MCP server, the per-site signed ARD catalog, the public JWKS, and the verifier recipe. Entries are listed newest-first and reflect only what is shipped and independently verifiable today.
Dated entries use ISO-8601 dates (UTC). Where a date is not known with confidence, the entry is grouped under its phase without a date rather than inventing one.
How this changelog is scoped
Section titled “How this changelog is scoped”This page tracks changes that affect external, agent-facing surfaces. It is not a commit log. It does not list internal refactors, dashboard-only changes, or unreleased work.
For protocol posture at a glance, see Protocols.
Surfaces tracked
Section titled “Surfaces tracked”| Surface | Endpoint pattern |
|---|---|
| Embed script | <script> install on the merchant page |
| Agent card | https://edge.sill.so/v1/agent-card/{site_key}.json |
| MCP server | POST https://edge.sill.so/v1/mcp/{site_key} |
| ARD catalog | https://edge.sill.so/v1/catalog/{site_key}.json |
| Public JWKS | https://edge.sill.so/.well-known/jwks.json |
2026-06-19 — Public JWKS endpoint
Section titled “2026-06-19 — Public JWKS endpoint”Sill began publishing the ed25519 signing key used for the agent card and the ARD trust manifest at a public JWKS endpoint. The endpoint serves application/jwk-set+json, includes Cache-Control: public, max-age=300, sets CORS *, and exposes the key as:
{ "keys": [ { "kty": "OKP", "crv": "Ed25519", "alg": "EdDSA", "use": "sig", "kid": "foyer/edge/card-signing-v1", "x": "<base64url public key>" } ]}With this endpoint in place, any third party can verify a Sill-signed manifest end-to-end using only an off-the-shelf RFC 8785 JSON Canonicalization Scheme implementation and an RFC 8032 / RFC 8037 ed25519 verifier — no Sill SDK, no Sill account, no Sill code involved. See Verify a signature for the recipe.
2026-06-19 — ARD ai-catalog.json (signed catalog) live
Section titled “2026-06-19 — ARD ai-catalog.json (signed catalog) live”Sill began publishing a per-site signed ARD ai-catalog.json at the edge. The catalog declares specVersion: 1.0 and sets host.identity to a did:web identifier derived from the verified site domain. Each trustManifest carries a compact, detached JWS (EdDSA / ed25519) over the RFC 8785 JCS-canonicalized manifest, and the signing key is published at the public JWKS for independent verification.
Scope, bounded honestly: the signature attests the trust manifest (identity + provenance). The per-entry url / capabilities / description fields are not inside the signed payload; their integrity rests on did:web + TLS per the ARD specification. The content-binding extension remains deferred.
Phase 1 — Discovery (shipped, live)
Section titled “Phase 1 — Discovery (shipped, live)”The following surfaces shipped during Phase 1. Where the ship date is not recorded here with confidence, the entry is grouped under the phase rather than dated.
Per-site MCP server
Section titled “Per-site MCP server”A Streamable-HTTP Model Context Protocol server runs at the edge per verified site 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 backing-filtered set the agent card advertises — and records tools/call invocations to the audit envelope.
Scope, bounded honestly:
- MCP server responses are not themselves signed; only the agent-card pointer to the MCP endpoint is signed. See MCP server for the deliberate scope.
- Skill invocation is conditional. Connector-wired skills dispatch through the connector layer. Skills without a wired backing fall back to discovery / observe-only. Money-movement skills require a signed mandate and are gated to Phase 2.
Per-site signed agent card (A2A-compatible)
Section titled “Per-site signed agent card (A2A-compatible)”Sill publishes a per-site A2A-compatible agent card at https://edge.sill.so/v1/agent-card/{site_key}.json, with protocol_version: "a2a/1.2", A2A-conformant skills[], and transport-flag capabilities. Each card is signed with an ed25519 envelope using the foyer/edge/card-signing-v1 key and is independently verifiable against the public JWKS. Advertised skills[] are backing-filtered against what the site actually exposes (no overclaim).
Embed script v1
Section titled “Embed script v1”A one-line embed script identifies agent traffic at the merchant page and beacons the interaction to Sill’s edge, against a seeded identity registry that includes known agents (Anthropic, OpenAI, Google, and others). The script is the install surface for Discovery; there is no platform-specific plugin requirement.
The canonical snippet:
<!-- paste before </body> --><script async src="https://cdn.sill.so/embed.js" data-site-key="sk_…" data-proof-token="pf_…"></script>The data-proof-token is a per-site, opaque value. The embed runtime does not read or transmit it; the attribute exists only so Sill’s origin can server-fetch the merchant’s published HTML and confirm the snippet is present — an anti-spoofing ownership proof tied to domain control.
Identity registry, seeded
Section titled “Identity registry, seeded”The edge maintains an identity registry seeded with public agent identities used by major providers. Agent classification is the basis for both the audit record and any subsequent policy decision.
Signed audit envelope + HTML bundle export
Section titled “Signed audit envelope + HTML bundle export”The audit envelope is an append-only, signed, Merkle-chained record of governed actions. Records are signed with ed25519 (base64url-encoded). Exportable as a server-rendered HTML bundle for handoff to auditors.
Dashboard + onboarding (Discovery)
Section titled “Dashboard + onboarding (Discovery)”The dashboard ships sites overview, add-site, onboarding, audit log, and bundle export. Sign-in is via magic link.
Dashboard sites overview after a site has been verified — dark theme, default.
Marketing site
Section titled “Marketing site”The marketing site is live at sill.so.
Cross-subdomain session posture
Section titled “Cross-subdomain session posture”Dashboard (app.sill.so) and marketing (sill.so) share session via a .sill.so cookie.
Phase 2 — Transactional core (live in limited production)
Section titled “Phase 2 — Transactional core (live in limited production)”The Transactional pipeline — signed mandate → policy evaluation → Stripe payment authorization → signed, Merkle-chained audit record — has been validated end-to-end on the live Stripe rail in production.
2026-06-19 — Stripe live-mode cut-over
Section titled “2026-06-19 — Stripe live-mode cut-over”The Stripe live-mode cut-over was taken on 2026-06-19. Subsequent end-to-end validation: six live-mode Stripe charges cleared and were refunded through the mandate → policy → Stripe-authorize → signed-audit pipeline on a single Sill-controlled live merchant account.
Phase 2 surfaces (shipped earlier in Phase 2)
Section titled “Phase 2 surfaces (shipped earlier in Phase 2)”- Signed mandates — canonical mandate envelope and verification.
- Policy engine — versioned, ordered rules with a DSL evaluator.
- Transactional endpoint — mandate ingestion at the edge.
- Stripe outbound rail — Stripe authorization against merchant-saved opaque payment-method tokens.
- Human-in-the-loop — escalation and resolution flow for
on_fail: escalaterule outcomes. - Refunds — Stripe and Shopify refund paths.
Frequently asked
Section titled “Frequently asked”Is this a complete release history?
Section titled “Is this a complete release history?”No. This is a curated changelog of changes to Sill’s public, agent-facing surfaces. Dashboard-only changes, internal refactors, and unreleased work are out of scope.
Why are some entries undated?
Section titled “Why are some entries undated?”Sill is still establishing its public release rhythm. Where a precise ship date is not recorded with confidence, the entry is grouped under its phase rather than carrying a fabricated date. New entries from here on are dated.
Where do I find what a signature actually covers?
Section titled “Where do I find what a signature actually covers?”See Verify a signature. The page describes the JCS + JWS-detached recipe and is explicit about which payload fields are inside the signed envelope and which are not.
How do I know a Sill-signed manifest is genuine?
Section titled “How do I know a Sill-signed manifest is genuine?”Fetch the public JWKS, pick the key whose kid matches the JWS protected header, canonicalize the manifest with RFC 8785, reconstruct the JWS signing input, and verify the ed25519 signature with any reputable library. The recipe and a minimal verifier sketch are at Verify a signature.
Where is the roadmap?
Section titled “Where is the roadmap?”This changelog does not publish dated roadmap promises. For the current posture of each protocol at the boundary — what is live and what is roadmap — see Protocols.