Troubleshooting

The most common Sill problems, grouped by symptom, with the cause and the fix. For the overall state of an install, start with Settings → Install → How Sill is installed: it shows which layers are live and the one next step.

Discovery: agent traffic isn’t showing up

You installed the embed but the dashboard shows no agent activity.

The site isn’t verified yet. Sill starts recording once the domain is verified. Complete domain verification first.
The script isn’t in the served HTML. View the page source of the live page (not the browser’s element inspector) and confirm the snippet is present in the response before </body>. The canonical install snippet is:
```

<script async src="https://cdn.sill.so/embed.js"
        data-site-key="us_…"
        data-proof-token="pf_…"></script>
```
A tag added by a tag manager can count visits, but domain verification only sees a snippet that is in the HTML your server sends.
A Content-Security-Policy is blocking it. If your site sends a CSP header, add https://cdn.sill.so to script-src and https://edge.sill.so to connect-src (the script sends its page view there).
Wrong site key. The data-site-key must match the site in your dashboard. Re-copy it from Settings → Install.
The visitor wasn’t a recognized agent. Discovery matches inbound traffic against a list of known agents (Anthropic, OpenAI, Google and others). Ordinary human traffic and unrecognized clients are not logged as identified agents — that is expected.
A firewall is blocking crawlers. If you see WAF is blocking AI agent crawlers, or Agent readiness reads AI crawlers get 403 Forbidden., your firewall or bot protection is turning crawlers away. See Let AI crawlers through your firewall.
Crawlers never show up. The embed script only sees visitors that run JavaScript; most AI crawlers do not. To see them, install the Cloudflare Worker or the WordPress plugin. For a script-tag site, also add an agent card redirect.

Your site key is public by design, like a Stripe publishable key; seeing it in your page source is expected.

Domain verification fails

The site stays unverified after you click Verify.

The snippet isn’t in the page Sill fetches. Sill fetches your homepage, as an anonymous visitor would, and looks for your data-proof-token value. The snippet must be in the HTML your server sends; a tag added later by a tag manager or other JavaScript is not seen. Paste the snippet exactly as copied, including its data- attributes.
The homepage did not return 200. A login wall, geo-block, firewall or timeout stops the check. Make sure the homepage loads for an anonymous visitor.
The site redirects to another host. Sill checks the exact domain you registered. A redirect between example.com and www.example.com is followed once; any other redirect fails. Register the domain your site actually serves, or serve the domain you registered.
Use the file instead. If the snippet can’t go on the homepage, serve the token at /.well-known/sill-proof.txt. The Cloudflare Worker and the WordPress plugin do this for you.
The WordPress plugin is active but /.well-known/sill-proof.txt shows your theme’s 404 page. The plugin registers its paths when it is activated. If a caching or permalink plugin still serves the old URL rules, go to Settings → Permalinks in WordPress, click Save Changes without changing anything, clear your page cache, then click Verify again. See Install Sill on WordPress.
The Cloudflare Worker deploy failed. A successful deploy verifies the domain. If you see Token invalid — check it has the required permissions. or This token is valid, but this domain isn’t in your Cloudflare account., see Install the Sill Cloudflare Worker.

See Domain verification.

The agent card URL returns 404

The body of the 404 tells you why:

{"status":"pending_verification",…} — Sill knows the site, but the domain is not verified yet. Finish verification; the card goes live within about a minute.
{"error":"not_found"} — Sill does not recognize the key in the URL. Copy the card URL again from Settings → Install → Endpoint → Agent card.

A mandate was rejected or escalated

Every mandate response has an outcome field; rejected responses also have a reason. The full list is in the rejection reasons.

Response	Cause	Fix
`rejected`, `signature_invalid` (`401`)	The signature does not match the agent’s registered key.	See Signature verification fails below; sign the exact canonical bytes.
`rejected`, `identity_check_failed` (`401`)	The agent or key is not registered or was revoked, the protocol value is not `a2a`, `ap2` or `mcp`, or the mandate names a different site.	Check the agent’s registration, the `protocol_context.protocol` value and the `site_key` in the URL. Your audit log shows the specific reason.
`rejected`, `replay` (`403`)	The mandate was already used.	Sign a new mandate for every action.
`rejected`, `expired` (`403`)	The mandate’s validity window has passed.	Sign a new mandate and send it promptly.
`rejected`, a rule ID (`403`)	One of your guardrails rejected the order.	Expected. Open the record in the dashboard to see which rule fired.
`escalated` (`202`)	A guardrail sent the order to human review.	Expected. Approve or reject it in the review queue; nothing is charged until then.
`rate_limited` (`429`)	Too many mandates for this site.	Wait `retry_after_seconds` and retry.
`unavailable` (`503`)	Sill could not complete its checks, so nothing was approved.	Retry later.

Signature verification fails (your verifier)

If your own code can’t verify a Sill-signed agent card or ARD catalog, the cause is almost always canonicalization:

You used JSON.stringify instead of JCS. The signing input is canonicalized with RFC 8785 (JCS). A plain serialize reorders keys and changes whitespace, so the bytes — and the signature — won’t match. Use a real JCS library.
You didn’t reconstruct the detached payload (catalog). A trust manifest’s JWS is in detached form: the payload is omitted from the compact string and must be rebuilt from the manifest. An agent card has no JWS; its raw signature is in signing.envelope_signature, over the card without that field. See the verifier recipe.
Wrong key. Match the card’s signing.signing_key_id, or the JWS header kid for a trust manifest, to the matching key in the public JWKS (kty: OKP, crv: Ed25519).
Test with a changed payload. Change one character and verify again; it must fail. If it still passes, your code is not checking the payload. See the negative-control test.

MCP requests behave unexpectedly

Calls appear in the audit log. Every tools/call to your MCP server is recorded there.
rate_limited errors. Too many calls in one session return rate_limited with retry_after_seconds. Wait that long, then retry.

Still stuck?

Email [email protected] with your site’s domain, the approximate time, and for mandates the outcome, reason and mandate_id from the response. Never send private signing keys or card details.