Which clauses this produces evidence for.
And, on the same table, which ones it does not touch.
A mapping is not a certification
A control mapping is not a certification, and this one is stated at the top rather than in a footer because it changes how every row below should be read. Token Observe holds no SOC 2 report, no ISO 27001 certification and no ISO/IEC 42001 certification, and it has had no independent penetration test; the security work behind it is internal, and it is published as internal rather than dressed as an external assessment. Every row says that a feature helps evidence a clause, never that installing the software makes you compliant — the vendor’s own support terms and published licence say it in the same words, that the software is a compensating control which does not make its licensee compliant with any law, regulation or standard. Classifying your systems by risk, carrying out a fundamental rights impact assessment, authoring the policy set and notifying a regulator remain your organisation’s duties, and evidence produced by a tool discharges none of them.
EU AI Act (Regulation 2024/1689)
Token Observe produces evidence against the deployer obligations of Regulation 2024/1689 — the duties that fall on the organisation using an AI system rather than on the organisation that built it.
The Act binds providers and deployers differently, and this table takes the deployer’s side of it. If your organisation runs agents built on somebody else’s models, you are a deployer, and the deployer articles are the ones an auditor will read to you: record-keeping over the system’s operating life, human oversight including the ability to stop, use in accordance with the instructions, a named person assigned to oversee, monitoring and onward reporting, log retention, the impact assessment where one is required, and cooperation with the authorities. Each of those is answered by a field or an artefact rather than by a paragraph of intent — which is the whole test this mapping applies, because a purpose nothing consults is a sentence in a document.
The timing argument is arithmetic rather than rhetorical. The high-risk obligations phase in through 2026 and 2027, and record-keeping is the one obligation that cannot be satisfied retroactively: a policy can be written the week before an audit, but a year of request history cannot. Retrofitting logging onto agents that have been running ungoverned for a year is the expensive path, and it is expensive in a specific way — the year you cannot evidence is the year you end up explaining.
Events are recorded automatically while the system is operating, across its lifetime.
The flight recorder writes the governed request lifecycle — the policy decisions taken, a post-redaction prompt excerpt capped at 4,000 characters and read back off the outbound payload, and tool arguments and results capped at 16,000 characters — for as long as your retention setting keeps them, while the hash-chained audit log records every governance-plane change separately from payloads. Two limits travel with that. Token Observe does not record hidden model reasoning, so a record of what an agent was asked and what it then did is not a record of why it decided. And model response text is deliberately not persisted: the response event records stop reason, upstream request id, token counts and content-block types rather than the words, while a tool result is stored, because a tool result is evidence of an action.
A person can oversee the system in operation, understand what it is doing, and intervene.
A require_approval policy holds the request at the gateway until a named human decides, and the decision is stored with the approver’s identity, the timestamp and their written rationale rather than as a boolean. Approvals are bound to the payload hash, single-use and expiring, so an approval granted for one request cannot be replayed against a different one. The limit worth stating beside the mechanism is volume: an approval queue nobody reads is worse than no gate at all, which is why gates are scoped rather than universal, and why every policy can run in shadow mode first, so you learn your false-positive rate before you start holding real work.
An operator can interrupt or stop the system, through a stop button or an equivalent control.
The kill switch is scoped global, team or agent, requires an attributable actor and a written reason, and is evaluated first in the governance decision — before role checks, budgets and every policy — so nothing downstream can override it. It is the literal implementation of the stop capability rather than an analogue of one. The cost of that design is stated in the same breath: governance is inline, so Token Observe is a single point of failure in the agent request path and an unavailable gateway stops the fleet. That is intentional, because a control you can bypass by turning it off is not a control.
The deployer takes technical and organisational measures to use the system as its instructions say it should be used.
The agent registry makes a declared purpose a required field at creation, capped at 4,000 characters and carried verbatim into every recertification snapshot, with every edit to it writing a field-level audit diff naming the actor — and it sits on the same row the gateway resolves at step 2 of every request, so the stated purpose cannot drift away from the record being enforced. Where an auditor reads it is worth being exact about: the declared purpose lives on the registry record and in the recertification history, and it is not one of the objects inside the sealed evidence bundle, which carries traces, approvals and audit entries. What Token Observe does not do is compare a request against that sentence. Nothing scores behaviour against declared purpose; a person reads traces and forms a view. Treat the field as the thing an auditor compares against, and the permission envelope as the thing that constrains, because those are two different mechanisms and only one of them runs on every call.
Human oversight is assigned to named people who have the competence, training and authority to exercise it.
Every agent record carries an owner email, required at creation and lower-cased on write so accountability does not fork on capitalisation, and every approval records the identity of the person who decided. Control-plane access is session-only and attributable to a named human: an admin bearer mode was documented once and the claim was removed rather than the feature added, because every governance action being traceable to a person is what makes the audit log evidence at all. Competence and authority are your assessment. Token Observe records who, and never whether they were the right who.
The deployer monitors the system in use and reports risks and serious incidents onward.
Monitoring is produced: policy-block metrics, month-to-date spend by agent, shadow-AI radar findings and incident-shaped webhook events — policy.blocked, budget.exceeded, agent.suspended, radar.finding — delivered into your own ITSM or SIEM with a signed payload carrying identifiers, counts, policy names and a one-line human summary. One deployment condition travels with the metrics half: the Prometheus endpoint follows the convention of its ecosystem and is unauthenticated, so it must be reachable only from your monitoring network, and month-to-date spend by agent id is one of the series it exposes. Reporting is not. Token Observe notifies systems inside your estate and nothing outside it, so informing a provider, a distributor or a market surveillance authority stays a human act on a human’s timetable. Delivery is also deliberately subordinate to the request: a webhook can never delay or fail the governed request that produced it, which is the right trade for an inline gateway and the wrong assumption for anyone treating the webhook as the record of what happened. The record is the trace and the audit log.
Logs the deployer controls are kept for a period appropriate to the purpose, and at least six months unless other law says otherwise.
Retention is implemented and its default is a decision rather than an omission: ACP_TRACE_RETENTION_DAYS is unset out of the box, and unset means keep forever, which over-satisfies a six-month floor and satisfies nothing in GDPR Article 5(1)(e). A GDPR-regulated deployment has to set it, because retention should be decided rather than inherited, and an upgrade that silently started deleting a customer’s evidence would be the worse failure. The scope caveat is the one a data protection officer asks for: the window and subject erasure act on traces, trace events, the search index and trace scores, on the live primary database only. The audit log is never purged, by design, so the record of a deletion outlives the deleted data. Approvals, radar findings and webhook deliveries are not purged and cannot be erased by subject — and an approval summary can carry up to 160 characters of the tool arguments a model proposed, captured before egress redaction runs on the response, so a retention statement that quotes a number without naming those tables is inaccurate.
The deployer uses the information the system provides to carry out a DPIA where the GDPR requires one.
The agent record carries a DPIA or FRIA reference in free-form metadata, each value up to 2,000 characters, and it travels into the recertification snapshot rather than living only in a console — so the assessment and the system it covers are joined by a reference an auditor can follow in either direction. Read the boundary precisely, because it is easy to state too widely: the reference sits on the registry record and in the recertification history, and the sealed evidence bundle is a bundle of traces, approvals and audit entries rather than a copy of the registry. The assessment itself is work a person does. Token Observe holds the pointer and the operational facts an assessment draws on: which data classes were detected and in what volume, which providers received them, under which data policy, and what was blocked. It produces neither the document nor the judgement inside it.
The deployer cooperates with authorities on any action concerning the system.
One endpoint produces one bundle for a period you choose: traces and their events, approvals with approver identity, timestamp and rationale, the audit-log entries for governance-plane changes in that window, a chain verification result naming whether it is valid, how many entries were checked, where it broke if it did, which protection mode was in force and the checkpoint it was verified against, and a SHA-256 digest of the bundle itself taken at a recorded time. The chain verdict is what distinguishes this from an exported log file, because an edit or a deletion breaks the link at a known sequence number and the verdict names that number. Two boundaries belong beside the mechanism rather than under it. The bundle is paged and capped rather than unbounded — traces, events, approvals and audit entries each have a ceiling, and the bundle declares in its own truncation flags when it hit one, so a long period is a sequence of bundles rather than one file that quietly stops short. And what it contains is scoped by the person who asked: evidence reads are team-scoped inside the store query, so an organisation-wide bundle requires an organisation-wide reader. Read the seal precisely too: the bundle is digest-sealed, not signed. The digest catches accidental or post-export editing and proves nothing about origin.
Classifying your systems by risk, carrying out a fundamental rights impact assessment, and notifying regulators.
These are decisions and filings, and no tool makes them. Token Observe records the risk tier you assign, stores the reference to the assessment you carried out and exports the evidence you cite, but it classifies nothing, writes nothing and notifies nobody outside your estate. The vendor does not sign off your DPIA, FRIA, record of processing or risk register either: support explicitly excludes compliance outcomes, and mapping your control framework or authoring your policy set is a professional services engagement rather than something a licence includes.
ISO/IEC 42001 (AI management systems)
Token Observe produces evidence against six ISO/IEC 42001 Annex A controls, and holds no ISO/IEC 42001 certification of its own — two statements buyers reasonably confuse, so both are on the page.
ISO/IEC 42001 is a management-system standard for artificial intelligence, and a certification body audits an organisation against it rather than a product. Its main clauses are the management system itself — context, leadership, planning, support, operation, performance evaluation and improvement — and Annex A carries the controls an organisation selects and justifies. A tool cannot hold a management system on your behalf. What a tool can do is hold the records an internal audit or a certification body samples, in a form that survives being sampled.
The strongest of those records is the inventory, and the reason is structural rather than featural: the agent registry is the same row the gateway enforces against, so the inventory cannot silently drift from what is actually running. Every other control below is mapped to a specific artefact on that basis, and where the artefact only reaches part of the control, the row says partial and names the part it does not reach.
The organisation maintains an inventory of the AI systems it operates.
The agent registry is the inventory, and it is the same row the gateway resolves on every governed request, so there is no export, no sync and no reconciliation job between the list and the runtime — because there is only one list. Four fields are required to create an agent: name, owner email, team and declared purpose. Lifecycle is part of the record too, and only an active agent passes the gateway check. The limit is coverage rather than accuracy: an agent that never routes through the gateway has no row here at all, which is the shadow-AI radar’s problem and not the registry’s.
Risks are assessed for the AI systems in use, and the assessment is kept current.
Every agent carries a risk tier — minimal, limited or high — shown in the console and carried into every recertification snapshot, with each change to it recorded as a field-level audit diff. Recertification is what turns a tier into evidence: a named reviewer attests a SHA-256 digest of the exact configuration in front of them, and because that digest binds each referenced role’s normalised permissions rather than merely its identifier, editing a role marks every affected review stale immediately without rewriting what was attested. The honest limit is that risk tier is recorded and reviewed but is not a policy-scope dimension — policies match on agent id, team and tag — so a rule intended to bite on your high-risk agents is written against a tag you maintain rather than against the tier. An overdue review also never suspends the agent itself; that remains a person’s decision, and it is audited as one.
Events in the operation of an AI system are logged, and the logs are monitored.
Two records, kept apart on purpose. The flight recorder holds request-lifecycle evidence and is subject to your retention window. The hash-chained audit log holds governance-plane changes only, is never purged, and survives a trace purge, so the record that a deletion happened outlives the deleted data — the two live in separate tables and verification still passes afterwards. Verification is an endpoint rather than a promise, and it locates a break at an exact sequence number. What that verdict is worth depends on one setting the export names: on the default unkeyed setting, a database writer who rewrites a row and recomputes every downstream hash produces a chain that verifies, which has been tested and does pass. Present it to an auditor as integrity verification, which it genuinely is, and not as tamper-proofing, which it is not.
Incidents involving AI systems are detected, handled and reported to the parties who need to know.
Incident-shaped events are published rather than managed: policy.blocked, budget.exceeded, agent.suspended, radar.finding and tool.drift_detected leave as a signed webhook payload into the ITSM or SIEM that already owns your incident process. Token Observe does not run that process, does not page anyone and does not track an incident to closure. It also does not send mail: the event publisher contains an SMTP client that the composition root never configures, so this release opens no socket for it — recorded here because a reviewer reading the source will find the primitive, and presence of a primitive is not presence of a feature.
Access to AI systems, and to the resources they can reach, is controlled and reviewed.
Agent permissions are deny-by-default and action-level: an agent holds only what a role explicitly grants, and delegation intersects permissions at every hop, so a forged delegation chain can only narrow authority and never widen it. Model listings are filtered against the registry rather than passed through, and a tool call is re-checked against grants independently of the tool listing, because a caller that never listed can still invoke. On the human side there are four control-plane ranks — admin, operator, auditor and viewer — with evidence reads additionally scoped by team, applied inside the store query and impossible to widen with a request parameter. One limit belongs beside that: local control-plane accounts have no multi-factor authentication unless you put an OIDC provider in front of them, and that is a recorded residual risk with a named role who has to accept it rather than a gap nobody noticed.
Relationships with suppliers in the AI supply chain are managed, including what they may do with your data.
Providers are a registry rather than a configuration file, and each carries a data policy expressed as three independent requirements rather than one: zero data retention and no training on payloads as two separate booleans, plus an optional serving region named as a string, where an empty region means no constraint. They are kept apart because providers genuinely differ on each — a provider may retain but not train, and region pinning is orthogonal to both — and because a single ZDR flag would overpromise. Those requirements are enforced on the fallback chain as well as on the primary route, and a request that can find no compliant route fails closed with ACP_ZDR_UNAVAILABLE rather than quietly downgrading. Tool suppliers are pinned: a descriptor hash over the canonicalised name, description and input schema, re-verified at the 60-second catalogue refresh, with drift quarantining the tool. Two limits. The data-policy flags are operator-asserted and unverified — setting one records your assertion about your contract with that provider, auditably, with the actor who set it, and Token Observe cannot check it against the contract. And a rewritten descriptor may be served from the trusted snapshot until the next refresh, at most 60 seconds on access.
Context, leadership, planning, support, operation, performance evaluation and improvement — the clauses a certification body audits.
A management system belongs to an organisation and no software holds one on its behalf. Token Observe produces records an internal audit or a certification body can sample; it does not define your AI policy, set objectives, run management review or close nonconformities. Token Observe is not itself certified to ISO/IEC 42001, and a supplier questionnaire that reads a control mapping as a certificate has misread it. Where certification matters to your procurement process, a design-partner agreement can carry a contractual commitment to a named milestone date — which is a commitment, and still not a certificate.
NIST AI Risk Management Framework 1.0
Token Observe supplies artefacts to all four NIST AI RMF functions — GOVERN, MAP, MEASURE and MANAGE — with the thinnest coverage in MEASURE, which is where a governance gateway naturally runs out of things to say.
The NIST AI Risk Management Framework is voluntary and carries no certification scheme of its own, which makes it a different kind of entry on this page: organisations adopt it because it gives a board a structure to ask questions in, and because it is the vocabulary most US-headquartered buyers already use. Its four functions run from governing a programme, through mapping context and identifying risk, to measuring and then managing what you found.
Mapped against a runtime control, three of the four functions land squarely and one does not. GOVERN, MAP and MANAGE are about accountability, context and action, all of which a gateway holds records of or performs. MEASURE is largely about evaluating models and outcomes, and a gateway sees traffic rather than model behaviour — so the row below says what is measured, says where the hook for somebody else’s evaluation is, and stops there.
Risk management is cultivated as a practice: policies exist, are documented, and someone is accountable.
Policies are versioned, audited records rather than settings, and every change writes an audit row naming the actor and the field-level diff; each agent carries a named human owner. Two mechanisms make that more than documentation. Every policy can run in shadow mode first, so you learn your false-positive rate before you start blocking real work. And an install can require that a backtest of that exact rule — a digest over its trigger, action, scope and priority — has been run and acknowledged by a named person before the rule may move into enforcement, with that person’s name and the figures they accepted copied into the audit entry. That gate is off by default and is a process control rather than a technical one. What Token Observe will not do is write your policy set: that is your work, or a professional services engagement, and it is explicitly outside support.
The context an AI system operates in is established: what it is for, what it touches, who owns it.
The registry record is the map: declared purpose, risk tier, named owner, team and tags, the roles and therefore the exact model and tool grants, budgets, rate limits, the data policy routing must honour, and free-form metadata for a repository, an environment or an assessment reference. Because the gateway resolves that record on every call rather than a copy of it, the map and the territory are the same object. What it does not map is the model’s own provenance: training data, model cards and the lineage of what a provider serves you are outside a gateway’s view entirely.
Identified risks are analysed, benchmarked, tracked and evaluated over time.
Measurement exists and its edges are worth knowing before you cite it. The cost ledger and month-to-date spend by agent, policy match and block rates, shadow-mode findings and the searchable trace store are all real and all queryable. Trace scores are a hook for eval scoring rather than an eval suite: Token Observe stores a score against the trace it belongs to and gives your evaluation stack somewhere to put one, and it does not generate the score, run the evaluation or hold a benchmark. The one published performance figure is a laboratory baseline, and it travels with the conditions it was measured under because without them it means nothing: 206.2 requests per second, p50 71.2 ms and p95 163.8 ms, from 6,216 completed requests with none failed, over 30 seconds at concurrency 16, against an in-process mock provider, on Node 20 on a single ten-core M1 Max laptop, on 14 August 2026 from a named immutable commit. The source publishes its own list of what that does not prove and every item is load-bearing: thirty seconds is not a soak, a mock upstream excludes provider latency, streaming, retries and failover, a fresh database does not model a partner-sized trace corpus, and the release image runs Node 24 rather than the Node 20 that was measured. That list closes with an instruction rather than a hedge — until a partner-shaped sustained-load test passes against agreed thresholds, do not turn the baseline into a concurrency limit or a throughput commitment.
Risks are prioritised, acted upon, and monitored after action is taken.
Acting is the part a gateway is built for: policies that block or hold a request, per-agent budgets and rate limits that stop a runaway loop, a suspend_agent action, provider circuit breakers that open on a failing route, and the kill switch that is evaluated first and beats everything else. Typed failover is where the care shows: a 429 or a timeout fails over, but a content-policy refusal, an authentication failure, an invalid request and a context-length error do not — otherwise the fallback chain quietly launders a refusal into a success, and your measured block rate becomes fiction. Every one of those actions is audited with the actor and the reason.
Evaluating a model for bias or representational harm, and evidencing where the model and its training data came from.
Token Observe governs runtime traffic. It does not test a model for bias, produce fairness metrics, hold model cards or evidence training-data provenance, and no configuration turns it into something that does. Those measurements come from your evaluation stack; where one produces a score, the trace-score hook is where it lands, beside the request that produced it rather than in a separate spreadsheet nobody joins back.
OWASP Top 10 for LLM Applications 2025
Token Observe carries a control for six of the ten OWASP LLM risks, partial coverage of two, and nothing at all for the remaining two — which are the rows worth reading first.
The OWASP list is a community risk register rather than a standard: nobody certifies against it, nobody is bound by it, and its value is that it is the list a security reviewer already has open when they start asking questions. That makes it the fastest way to see the shape of a control’s coverage, provided the empty rows are published alongside the full ones.
Two entries here are out of scope by construction rather than by omission. Model poisoning happens in a training pipeline a gateway never sees, and vector weaknesses need a retrieval layer Token Observe does not have. Neither is a roadmap item disguised as a gap; both describe a place where an inline runtime control is the wrong instrument, and saying so is more useful than a tick that would not survive the first question about it.
An attacker steers the model through crafted input, directly or through content the model retrieves.
Unicode is sanitised to a fixpoint before anything reads the payload, then heuristic scoring runs on prompts and on tool results, with tool-result findings weighted 1.25 times because indirect injection arrives in what a tool returns rather than in what a person types. The injection trigger is a policy with a confidence threshold, so you choose the point at which a score becomes a block, and you can watch that threshold in shadow mode before it holds anything. It is a heuristic, which means false negatives: novel phrasing and non-English payloads evade regex scoring, and that residual is recorded with a named role who has to accept it rather than being described as solved. The layer underneath is what limits the damage when the scanner misses — deny-by-default permissions and an approval gate on high-impact tools.
Personal data, secrets or confidential content reach a model, a tool or a response that should not carry them.
Redaction runs inline and in-process before the request leaves, not asynchronously and not after the fact: card numbers validated by Luhn, IBANs by mod-97, UK NHS numbers by mod-11, US social security and UK national insurance numbers, email and phone, plus secret kinds — JWTs, AWS access keys, prefixed vendor API keys and PEM private-key headers. Secret kinds are always masked irreversibly, whatever a policy’s mode says, because a reversible placeholder for a credential is a credential. Responses are scanned as well as requests, so a rule fires on an identifier the model produced even though nobody sent one, and streaming is covered by a hold-back buffer with a separate buffer per tool-call argument channel, because a stream has no later enforcement point. The detector is the limit: matching is regex plus checksum, so free-text personal data and identifier formats outside the UK and US patterns are not detected at all. This is a compensating control, not a complete data loss prevention system.
A component the application depends on — a model, a plugin, a tool server — is compromised or silently changed.
MCP tool descriptors are hashed at approval over the canonicalised name, description and input schema, re-verified at the 60-second catalogue refresh and on live-listener maintenance, and drift quarantines the tool and emits tool.drift_detected. The window is stated rather than rounded off: a rewritten descriptor may be served from the trusted snapshot until the next refresh, at most 60 seconds on access. On the software’s own supply chain, every release ships a CycloneDX bill of materials and a SHA256SUMS file covering each artefact, and the governance core has zero runtime dependencies, so the code that decides allow or block can be read end to end without standing up any infrastructure.
Training or fine-tuning data is manipulated so the model itself carries the attacker’s intent.
Token Observe governs runtime traffic and has no view of a training pipeline. Nothing about how a model was trained, what it was trained on, or who could influence that is visible from a gateway sitting between your agent and a provider’s API, and no setting changes it. The adjacent thing a gateway can do is record which provider and model served each request, so if a model is later found to be poisoned you can enumerate exactly which of your requests it touched.
Model output is passed to a downstream system without validation, and is executed, rendered or trusted.
Output redaction runs on responses, and the response-side data-class decision on a stream is taken before the first byte leaves. What Token Observe cannot do is control what your application does with the text once it arrives: rendering it as HTML, passing it to a shell, or interpolating it into a query are decisions in your code, on the other side of the gateway. It also does not rewrite outbound URLs, so markdown-based exfiltration is detection rather than prevention. The honest framing is that the gateway constrains what goes out and records what came back; the sanitiser at the point of use is still yours to write.
An agent holds more permission, autonomy or functionality than its task needs, and uses it.
Deny-by-default action-level permissions, argument-level policy matchers that bite on what a tool is being asked to do rather than merely on which tool, human approval gates on high-impact calls, and delegation that intersects at every hop. The design assumption is that a model will eventually ask for something it should not have, so the authority envelope is decided before the request runs rather than inferred afterwards from what came back. The residual is credential-shaped and stated as such: agent credentials are long-lived bearer tokens with manual rotation rather than workload-bound identities, because the agent frameworks that have to be supported today cannot present one — revocation, optional expiry and last-used timestamps are what compensate.
The system prompt, and the secrets people put in it, reach a caller.
A system_prompt_probe heuristic sits in the injection scanner, and the stored prompt excerpt is bounded, taken after redaction from the outbound payload rather than from the original, access-controlled inside trace evidence and never returned through an agent protocol — an agent cannot ask the gateway for it. Reading it is a human evidence path, scoped by the reader’s team and audited: sensitive trace list, search and detail reads append attributable audit events, because reading a prompt corpus is itself an act worth recording.
Retrieval and embedding infrastructure leaks across tenants, is poisoned, or is inverted to recover source data.
There is no retrieval layer. Token Observe does not host a vector store, does not index your documents and does not sit between a retriever and an index, so embedding inversion, retrieval poisoning and cross-tenant leakage inside a vector database are outside what it can observe or control. What it does see is retrieved content once it has been pasted into a request or returned by a tool, which is exactly where the injection scanner reads it — so the consequence of a poisoned index is in scope even though the index is not.
The system produces confident output that is wrong, and somebody acts on it.
Traces make outputs reviewable, and trace scores are the hook where an evaluation result lands beside the request that produced it. That is the extent of it. Token Observe does not fact-check, does not ground a response against a source and holds no opinion about whether an answer was correct. A governance gateway can prove what was asked, which model answered and what the application then did with the answer; whether the answer was true is an evaluation problem that sits outside it, and pretending otherwise would be the exact overclaim this page exists to avoid.
Cost, tokens or request volume run away, through a loop, an abusive caller or a badly framed task.
Per-agent budgets for a single request, an hour, a day and a month, plus rate limits on requests, tool calls and tokens per minute, provider circuit breakers that open on a failing route, and a suspend_agent policy action for a runaway loop. The distinction that matters is where the ceiling lives: these are enforced at the gateway before the request goes out, which is a different thing from a dashboard that tells you on Tuesday what Monday cost. The cost dashboard exists as well, and it is the part every vendor in this category has. The limit is estimation and topology, and both are recorded rather than smoothed over: admission reserves against a projected cost computed before the call, so a provider’s reported final cost can land above the pre-flight estimate, and the per-minute rate windows are process-local counters rather than distributed admission — which is one of the reasons a single node is the supported topology at this scale.
OWASP Top 10 for Agentic Applications 2026
Token Observe maps against the agentic threat list wherever an inline control can act — goal hijack, tool misuse, supply chain, cascading failure, oversight and repudiation — and marks the two entries where a gateway is only part of the answer.
The agentic list, and the threat taxonomy that accompanies it, describes failure modes that only appear once a model can act rather than only answer: an agent pursuing a goal somebody else inserted, a tool used within its permissions but against its purpose, a chain of agents amplifying one bad decision, and a record nobody can rely on afterwards. Those are governance problems more than they are model problems, which is why this list maps more densely onto a gateway than the application-layer one does.
Two rows are partial for the same underlying reason, and it is worth naming once. An inline control sees what crosses it. A memory written by one part of your system and read by another without a governed call is invisible to it, and so is an agent nobody registered — which is why the shadow-AI radar exists as a separate control with its own evidence sources rather than as a claim that the gateway sees everything.
An attacker redirects the agent’s objective through content it reads, and the agent pursues the new goal.
Injection scanning runs on both channels, and tool-result content is treated as data rather than as instruction — the distinction the whole class turns on. Tool-result findings carry a 1.25 weighting because that is where indirect injection actually arrives. Because the scanner is a heuristic with false negatives, the layer beneath it is what bounds the damage: an agent whose permissions are deny-by-default, whose high-impact tools sit behind an approval gate and whose budget has a ceiling has a smaller blast radius when a hijack is missed than one whose only defence was the scanner.
An agent invokes tools beyond its authority, or accumulates privilege across a chain of delegations.
Tools are scoped per role, arguments are matched by policy so a rule can bite on the amount, the account or the destination rather than only on the tool name, and delegation intersects permissions at every hop — so a forged delegation chain can only narrow authority, never widen it. A tool call is authorised independently of the tool listing, because a caller that never listed can still invoke. One thing the on-behalf-of mask cannot do is authenticate: the header carries no signed claim, and it is accepted on the reasoning that it can only narrow authority, so a forged principal buys an attacker strictly less than sending no header at all. Two qualifications belong with that rather than under it, because the source states them and they are the easiest thing on this page to flatten. The mask has three settings and only one of them refuses anything: off is the default and reads no principal at all, shadow computes the intersection and records what it would have refused while letting the request through, and only enforce subtracts authority — so an install that has not reached enforce should not describe the intersection as a mitigation it holds. And an agent can simply omit the header, which skips the mask entirely unless that agent is configured to require a principal. What is unconditional in every setting is the record: the header is written to the trace, which is what makes a request attributable to a person.
A tool a fleet already trusts is rewritten after approval, and the fleet keeps calling it.
The descriptor hash is taken at approval over the canonicalised name, description and input schema, re-verified at the 60-second catalogue refresh and on live-listener maintenance, and drift quarantines the tool and emits tool.drift_detected rather than failing open. The residual is the refresh window itself: a change may be served from the trusted snapshot until the next refresh, at most 60 seconds on access, which is a bounded exposure rather than an unbounded one and is published as such.
Poisoned content is written into an agent’s memory or context and read back later as trusted.
Content that crosses the gateway is sanitised and scanned, including the tool results where poisoned context usually enters, and a policy can block on the finding before it reaches the model. Content that does not cross the gateway is invisible. Token Observe holds no agent memory store, no conversation store of its own beyond bounded trace evidence, and no retrieval index, so a memory written by one component and read by another without a governed call is entirely outside it. Where that memory is later used in a governed request, the scanner reads it then — which is detection at the point of use rather than protection of the store.
One failure propagates through agents, tools and retries until the whole fleet is affected.
Rate-limit circuit breakers, provider circuit breakers, a suspend_agent policy action and the kill switch, which is evaluated first and beats everything else, so a person can stop a cascade without waiting for a deployment. The counterweight is stated in the same place rather than in a footnote: because governance is inline, an unavailable gateway stops the fleet. That is the trade an inline control makes, and it is deliberate — a control you can bypass by turning it off is not a control.
High-impact actions happen without a human decision, or with one nobody can later reconstruct.
A policy holds the request until a named human decides, and the record keeps the approver’s identity, the timestamp and their written rationale. Approvals are bound to the payload hash, single-use through a consumption marker and expiring on a TTL, so a decision cannot be replayed against a different request or reused after the situation changed. Suspension and kill-switch use are the escalation path above that, and both require an attributable actor and a reason.
An agent operates outside the organisation’s knowledge or control, and nobody notices.
A registered agent carries a named owner, an authority envelope and a lifecycle anybody with the rank can suspend in one write. An agent nobody registered is exactly what a request-path control cannot see, which is why the shadow-AI radar is a separate control reading billing lines, network egress rows, service-account listings and IDE telemetry that your operators supply, alongside the gateway’s own hourly roll-up of credentials presented and rejected — counts and reasons only, never the presented token and not a digest of it either, because a digest of a live secret is an offline oracle against that secret. Three limits belong beside it. That roll-up is detection rather than prevention, and it is hard-capped at 2,000 writes an hour, past which its counts are a floor rather than a total. The operator-fed sources are only as current as the last export somebody posted, and between exports the radar reports the estate as it was rather than as it is. And every pass records a run row whatever the outcome, because a dead feed must never be indistinguishable from a clean estate.
Nobody can prove afterwards who did what, or that the record has not been changed since.
Every governance-plane change is appended to a hash-chained log with a verification endpoint that locates a break at an exact sequence number, and every control-plane action is attributable to a named human because there is no admin bearer token to hide behind. How much that resists depends on one setting, and the export names it. Unkeyed, the default, is defeated by a writer who rewrites a row and recomputes the whole chain — there is a test that proves the forgery passes, and a second test that proves it fails once a key is set. Keyed, with HMAC-SHA256 under a key the database administrator cannot read and a boot checkpoint sealing the head, defeats that writer — and only if the key is injected from a store the administrator cannot read, because a key in a file beside the database buys nothing, and a host compromise reads it out of the process environment either way. An independently retained Ed25519 anchor is what addresses those two qualifications rather than closing them, it is off until you set a signing key, and its claim is exactly one sentence: any copy of the anchors you kept off-box beats any rewrite made after you took it. The chain is tamper-evident, not tamper-proof, and the difference is the whole reason the setting is reported in the export.
So many approvals are raised that the human gate becomes a rubber stamp.
Gates are scoped by risk so that approvals stay rare enough to be read — an approval queue nobody reads is worse than no gate at all, because it converts a control into a delay while appearing in the evidence as a control. Shadow mode is the mechanism that keeps that honest: a policy runs and records what it would have held without holding anything, so the volume and the false-positive rate are known before the queue becomes somebody’s afternoon. An install can go further and refuse the transition into enforcement until a backtest of that exact rule has been acknowledged by a named person, whose name and accepted figures are copied into the audit entry.
What a reviewer should do with this page
Take the rows marked out of scope to whatever else in your estate covers them, because that is the gap this product will not close and the one your assessment will find. Then take the rows marked evidence and ask for the artefact rather than the claim — an export, an anchor verification, a policy backtest — because on every one of them there is a file you can be shown. The security page carries the residual risks that need a named person to accept them, which is the other half of what an assessment asks for.
Anything your questionnaire asks that neither page answers goes to security@tenhaw.com and does not need a call.
Does installing Token Observe make my organisation compliant with the EU AI Act?
No, and no software can. Token Observe produces the artefacts a deployer is asked to show — an inventory with declared purposes and named owners, an automatic record of what each agent did, approval decisions carrying the approver’s identity and rationale, a stop control that demands an attributable actor and a reason, and an export bundle with a chain verdict inside it — but the obligations sit on your organisation and stay there. Classifying a system’s risk, carrying out a fundamental rights impact assessment, deciding a retention period your counsel is content with, and notifying a regulator are all yours. The vendor’s own licence and support terms say the same in their own words: the software is a compensating control, it does not make its licensee compliant with any law, regulation or standard, and the vendor does not sign off your DPIA, FRIA, record of processing or risk register.
Is Token Observe SOC 2 or ISO 27001 certified?
No. It holds no SOC 2 report, no ISO 27001 certification and no ISO/IEC 42001 certification, and it has had no independent penetration test — no third-party security assessment, red-team engagement or external code audit has been carried out on it. What exists instead is internal work, published rather than summarised: a threat model naming the residual risk beside each mitigation, a defect list that names the file, states the concrete cost, describes the attack that works and records which findings were refuted as well as confirmed, a CycloneDX bill of materials and a SHA256SUMS file with every release, and licence clauses that expressly permit you to inspect, test, fuzz, penetration-test and reverse-engineer the software as deployed on infrastructure you control, or to commission a third party to do it for you. Publication is permitted as well, and the terms differ by kind, which is worth reading rather than summarising into one phrase: benchmark results may be published with no pre-approval, provided the publication names the version tested and the configuration used, and security findings may be published, naming the software, after the coordinated-disclosure process in the vendor’s security policy. There is no clause that suppresses a finding — the licence says the section is meant to be consistent with the vendor already publishing its own outstanding defects rather than to override it. A design-partner agreement can carry a contractual commitment to a named certification date; a date is not a certificate, and this page will keep saying so until one exists.
What does an auditor actually receive, and how do they check it?
One bundle from one endpoint, covering a period you choose: traces and their events, approvals with approver identity, timestamp and rationale, the audit-log entries for governance-plane changes in that window, a chain verification result, and a SHA-256 digest of the bundle taken at a recorded time. The chain verdict is what distinguishes it from an exported log file, because an edit or a deletion breaks the link at a known sequence number and the verdict reports that number, the protection mode in force and the checkpoint it was verified against. Two things to expect rather than discover: each of those collections has a cap and the bundle declares in its own truncation flags when it hit one, so a long period comes back as a paged sequence of sealed bundles rather than a single file that stops without saying so; and the contents are scoped to the team scope of the person who requested it, so an organisation-wide bundle needs an organisation-wide reader. Read the seal precisely, because auditors do: the bundle is digest-sealed, not signed. The digest detects accidental or post-export editing and proves nothing about origin. Durable origin evidence comes from keyed audit plus an Ed25519 anchor retained somewhere the party under audit cannot rewrite.
Can an auditor verify the record without trusting the party under audit?
That is what anchoring is for, and its claim is deliberately one sentence: any copy of the anchors you kept off-box beats any rewrite made after you took it. With a signing key configured, the chain head is periodically signed as an Ed25519 statement — sequence, hash, entries covered, protection mode, the previous anchor’s hash, the key id and the time — chained anchor to anchor and published to a file or an HTTP sink. The auditor needs the anchor export and the public key, and the public key must arrive out of band rather than from the anchor file, because a signature checked against a key read out of the artefact being verified proves nothing at all. The offline verifier imports only the governance core and Node built-ins, touches no database and runs on a locked-down laptop. An auditor who can also reach the running install should use both: the verification endpoint to confirm today’s history is intact, and the offline verifier against a copy taken months ago to confirm that today’s history is the one they were shown then — because the endpoint, unlike the copy in their hands, is served by the party under audit. The things anchoring does not close are printed by the verifier on every run rather than filed in a document, so nobody reads a pass as more than it is: key theft signs anything, history before the first anchor is covered by no anchor, a sink administered by the same party as the database is not independent, the signing time is asserted by the signer so only an RFC 3161 timestamp authority proves when — and that is not built — and there is no Merkle tree, so partial-log proofs are not available either. Anchoring is also off until you set the key.
Which requirements does Token Observe not touch at all?
Anything about the model rather than the traffic, and anything about an agent that never routes through the gateway. Specifically: training-data provenance and model cards, bias and fairness testing, training-pipeline poisoning, and vector or embedding weaknesses, because there is no retrieval layer to defend. Also, unambiguously, the decisions: risk classification, the impact assessment itself, the policy set, and any notification to a regulator. Unregistered agents are the most interesting gap, and they are answered by a different control rather than denied — the shadow-AI radar reads billing lines, network egress rows, service-account listings and IDE telemetry your operators supply, plus the gateway’s own roll-up of credentials presented and rejected, and its findings belong in your risk register rather than being written off as noise. Absence of evidence is not evidence of absence.
We have not decided whether our systems are high-risk. Is any of this relevant yet?
The classification is yours to make and this mapping does not make it, but the timing does not wait for the decision. The EU AI Act’s high-risk obligations phase in through 2026 and 2027, and record-keeping is the one obligation that cannot be satisfied retroactively: a policy can be written the week before an audit, a named owner can be assigned in an afternoon, and neither of those recovers a year of request history that was never recorded. Retrofitting logging onto agents that have been running ungoverned for a year is the expensive path. Starting the record early costs a base-URL change per agent, and if the classification later comes back as limited rather than high, you have an inventory, a spend ledger and an audit trail you would have wanted regardless.
Send the questionnaire. Most of it is already answered.
If you are running an assessment and something on it is not covered by this page or the security page, ask and you will get a written answer rather than a meeting invitation.
no form · no qualification step · no sales desk · the other three ways in