Supplier information

What AgentAudit processes, where it sits, how the record is protected, and — in the same document — what this supplier does not claim.

What AgentAudit processes

Only what your agents report: a timestamp, an action, an outcome, and whatever optional context you choose to send — a rationale, a subject reference, the model and policy version in force, whether a human reviewed it and who.

It collects nothing on its own. There is no tracking, no enrichment, no lookup against any other source, and no inference. If a field is in your record it is because your agent put it there.

The technical controls

Each of these is checkable. The file is named so a buyer’s technical assessor can read the mechanism rather than take the sentence on trust — and the first three can be tested live from the Prove it page.

A decision cannot be edited or deleted once written.
Enforced by database triggers on UPDATE and DELETE, not by application code. Attempts are refused even for the service role, which bypasses row-level security entirely.
supabase/apply-agentaudit.sql — and you can run the attempt yourself on the Prove it page.
Deleting an agent cannot erase its decision history.
The foreign key from a decision to its agent is ON DELETE RESTRICT, so the parent row cannot be removed while decisions reference it. Agents are retired, not deleted.
supabase/apply-agentaudit.sql
One customer cannot read another customer's records.
Row-level security policies scope every read and write to the caller's organisation. The database enforces it, so a fault in application code cannot widen it.
supabase/apply-agentaudit.sql, supabase/apply-tenancy.sql
API keys are never stored in a form that could be used.
Only a SHA-256 hash of a key is kept. The plaintext is shown once at creation and cannot be recovered, so a database disclosure does not hand anybody working credentials.
src/lib/apiPrincipal.ts, src/app/api/access-keys/route.ts
No decision content is ever sent to a language model.
There is no model call anywhere in AgentAudit. Nothing is summarised, classified, scored or rewritten by AI — the compliance assessment and the transparency record are deterministic functions over counted figures.
src/lib/agentaudit/ — grep it for a model call and you will find none.
A rationale is never generated.
The reasoning stored against a decision is whatever the customer's agent reported, verbatim. This platform will not write one, and the SDK will not infer one when it wraps a function.
src/lib/agentaudit/ingest.ts, packages/agentaudit-sdk/
Verification can be performed without us.
The hashing algorithm is published in full. A customer, a regulator or an opposing party can re-derive every hash from an export with about thirty lines of their own code. The browser verifier makes no network request when it runs.
/agentaudit/docs#algorithm

Sub-processors

Three, and no others are involved in handling a decision record:

Sub-processors used by AgentAudit
Provider	Purpose	Touches decision records
Supabase	Database, authentication and row-level security	Yes — the record is stored here
Vercel	Application hosting and delivery	In transit only
Stripe	Subscription billing	No — billing data only

Retention, and the erasure question

A decision cannot be deleted. That is the entire product, and it pulls against the right to erasure under Article 17 of the UK GDPR. A data protection officer will raise it in the first meeting, so it is raised here first.

The design intent is that a decision record contains no personal data. The subject field is for a reference — a case number, a claim identifier, an account key — not a name. Held that way, the record describes what an agent did to case 88213 and the identity of that person lives in your own systems, where erasure is something you can actually perform.

Nothing in this platform enforces that. It stores what your agents send, so minimisation has to happen at source, in your code, before the decision is reported. That is worth writing into your integration design rather than discovering later.

Whether Article 17 is engaged at all for a given deployment, and whether an exemption applies, is a legal question about your use case. This supplier does not answer it and is not competent to.

Supplier questions

1 of 7 supplier questions answered. 6 are outstanding and shown as such — a visible gap costs a follow-up email, and an invented answer costs the contract.

Anything the deployment can establish about itself is read from the running system rather than typed in — a page that asks a human to remember which region they deployed to will eventually state the wrong one confidently. The rest are the operator’s own declarations, in their own words.

Region the application runs inRead from the deployment

London, United Kingdom (lhr1)

Read from the running deployment, not typed in. A supplier page that asks a human to remember which region they deployed to will eventually state the wrong one confidently.

Legal entity, registered address and company numberNot yet answered