Compliance and internal audit
Every mapping says this feature helps evidence that clause. None of them says installing it makes you compliant.
On this page
What is already on you
- 01
The obligations phase in while the agents are already running
High-risk deployer duties arrive through 2026 and 2027, and building the evidence trail before the deadline is the whole point — retrofitting logging onto agents that have been running ungoverned for a year is the expensive path, because the year you most need to evidence is the year nobody recorded. - 02
Your evidence has to survive being handed to someone who does not trust you
An exported log file proves nothing to a party who assumes you could have edited it. What distinguishes a bundle from a log file is that any edit or deletion breaks the link at a known sequence number, so casual or accidental alteration is caught and located rather than merely suspected. Say casual or accidental rather than any, because at the unkeyed default an operator who rewrites an entry and recomputes every downstream hash still verifies clean; a key and an off-box anchor are what raise the bar past that. - 03
An approval queue nobody reads is worse than no gate at all
Human oversight that has been diluted into thousands of daily confirmations is oversight on paper only, and a regulator reading the record will see rubber-stamping. Risk-tiered gates exist so approvals stay rare enough to be read, which is a design position on the human-in-the-loop failure mode rather than a feature. - 04
You are asked for an AI inventory and handed a spreadsheet
An inventory maintained beside the runtime is updated by whoever remembers, while the runtime is updated by whoever ships. The registry here is the same record the gateway enforces against on every request, which is the only structural reason an inventory cannot silently drift from reality. - 05
The certification questions have no yes yet
There is no SOC 2, no ISO 27001 and no ISO/IEC 42001 certification, and no independent penetration test. Any readiness score you may have seen has been formally withdrawn. What can go into an agreement is a named date for a certification milestone your process requires — which is a different, and more checkable, thing than a badge.
The objections, in the words they are raised in
Not a marketing FAQ. These are the sentences this reader says out loud in a first call, quoted rather than softened, and several of the answers below concede that the limitation is real and name the person who has to accept it.
- 01· asked
Who says the head you are showing me is the head you showed me last month?
answeredNot Token Observe, and that is precisely what the anchor is for. Chain verification answers whether the hash chain holds; it cannot answer whether today’s chain is the one you were shown, because the key that verifies a MAC is the key that could forge it — hand it to an auditor and you have handed them the power to fabricate the record they were given it to check. So the head is periodically signed with an Ed25519 key whose private half never leaves the signer, and the signed statement is published off-box. The claim that supports is one sentence: any copy of the anchors you kept off-box beats any rewrite made after you took it. Take a copy on your own schedule, to a place the database administrator cannot rewrite. And read what an anchor does not close before you rely on it: key theft signs any history, no anchor covers what came before the first one, a sink your own database administrator also runs is not independent, and the signer writes its own timestamp, so only a timestamping authority proves when. That residual — tamper-evident rather than tamper-proof — is named in the threat model as one the CISO has to accept in writing, and it is not accepted until a named person dates it.
- 02· asked
Does installing this make us compliant with the EU AI Act?
answeredNo, and the documentation says so above the mapping table rather than below it. Every entry is phrased as this feature helps evidence that clause, never as installing this makes you compliant. Deciding risk tiers, running a fundamental-rights impact assessment and notifying authorities remain the deploying organisation’s duties, and the licence states plainly that the software is a compensating control which discharges no obligation you owe to a regulator, a data subject or a customer. What it produces is the artefact shape those clauses ask for: an enforced inventory, a declared purpose and named owner per agent, recorded approvals with rationale, a scoped stop capability, and an exportable event record for a period you choose.
- 03· asked
Is the evidence export signed?
answeredNo. Trace and compliance envelopes are digest-sealed, not signed: the recipient recomputes SHA-256 over the canonical JSON of the bundle and separately reads the embedded chain verification — its protection level, its checkpoint, and what it was attested against. That catches accidental and post-export edits, and it does not prove origin. Origin evidence comes from two other things that must travel with the bundle: keyed audit, where entry digests are MACs under a key held outside the database, and an Ed25519 anchor retained independently of the database it attests. Preserving the distinction matters more than it sounds, because a recipient who reads digest-sealed as signed has been told the wrong thing about what they hold.
- 04· asked
You have no ISO 42001 certification, so how does this help our management system?
answeredIt does not certify it, and no such claim is made. What the mapping does is name, per Annex A control, the mechanism that produces the evidence. A.4.2 asks for an AI system inventory, and the registry is the inventory the gateway enforces against on every request, so it cannot silently drift. A.5.3 attaches to a per-agent risk tier that policy scope can be written around. A.6.2.8 is the flight recorder plus the hash-chained governance log. A.9.2 is deny-by-default agent RBAC with delegation intersection. A.10.3 is the provider registry with data-policy flags and tool integrity pinning. Your certification is still yours to obtain; what changes is which clauses you evidence with a record rather than a policy document.
If the objection that would actually decide this for you is not one of the ones above, that is the more useful question, and it is the one worth sending.
Talk it throughThe clause-by-clause mapping, and the entries that say no
The mapping is useful because of the entries that decline to claim coverage. Under the OWASP LLM top ten, data and model poisoning is marked out of scope because the product governs runtime traffic rather than training pipelines; vector and embedding weaknesses are out of scope because there is no retrieval layer; improper output handling and misinformation are marked partial, because response redaction cannot control what the calling application does with the text and traces make outputs reviewable without adjudicating them. A mapping that claimed ten out of ten would be less useful to you, not more.
On the EU AI Act side, the Article 12 entry carries its own limit in the same sentence as its claim: a flight recorder for the governed request lifecycle, bounded prompt and tool evidence and policy decisions while retained, plus a hash-chained log of governance-plane changes — and no recording of hidden model reasoning, which no gateway can see. Article 26(6) is the one that requires a decision from you: retention is unset by default and unset means keep everything, so counsel has to decide whether the six-month obligation applies and approve a period that also satisfies storage limitation.
- Art 14(4)(e), the stop capability
- A kill switch scoped to one agent, a team or everything, requiring an attributable actor and a reason. It is evaluated first in the request path and beats every other gate.
- Art 26(1) and 26(2), instructions and oversight
- A declared purpose per agent, required at creation rather than optional, and a named human owner rather than a team alias. Approver identity is recorded on every decision.
- Art 26(9), impact assessments
- The agent record carries a DPIA or FRIA reference in its metadata, and that reference travels into the recertification snapshot and the export rather than living only in a console field.
- Art 26(12), cooperating with authorities
- One compliance export for a period, carrying the chain verification result alongside the content rather than beside it in a covering note.
- NIST AI RMF
- Govern is versioned, audited policy records with owner accountability per agent; map is the registry’s purpose, risk tier, model and tool grants; measure is the cost ledger, policy-match rates, shadow-mode findings and trace scores; manage is circuit breakers, the kill switch, approval gates and radar findings.
Verifying the chain on your own laptop, without trusting the party under audit
An offline verifier ships with the product and imports only the governance core and Node built-ins: it loads nothing native, touches no database and makes no network call, so it runs on a locked-down machine. You give it an anchor export and, separately and out of band, the current Ed25519 public key plus every retired public key ordered newest first. The public key is required and the tool will never print a pass without one — a signature checked against a key read out of the artefact being verified proves nothing at all, because whoever rewrote the anchors rewrote the keys beside them.
Two of its behaviours are worth knowing before you run it. It refuses a file that does not begin at the first anchor unless you explicitly allow a partial chain, because a ledger that starts at four is a deletion rather than a shorter file. And it reports honestly when it cannot speak: a live chain at a daily cadence has normally grown past its newest anchor, so a supplied head alone cannot rule out an entry beneath the anchor having been rewritten with two ordinary entries appended over it. The verifier prints its own limits on every run, so nobody reads a pass as more than it is.
The endpoint and the offline tool are not substitutes for each other, and the reason is structural. The endpoint holds the database and walks the entry chain first, so it can confirm that today’s history is intact — but it is served by the party under audit. The offline verifier, run against a copy you took months ago, confirms that today’s history is the same one you were shown then. An auditor with access to a running install should use both.
One more field decides what a passing verification is worth. The verification result names what it was compared against: a head you supplied yourself — the only form that survives a restore — this file’s own stored anchor or checkpoint, or nothing outside the entries at all. A restore that lost its tail also lost the attestation of that tail, so it verifies clean against its own stored state. Record the head on your own schedule, and keep the record somewhere the install cannot reach.
What an auditor can read, what they cannot, and why the reads are themselves recorded
The auditor rank is a first-class control-plane role rather than an admin account with a different label, and evidence access is scoped twice: by rank and by the team scopes on the individual account. An organisation-wide scope is explicit; an empty list means no team evidence at all. The predicate is derived from the signed-in user and applied inside the queries, and repeated on detail, search, export, compliance, spend, governance, approvals and savings paths — because scoping a list while leaving the detail URL open is not scoping.
Some surfaces are deliberately organisation-wide only and return a refusal to a team-scoped reader rather than a filtered answer: the audit chain and its anchors, retention controls, the shadow-AI radar, the seat census and the fleet summary. Projecting those onto one team would produce a misleading result — a whole-estate recertification view filtered to a fraction of the estate reads as the posture of the organisation, and anchors attest one global chain that cannot be projected without changing what the signature means.
Reading evidence is itself an act worth recording, and it is recorded. Sensitive trace list, search and detail reads append attributable audit events, so the question of whether an auditor read prompt content beyond their remit has an answer. Control-plane accounts are disabled rather than deleted, and there is no endpoint to delete one, so the audit trail keeps resolving the actor years later. Demoting someone without giving them an explicit scope drops any inherited organisation-wide access to the empty scope, so a role reduction cannot accidentally preserve full-corpus reach.
The parts of the platform this leans on
In the order they matter to this reader rather than the order the platform argues them, and each one carries its own stated limit on the page it links to.
Audit chain
Every administrative act hash-chained; seal it under a key held off the box, and anchor it with a signature your auditor can check alone.
Flight recorder
Every governed request in a timeline a compliance officer can read, and a search box that never writes SQL.
Human approvals
One human decision, bound to one exact payload, spendable once.
Agent registry
One record per agent, and it is the record the gateway enforces against.
Effect contracts
The action leaves once, and success is what a second pinned tool observed.
What exactly is inside a compliance export?
Traces and their events for the period you requested; approvals with approver identity, timestamp and recorded rationale; audit-log entries covering every governance-plane change; a chain verification result carrying whether it is valid, how many entries were checked, the sequence number of any break, the protection level and the checkpoint it was verified against; and a SHA-256 digest of the bundle itself generated at a recorded time. Portability exports are JSON with the same digest treatment. What is not in it is model response text or hidden reasoning — the record captures stop reason, upstream request id, token counts and content-block types rather than the generated text.
How does the product prove human oversight actually happened?
An approval is bound to one exact action payload, is single-use, and expires; consuming it requires the same payload hash, so an approval cannot be reused for a slightly different action. The record carries the approver’s identity, the time and the rationale they typed. The design position underneath that matters as much as the mechanism: gates are risk-tiered so approvals stay rare enough to be read, because an approval queue nobody reads is worse than no gate at all, and a regulator reading a record of thousands of instant confirmations will draw the obvious conclusion.
Can we prove an agent’s action had the effect it claimed?
For actions governed by an effect contract, yes, within a stated boundary. A run does not become committed because a call returned success; it becomes committed when fresh evidence, within a bounded age, matches every postcondition the contract declared, and stale or exhausted evidence never advances a terminal success state. Where a compensating action runs, it stays unverified until a separately pinned compensation verifier proves the compensation postconditions. Two honest limits: this is durable at-most-one intent rather than distributed exactly-once, and a distinct pinned verifier is not independent third-party attestation.
What happens to our evidence if we stop subscribing?
That is the intended position, and it is written down. The published licence provides that records — traces, trace events, audit entries, approvals, policies, registry records, cost ledger entries and exports — may be retained, exported and used indefinitely, including after termination, on the reasoning that the software is bought precisely to produce that evidence and losing it at the end of a subscription would defeat the purpose. Treat that as a drafted intention rather than a right you already hold: the file is marked as a template requiring counsel’s approval, so get the survival clause into the executed agreement rather than citing the repository. The practical corollary is on you: there is no vendor-side copy, so if the database file is lost and no backup exists, the traces and the chain are gone. Back it up like evidence and verify the chain after every restore.
Is the audit log the same thing as the flight recorder?
No, and conflating them is the most common misreading. The flight recorder holds governed request evidence — prompt excerpts after redaction, tool arguments and results, policy decisions, usage — and it is what a retention window and a subject erasure act on. The audit log holds governance-plane changes only, never payloads: who changed a policy, who approved what, who engaged a kill switch. It is hash-chained, and it is deliberately never touched by retention, which is what lets the record of a deletion outlive the deleted data — verification still passes after a purge.
Bring the objection that is not on this page.
Write to hello@tenhaw.com with what your agents do, which providers they call and what would have to be true for you to put something in front of them. James Rooney replies. You will get a straight answer about whether Token Observe fits, including when it does not.
no form · no qualification step · no sales desk · the other three ways in