Skip to content

Developer FAQ

Short answers to the questions developers ask most. To fix a specific problem, see Troubleshooting.

Sill sits in front of your existing store and payment stack and answers three questions about every AI agent that interacts with it: identity (who the agent is), intent (what it is allowed to do) and proof (a signed, exportable record of what happened). Sill never holds funds.

No. You install Sill with a script tag, the Cloudflare Worker, the WordPress plugin or the Shopify app; nothing goes into your code bundle. To verify signatures, any RFC 8785 (JCS) and ed25519 library works.

MCP, A2A (agent card), AP2, UCP checkout and Web Bot Auth are live, along with the signed catalog, llms.txt and the /agent page. ACP is built but not enabled; x402 is deferred. See Supported agent protocols for the details of each.

The canonical embed snippet is:

<!-- paste before </body> -->
<script async src="https://cdn.sill.so/embed.js"
data-site-key="us_…"
data-proof-token="pf_…"></script>

data-site-key identifies your site. data-proof-token proves you control the domain: Sill fetches your homepage and looks for it. The script itself never reads or sends the token. Both values are public once the snippet is on your site.

No. The site key is a public credential — it ships in every visitor’s page source, the same way a Stripe publishable key does. Seeing it in your HTML is not a leak. It identifies your site; it does not authorize sensitive actions.

How do I verify that a Sill signature is genuine?

Section titled “How do I verify that a Sill signature is genuine?”

For an agent card or catalog: fetch the public JWKS, canonicalize the signed JSON with RFC 8785 (JCS) and verify the ed25519 signature (the card’s signing.envelope_signature, or the trust manifest’s detached JWS) against the key with the matching kid. For audit bundles, use the hosted verifier or the recipe in Verify a signature.

No. Sill is a hosted service. You install it on your site and, for orders, connect your own payment processor.

No. Sill handles only payment tokens from your processor (for example Stripe pm_… and tok_…); card numbers never enter Sill. This is a design property, not a PCI certification. See Security.

The US East region. You cannot choose another region. Sill does not publish latency or uptime figures.

Yes. The mandate endpoint returns HTTP 429 with outcome: rate_limited and retry_after_seconds when a site sends too many mandates. The MCP server returns a rate_limited error with retry_after_seconds when one session makes too many calls. Wait the given time, then retry.

What’s the difference between Discovery and Transactional?

Section titled “What’s the difference between Discovery and Transactional?”

Discovery identifies and logs the agents that visit your site and publishes files agents can read. It never authorizes payments. Transactional (early access) adds signed mandates, the policy engine, human-in-the-loop escalation, and payment authorization on your processor, validated end-to-end on the live Stripe rail.

How do AI agents discover what my site offers?

Section titled “How do AI agents discover what my site offers?”

Through what Sill publishes for each site: the signed agent card, the MCP server (tools/list), the signed catalog, llms.txt and the /agent page. The agent card and catalog can be verified against the public JWKS; MCP responses are not signed.

It is held for human review (outcome: escalated, HTTP 202), and nothing is charged until a reviewer approves it. Your guardrails decide which orders go to review.

Can I use Sill’s framework mappings in my own audit?

Section titled “Can I use Sill’s framework mappings in my own audit?”

Sill publishes mappings to the OWASP Top 10 for Agentic Applications, the OWASP LLM Top 10, MITRE ATLAS and NIST AI RMF. They are mappings, not certifications, and Sill holds no security certification. They can inform your own assessment; they do not replace an accredited audit.