Trust Center
Where sigill.ai runs, how evidence is produced, which independent authorities anchor it, and what our proofs can and cannot establish.
Trust model
sigill.ai is evidence infrastructure for digital records, and is structured as a hub. For proof of time, we relay requests to independent Timestamp Authorities under RFC 3161 and return their signed tokens — we do not run a TSA ourselves and have no plans to. For proof of organisational origin, we produce PAdES seals for PDFs and CAdES detached signatures for non-PDF files, bound to an X.509 certificate for an organisation, issued by an external Certificate Authority — either the customer's own certificate (BYOC) or the Sigill Platform Seal certificate for platform-issued artefacts. The cryptographic trust rests on those external authorities, never on sigill.ai alone. Timestamps are verified against the issuing TSA; electronic seals are verified against the sealing certificate and its issuing CA chain — independently, and without contacting Sigill.
A Sigill Platform Seal proves that the artefact was sealed or issued through the Sigill platform. It does not represent the customer's organisation and does not prove that the customer authored or approved the artefact. Customer seals require a customer-owned certificate (BYOC).
Data handling
For timestamping, verification, and CAdES sealing, only a SHA hash crosses the network — the file stays on your machine. PAdES sealing is the single exception: a PDF must be uploaded so the signature can be embedded inside it. Sigill is not a document store. The unsigned PDF input and the sealed PDF output are processed in memory and streamed back in the HTTP response — neither is persisted. What Sigill keeps on your behalf is the file's hash and a small metadata row; optionally, the RFC 3161 timestamp token and the CAdES detached .p7s signature, governed by per-tenant settings. PAdES sealed PDFs are never retained.
The single narrow exception is the Model Context Protocol (MCP) server. Because MCP tool responses cannot carry binary content, MCP-mediated uploads and sealed downloads transit through temporary server-side slots in eu-north-1 with a hard one-hour expiry and a 50 MB upload cap. The slots are scoped to the originating tenant and deleted automatically.
Hosting and sub-processors
sigill.ai's primary application data plane runs in AWS eu-north-1, Stockholm. Customer evidence records, signing keys, audit logs, and database backups are hosted in that region. Limited account, billing, identity, and contact-form metadata may be processed by sub-processors outside that region — see the sub-processors page for the full list.
Standards and verification
sigill.ai implements published IETF and ETSI standards rather than proprietary cryptographic schemes — principally RFC 3161 (timestamps), RFC 5126 / ETSI EN 319 122-1 (CAdES), ETSI EN 319 142-1 (PAdES), and the eIDAS Regulation for qualified services. Every timestamp we relay and every seal we produce can be verified independently with standard tools such as openssl ts -verify, Adobe Acrobat Reader, or the eIDAS DSS demo validator. See standards and verification model.
Key management
Signing keys are held in AWS KMS. Private-key material is non-extractable: it never appears in memory or on disk outside the KMS HSM boundary. Customers can also bring their own certificate, with the corresponding key generated and held in a tenant-scoped KMS key that only their tenant can sign with. Detail is in security architecture.
Tenant isolation
sigill.ai is multi-tenant. Tenant isolation is enforced through database-resolved authorization, ORM-level tenant filters, and DTO-level capability boundaries. A valid token establishes identity; authorization is resolved against the database on every protected request rather than trusting role claims embedded in the token. Detail in security architecture.
Compliance posture
We state what is in place, partially in place, and planned. Marketing-grade phrasing is intentionally avoided.
Full statement at compliance posture.
What we can prove — and what we cannot
A cryptographic proof is only useful if its scope is stated honestly. sigill.ai makes specific, narrow claims. Marketing-grade phrasing like "tamper-proof documents" is intentionally avoided.
sigill.ai can prove
- That a specific byte-exact file existed by a specific moment in time, anchored to an independent Timestamp Authority's signing key.
- That a sealed PDF or detached CAdES signature was produced using a specific organisational certificate, and that the file bytes have not changed since.
- That a qualified-timestamp proof was issued by a TSA listed on the EU LOTL at the time of issuance.
- That a given hash was observed by sigill.ai at a given time (account-scoped, via the tenant audit log).
sigill.ai cannot prove
- That the contents of the file are factually true — only that they existed and have not changed.
- Who authored the file. A timestamp anchors a hash to a time, not to a human identity.
- That a file is "the original." Two parties may stamp identical bytes; both stamps are valid.
- The absence of a prior version. We can prove existence-by; we cannot prove non-existence-before.
- That a sealed PDF was approved by every individual mentioned inside it — a seal binds the document to the issuing organisation, not to its content's signatories.
Incident contact
Security issues, suspected key compromise, or suspected cross-tenant access: security@sigill.ai. Privacy and GDPR queries: contact@sigill.ai. See responsible disclosure for scope and expected response times.
Read more
Document history
| Version | Date | Change |
|---|---|---|
| v1.0 | 2026-05-23 | Initial Trust Center publication. |
Changes that affect a contractual statement, sub-processor list, or stated control will be announced to active customers by email at least 30 days before they take effect.