Trust & safety

Security

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.

Last updated 14 October 2026

Checked before it acts. Offline check against a pinned key.

Seal leaves one signed file for each consequential AI decision that passes through it: a model call, or an agent's tool action. 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.

Open specification

ATTESTATION-v1

Open envelope · Apache-2.0

Published verifying key

9Y3Eiq6V8QjRDUM5nPqSwKIOPQaoEU4SbagfYFdvWa4

Ed25519 · 32-byte public key · in use since 2026-08-09

Receipts issued before then are signed by a previous key, listed at issuer-keys.txt. Retired keys are never withdrawn: a receipt must stay checkable for as long as the decision it records matters.

Engineers can run the open verifier

# Python

on PyPI ↗

pip install aqta-verify-receipt

# save as check.py; sample: curl -sO https://app.aqta.ai/samples/sample-receipt.json
import json
from aqta_verify_receipt import verify_receipt

receipt = json.load(open('sample-receipt.json'))
key = '9Y3Eiq6V8QjRDUM5nPqSwKIOPQaoEU4SbagfYFdvWa4'  # published key
print(verify_receipt(receipt, trusted_public_key=key).valid)  # True

# TypeScript / Node

on npm ↗

npm install aqta-verify-receipt

// save as check.mjs; sample: curl -sO https://app.aqta.ai/samples/sample-receipt.json
import { readFileSync } from 'node:fs'
import { verifyReceipt } from 'aqta-verify-receipt'

const receipt = JSON.parse(readFileSync('sample-receipt.json', 'utf8'))
const key = '9Y3Eiq6V8QjRDUM5nPqSwKIOPQaoEU4SbagfYFdvWa4' // published key
console.log(verifyReceipt(receipt, { trustedPublicKey: key }).valid) // true

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.

Controls verified in the 14 Oct 2026 release

Gateway release of 14 October 2026; 718 gateway tests passed at release. Each control is stated with its scope and how it was tested. These are the controls this release verified, not a claim that every risk is covered.

Exact approvals

ScopeAn approval (a grant) can fix exact argument values, such as payee account, amount and currency. Seal refuses any call whose values differ, and the refusal does not use up the approval. Applies to tools under a grant rule in your policy.

How tested86 automated gateway tests: matching and mismatched values, an amount spelled differently, a number where a string was fixed, a missing value, an edited grant, and use counting after a refusal.

Human decisions need a person

ScopeAgent API keys cannot approve, countersign or submit a review. Those routes accept only a signed-in person.

How testedAutomated tests that an API key is refused on each approval, countersign and review route, and still works on ordinary routes.

Verified sign-in

ScopeAdmin rights need an email address the identity provider has verified. A returning account links by the provider’s own account identifier, not by email alone, and an unverified address never creates an account.

How testedAutomated tests for each case, and an end-to-end sign-in on the live console after release.

SSO domain proof

ScopeA new single sign-on domain stays pending until a DNS TXT record proves control of it.

How testedAutomated tests for pending, proven, already held and malformed domains.

Secrets

ScopeService credentials are held in a cloud secret manager rather than in plain configuration, and the secret shared between the console and the gateway was rotated in this release.

How testedChecked on the live service configuration after deployment; console calls confirmed working after rotation.

Signed refusals

ScopeA refused action is signed in the same format as an allowed one, and the record names the rules applied.

How testedRefusals are checked offline with the published verifier; changing one field makes the check fail.

Offline verification

ScopeAny record can be checked against the published key without contacting Aqta.

How testedTwo published verifiers, TypeScript and Python, run the same conformance vectors and must reach the same verdict.

Public log

ScopeHashes of signed records are appended to a public log. No decision content is published.

How testedAnyone can check inclusion and consistency proofs; release tests check that proofs and the signed head describe the same tree.

Boundaries

What a record proves

That its signed fields have not changed since Seal signed them, under the key it names.
Which rules Seal applied and the outcome, allowed or refused, at the time it states.

What it does not prove

That the caller then ran exactly what it declared, unless Seal performed the action itself. The record holds a hash of the arguments, not the arguments.
That the decision was right, or that the rules were the right rules for the workflow.
That an approver was entitled to approve, or that a key was held by the person you expect.

Fail-closed integration

The action check is designed so the caller runs an action only after Seal answers ALLOWED. In the recommended integration, an error or no answer from Seal means the action does not run. On its side, Seal issues no ALLOWED without a signed, stored record; a decision it cannot sign is not issued.

What Seal cannot see

Seal cannot see actions that never asked it. An agent with another route to a tool leaves no record of using it, so the check belongs in the code path that performs the action. The public log makes it harder to remove a record after it was signed; it cannot show a request that was never made.

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

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 then discards the content.

Kept: signed records, a one-way fingerprint of each request, operational metadata (timestamps, model names, token counts, policy outcomes, costs, and the calling IP address and user agent), and for agent sessions the intent the agent declared
Operational metadata is deleted per your retention tier; signed records are not deleted automatically, and their hashes are leaves in the public transparency log (see the privacy policy)
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 for all traffic in transit
AES-256 for data at rest
Receipts use an open signed format (ATTESTATION-v1), signed with 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
Rate-limit blocks lift within 24 hours, so a shared address is never locked out indefinitely
Rate limits are held in memory, per instance, when no shared cache is configured
Per-tenant isolation: all keys scoped to organisation ID

4. Authentication & access

OAuth 2.0 sign-in; admin rights need a provider-verified email, and accounts link by the provider’s account identifier
OTP via email, no passwords stored
Cross-tenant access is enforced with organisation-scoped queries
API keys hashed at rest
Enterprise SSO on request

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 26-2: FinServ policies and signed exports can support pilot evidence review
ISO/IEC 42001: design alignment only; Aqta is not certified

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
DORA · MiFID II · NIS2 · SR 26-2	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 Technologies Limited, 20 Harcourt Street, Dublin 2, D02 H364, Ireland

Now taking pilots.

A free 30-minute evidence review first, then up to five working days on one workflow: one review path, one evidence pack, judged against your reviewer’s own criteria.

Book a free evidence review Verify it yourself