Security
Last updated: 15 September 2026
Our security commitment
Security is not a feature we add. It is the reason this product exists. For configured pre-call policies, the gateway decides before the model call. The response includes a signed record of Seal's outcome and applied policies. This page documents the controls we apply to our own infrastructure.
Checked before it acts. Offline check against a pinned key.
Seal leaves one signed file for each consequential AI decision: a model call in the cloud, an edge deployment, or a physical decision stream (Act II lab; not a shipping robot product). Same file for your team, counsel, and auditors.
A reviewer opens that file offline, on an air-gapped machine if needed, and checks it against our published key. The receipt stands without a network call. Change one signed field and the signature dies.
Engineers can run the open verifier
The greenest AI call is the one that never runs, and a refused call is one you can evidence. How we keep the signed refusal apart from the modelled carbon estimate: Green AI.
Three properties a signed record can be asked to prove, worked through on a real production receipt. Authenticity is solved, correctness is partial, and completeness is open. Break each one yourself: What a signature cannot prove.
How the receipt fields function as agent identity primitives (which agent acted, under whose authority, within what constraints): Receipt identity. Act II vision for the same primitive at the edge: Physical AI receipts (not a shipping robot product). Run Seal in front of a local model today: Sovereign edge demo (Docker Compose + Ollama; foreign cloud optional).
For regulated buyers
A vendor's own log is evidence written by the party being questioned, and that review is where deals stall. Since January 2025, DORA has made EU financial entities ask ICT third parties harder questions about what their models did, and those questions land on exactly that log. DORA does not ask for cryptographic evidence. Seal answers the question anyway.
Seal clears the model into that review with one signed file of what it decided, checkable offline against the published key. Attach it to a filing pack for counsel or audit, or refuse with a precise hole. Evidence for audit and regulatory review. Not a certification. Not a claim that a court must accept it.
When the record cannot be checked, someone pays. Horizon and the Dutch childcare-benefits cases both turned on automated systems whose operators could not produce an independent check of what the system decided.
Sources: Post Office Horizon Inquiry · Dutch childcare-benefits inquiry · Signed receipt · Sovereign edge
1. Data architecture
We do not store prompt content or model responses. The gateway inspects requests in transit to enforce configured policies (PHI detection, loop detection, spend limits) and immediately discards the content. Only metadata is retained.
- Prompts and responses are processed in transit and not persisted; only one-way hashes and signed metadata are retained, per your retention tier
- Metadata retained: timestamps, model names, token counts, policy outcomes, costs
- Seal maintains an internal per-organisation hash chain that the authenticated dashboard checks during review
- Optional advanced proving modes, when enabled for a workflow, are in preview and are not required for receipt verification
2. Encryption
- TLS 1.3 for all traffic in transit
- AES-256 for data at rest
- Receipts use an open signed format (ATTESTATION-v1); ink is Ed25519
- SHA-256 internal hash chaining for dashboard sequence integrity
- Optional advanced proving modes in preview; not required for receipt checks
3. Infrastructure
- EU-hosted: gateway and database on Google Cloud in Belgium, website functions in Dublin; encryption at rest and in transit
- Production signing keys are loaded only in the gateway environment
- Permanent blocks expire after 24h, no indefinite NAT lockouts
- Fail-closed rate limiting by default when cache is unavailable
- Per-tenant isolation: all keys scoped to organisation ID
4. Authentication & access
- OAuth 2.0 (Google, Microsoft, Auth0/SSO) with provider ID verification
- OTP via email, no passwords stored
- Cross-tenant access is enforced with organisation-scoped queries
- API keys hashed at rest, never logged in plaintext
- SSO available for enterprise deployments
5. Evidence coverage
- EU AI Act: signed records support Article 12 and Article 14 evidence work; the export includes directional Articles 9-15 mapping
- GDPR: EU-hosted option and data-minimisation controls; customers remain responsible for their own legal assessment
- HIPAA: PHI detection and no prompt-or-response persistence in the Health pack; a Business Associate Agreement is subject to engagement
- DORA, MiFID II, NIS2 and SR 11-7: FinServ policies and signed exports can support pilot evidence review
- ISO/IEC 42001: design alignment only; Aqta is not certified
- NIST AI RMF: risk-mapping crosswalk available under NDA on enterprise engagement
Framework references
| Framework | Scope | Status |
|---|---|---|
| EU AI Act | All tiers | Evidence for Arts. 12 and 14; mapping supports review |
| GDPR | All tiers | Data-minimisation controls; customer obligations remain theirs |
| HIPAA | Health pack | PHI features; BAA subject to engagement |
| ISO/IEC 42001 | All tiers | Roadmap |
| NIST AI RMF | All tiers | Crosswalk available under NDA |
| DORA · MiFID II · NIS2 · SR 11-7 | FinServ pack | Evidence features for pilot review |
6. Vulnerability disclosure
We welcome responsible disclosure of security vulnerabilities. If you believe you have found a security issue, please contact us before disclosing publicly so we can investigate and remediate.
Contact: security@aqta.ai with subject "Security disclosure".
7. Contact
For security enquiries: security@aqta.ai
Aqta, Dublin, Ireland