Verification model
What crosses the network, what stays on your machine, and how anyone can verify a sigill.ai proof without sigill.ai in the loop.
Data minimisation by protocol
RFC 3161 §2.4 is explicit: a Timestamp Authority must not examine the imprint being time-stamped in any way other than to check its length. sigill.ai honours this at every layer. For timestamping and verification, only a SHA hash crosses the network — the file itself never reaches our servers.
CAdES and JAdES sealing are hash-only — only the SHA-256 digest is sent; the original file never reaches our servers. PAdES sealing has two modes: the delegated SDK mode assembles the signature on the customer's machine and transmits only the ByteRange digest — the PDF never reaches Sigill — while the upload mode (used by the web app) transmits the PDF so the signature can be embedded server-side. Uploaded PAdES requests are processed in-memory and the sealed PDF is streamed back in the HTTP response — Sigill does not write the unsigned input or the sealed PDF to durable storage. What Sigill keeps is the file's hash and a small metadata row; optionally, the RFC 3161 timestamp token and (for detached seals only) the detached .p7s (CAdES) or .jades.json (JAdES) signature, governed by per-tenant settings. PAdES sealed PDFs are never retained.
AI-agent runs follow the same rule. The SDKs and the Sigill plugin for Claude Code and Codex hash every prompt, tool argument, result and model output on the customer's machine and send only digests for sealing. To list runs in the Evidence Store, the producer then uploads the signed envelope of each step — step type, tool name, times, agent and run identifiers and the object digests — never the content. Sigill accepts an envelope only if it matches a seal the customer's own organisation made, with exactly the signature Sigill issued, and its read views return identifiers and digests only, not free-text fields of the envelope. Uploading is the producer's choice and can be switched off.
Sub-agents are recorded as runs of their own (Agent Delegation v1): the parent's signed step declares the sub-agent before it starts, the sub-agent's first step binds that declaration, and the parent's signed result binds the sub-agent's final step. A run tree is only reported as finalized when every run in it is finalized and every such link holds in both directions; a withheld, swapped or edited sub-agent run makes the tree invalid. Trees are assembled from your organisation's records only. As with any run, a finalized tree proves that what was recorded is intact — not that every sub-agent the system started was recorded.
The Model Context Protocol (MCP) server is hash-only as well: its tools take and return digests, timestamp tokens, detached signatures and short text such as labels and tags. It has no document upload or download capability in either direction, so PAdES sealing, which needs the PDF, is available through the SDKs (delegated mode) and the web app, not over MCP.
Two classes of request
What goes through sigill.ai
- Timestamp request — hex digest in, RFC 3161 token out
- Timestamp verification — hex digest plus token in, verdict out
- Timestamp inspection — token in, parsed metadata out
- Hash lookup — boolean answer only
- CAdES / JAdES sealing (
/seal/sign-hash) — SHA-256 digest in, detached.p7s(CAdES) or.jades.json(JAdES) out; original file never leaves the client
The file never reaches our servers. Timestamp verification can also be run entirely offline with openssl ts -verify.
The upload paths
- PAdES upload sealing (
/seal/sign, used by the web app) — PDF bytes in, signed PDF out with the signature embedded. The delegated SDK mode (/seal/sign-pades-hash) avoids the upload entirely: the signature is assembled on the customer's machine and only the ByteRange digest is transmitted. - Full-file seal verification (
/seal/verify) — original file plus.p7s(CAdES) or.jades.json(JAdES) in, or sealed PDF in (PAdES), verdict out. Hash-based verification (/seal/verify-hash) needs no file for the detached formats.
On the upload paths, both the input and the output are processed in-memory and streamed back — Sigill does not retain the file bytes.
Independent verification
Every proof returned by sigill.ai is independently verifiable. Timestamps are verified against the TSA that signed the token; electronic seals are verified against the sealing certificate and its issuing CA chain. The third-party tools we cross-check against, and that any recipient of a sigill.ai proof can use, include:
- RFC 3161 timestamps —
openssl ts -verify -in token.tsr -data file -CAfile ca-bundle.pem - PAdES-sealed PDFs — Adobe Acrobat Reader displays the signature panel and validates the embedded timestamp natively
- CAdES detached signatures — any CAdES-aware verifier, or the eIDAS DSS demo validator below
- JAdES detached signatures — any JAdES/JWS-aware verifier, or the eIDAS DSS demo validator below
- Qualified RFC 3161 timestamps — the eIDAS DSS demo validator resolves the signing certificate against the EU LOTL and produces a qualified verdict for the timestamp. For seals, Sigill produces advanced electronic seals (AdES); validators such as DSS may classify a seal more highly when a customer brings a qualified certificate for electronic seal (BYOC) — a path Sigill has not validated end-to-end. A QESeal additionally requires a QSCD and is not offered by Sigill today.
If a proof returned by sigill.ai fails to validate in one of these tools and you can reproduce the failure, treat it as a bug and write to security@sigill.ai.
Retention of TSR tokens
Whether sigill.ai stores the bytes of an issued timestamp token alongside its hash is a per-tenant setting. With token storage enabled, the tenant can re-download the original token from the evidence ledger. With token storage disabled, only the digest, the metadata, and the issuing TSA are retained — the tenant is responsible for archiving the token bytes themselves. The setting is itself audited.