Security

This page explains how Sill keeps your data and your customers’ payments safe, and what you can check for yourself. In short:

Everything Sill publishes about your site, and every decision it records, is signed with ed25519, and anyone can verify the signatures with public keys.
Decisions are written to an append-only, tamper-evident audit log.
Sill never holds money and never sees card numbers; your payment processor does.
Each merchant’s data is kept separate from every other merchant’s.
You sign in with a magic link; there are no passwords.

For an overview, see sill.so/security.

Signatures you can verify

What is signed	How	Public key
Your agent card and catalog trust manifest	Card: ed25519 signature in `signing.envelope_signature`. Trust manifest: detached JWS, `alg: EdDSA` (RFC 7515, RFC 8037)	`https://edge.sill.so/.well-known/jwks.json`
Every audit record and every exported audit bundle	ed25519 signature over the record	`https://sill.so/.well-known/sill-audit-envelope-v1.pub`

Signed JSON is first put into a standard byte form with RFC 8785 (JCS), so any implementation produces the same bytes. To verify a signature you need only the public key, a JCS library and an ed25519 library (for example @noble/ed25519, pynacl, tweetnacl or OpenSSL) — no Sill account or software. See Verify a signature, or drop an exported bundle into the hosted verifier, which runs in your browser and uploads nothing.

What each signature covers

Signed item	Covered	Not covered
Agent card	The card: `protocol_version`, `skills[]`, `capabilities`	Whether each skill answers right now — the card describes, it does not test
Catalog	The trust manifest (who publishes the catalog)	Each entry’s `url`, `capabilities` and `description`, which rely on `did:web` and TLS
Audit record	The whole record except its signature and `merkle_root`	`merkle_root`, which is added when the day’s batch closes
Audit bundle	The bundle body	Nothing extra — a full check also re-verifies each record and recomputes the batch roots

A tamper-evident audit log

Every decision Sill makes is written to the audit log as a signed record. Each record includes the hash of the record before it, and each day’s records for a site are combined into a Merkle root.

flowchart LR
  A[Decision] --> B[Signed record<br/>linked to the previous one]
  B --> C[Daily Merkle root<br/>per site]
  C --> D[Exported bundle<br/>anyone can verify]

Changing, removing or reordering a record breaks its signature, the link from the next record, or the day’s root, so the change is detectable. Discovery and transactional decisions are kept in separate chains for each site, so a record cannot be moved from one chain or site to another. The record format and the step-by-step check are in Audit envelope.

Sill never holds money

Sill decides whether an order may go ahead, signs that decision and records it. Your payment processor (Stripe) holds the card, charges it, settles and pays you out. No money passes through an account Sill controls.

sequenceDiagram
  participant A as Agent
  participant S as Sill
  participant P as Stripe
  participant M as Your bank account

  A->>S: Signed mandate
  S->>S: Evaluate your policy
  S->>P: Charge the saved payment method
  P-->>S: Charge result
  S->>S: Write a signed audit record
  P->>M: Settlement and payout

See Payments.

No card numbers

Sill handles only payment tokens issued by your processor (Stripe pm_…, tok_… and Shared Payment Token references). Card numbers, expiry dates and security codes never enter Sill; they stay with Stripe. An automated check on every change to Sill’s code rejects anything that looks like card data.

This keeps Sill’s own exposure to card data small. It is not a PCI certification: Sill holds no PCI attestation, Report on Compliance or Self-Assessment Questionnaire. See Compliance.

Merchant data is kept separate

Every merchant account and every site has its own ID, and every request is checked against it:

Public routes (/v1/agent-card/{site_key}.json, /v1/catalog/{site_key}.json, /v1/mcp/{site_key}) find the site from the key in the URL before reading any data.
Dashboard requests only return data that belongs to the signed-in account.
Stripe and Shopify credentials are stored per account and looked up from the account making the request, never from anything the caller sends.
Audit chains are separate per site, so one site’s records cannot be inserted into another’s.

Signing in

You sign in with a single-use link sent to your email address. There are no passwords to steal or reset.

One sign-in covers app.sill.so and sill.so. The session cookie is Secure, HttpOnly and SameSite=Lax.
Single sign-on (SSO) is not available.

How Sill runs

Region. Sill runs in the US East region. You cannot choose another region.
Signing keys. Signing keys are kept in a managed key store. The agent card and catalog use one key; audit records and bundles use another.
Backups. The database has point-in-time recovery over a 7-day window, plus a nightly backup that is encrypted before it leaves the backup job and stored with a different provider for 35 days. The decryption key is kept offline. Restores are tested every quarter.
Access. Only authorized staff can reach production, and every infrastructure account requires multi-factor authentication.
Deploys. A new version of the API must pass health checks before it receives traffic.
Incidents. If a confirmed security incident affects you, Sill notifies you without undue delay and within 72 hours of confirming it.

Sill does not publish uptime or latency figures.

Data retention and deletion

Audit log. Kept for the life of your account. It is designed to hold no personal data; people are referred to by opaque IDs.

Returning visitors. When a site has returning visitors turned on, each visitor’s page history and IP addresses are kept for 13 months after their last visit, then deleted. IP addresses are stored encrypted. An owner or admin can forget a visitor at any time.

Operational logs (notification, catalog-sync and invite logs, test history) are kept for about 90 days, and red-team results for 365 days, then removed.

Deleting your account. An account owner can request deletion from the dashboard and confirms it with a single-use code sent to their email. Your sites go offline and every session is signed out straight away. For 30 days you can cancel by signing back in. After that, the account is deleted: personal data — team members, connector credentials, buyer details, contact information — is erased, and the audit records are kept in anonymized form so the chain stays verifiable. Erased data leaves the encrypted backups within their 35-day rotation. See Deleting your account.

Report a vulnerability

Email [email protected] with steps to reproduce and the affected part of Sill (an endpoint, a dashboard page, an export format). Contact details are also at sill.so/.well-known/security.txt (RFC 9116).

Frequently asked

How do I check a Sill signature without trusting Sill? Fetch the public key, canonicalize the signed JSON with RFC 8785 (JCS) and verify the ed25519 signature with any standard library. Step by step: Verify a signature.

Can an audit record be changed or deleted? Not without detection. Each record is signed, linked to the previous record by prev_record_hash, and included in a daily Merkle root; any change breaks at least one of these. The only value added later is the record’s merkle_root, which is outside the signature.

Does Sill see card numbers? No. Sill handles only processor tokens such as Stripe pm_… and tok_….

Is Sill PCI, SOC 2 or ISO 27001 certified? No. Sill publishes framework mappings, which are not certifications, and will not claim a certification until an accredited audit is complete. The mappings cover the OWASP Top 10 for Agentic Applications 2026 (v1.0), the OWASP Top 10 for LLM Applications 2026 and MITRE ATLAS 2026.09. See Compliance.

Where is my data? In the US East region.