Security leadership
Six residual risks name you as the person who has to accept them, and all six are published before you ask.
On this page
What is already on you
- 01
The actions are consequential now, and irreversible
Agents write code, query databases and move money. The moment an agent can issue a refund, merge a deployment or transition a ticket, the security question stops being what the model said and becomes what actually happened downstream — and an API returning 200 is not an answer to that. - 02
Indirect injection arrives through the channel the agent trusts
The prompt a human typed is the channel everybody watches. Tool results are the channel that gets agents hijacked, because the model treats them as retrieved fact. Token Observe scores both and weights tool-result findings 1.25×, which is an admission about where the risk sits rather than a claim to have solved it. - 03
You are installing the process that concentrates every provider key
A provider row names both a URL and an environment variable, and the gateway resolves that variable and sends its value to that URL as a bearer credential. An unconstrained registry write would therefore be equivalent to reading every secret in the one process that deliberately holds them all — which is why the two provider egress allowlists are the highest-value hardening step for any deployment whose model endpoints are not the public vendor ones, and why neither of them may be empty. Registered tool servers and webhook receivers carry their own host and credential-name pairs, and the tool-server pair guards the worse primitive of the two. - 04
Evidence has to survive the person who runs the database
Most audit logs are defeated by the same administrator who is asked to produce them. The default here is hash-chained and unkeyed, and a full chain recompute beats it — there is a test in the repository that performs exactly that forgery and asserts it succeeds. Keyed digests and an off-box Ed25519 anchor are what change that, and each buys something precisely bounded. - 05
Somebody has to sign, and it will be you
The design-partner gate does not close on an average score. It requires named owners and written acceptance of single-node SQLite, no vendor-operated availability commitment, no independent certification and the endpoint-seat preview limitations. An empty field is a failed gate.
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
You have not had a penetration test.
answeredCorrect, and the product’s own security documentation says so before a buyer asks. No third-party assessment, red-team engagement or external code audit has been carried out. The internal work is genuine — a five-dimension adversarial review with a three-verifier refutation panel per finding, a STRIDE threat model, targeted testing of specific attacks including a deliberately forged audit chain and adversarial ReDoS inputs, and automated release gates — and it is not the same thing as an external test, so it is not presented as one. The published licence sets thirty days for your team to read, run and attack the software before a purchase order exists, and permits publication of the results. Take that as the intended commercial position rather than a right already granted: the file carries a banner saying it requires counsel’s approval in England and Wales before it is relied upon, and it still has placeholders in it, so the terms your lawyers sign are the ones that bind. Start from the published defect list; it will stop you re-finding what is already known.
- 02· asked
Where do the audit keys live?
answeredWherever your database administrator cannot read them, which in practice means injected from an external key manager at process start rather than persisted as platform environment variables. The reason is specific: on a platform where one console reads both the service variables and a shell on the data volume, that party holds both halves, and the key has stopped separating anyone from anything. There is no third option — the custody arrangement is either a mechanism or a sentence written into the evidence pack, and an auditor will ask which. Set the key regardless of where it lands, because keyed mode still defeats a database-only writer: a leaked backup, an errant restore, a database-level integration, anyone holding the volume but not the process environment.
- 03· asked
Your prompt-injection detection is heuristic. That is not real security.
answeredIt is heuristic, and blocking on a classifier with a meaningful false-positive rate would break legitimate traffic on an inline hot path. Two things make that a decision rather than an excuse. Scoring runs on tool results as well as prompts, weighted 1.25× there, because that is where indirect injection actually arrives. And an injection finding is one input to policy rather than the only control: deny-by-default action-level RBAC, tool scoping, delegation that intersects permissions at every hop, payload-bound approvals and hard budget ceilings all bound what a successful hijack can do. The residual is a false negative, it is named in the threat model, and it is yours to accept in writing rather than something you discover in a pilot.
- 04· asked
The on-behalf-of header is unauthenticated. Anyone can forge a principal.
answeredThey can, and the threat model names you as the acceptor of that. The structural mitigation is that the mask can only narrow authority and never grant it: the agent’s own RBAC decision is computed before any principal field is read, so a forged principal buys an attacker strictly less than sending no header at all. The half that matters more is about deployment state. Enforcement has three settings and only one of them refuses anything — off is the default and reads no principal at all, shadow resolves and records what it would have refused while letting the request through, and only enforce is a control. An install that has not reached enforce should not describe the intersection as a mitigation it holds.
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 six risks that name you, and why each one went that way
The threat model’s acceptance section is not a disclaimer page. It records, per risk, the role that must accept it and the proposed rationale, and states that none of them is evidence of approval until that role writes a dated acceptance into the design-partner evidence pack. It then closes the loop in the way that matters: anything not on the list and not mitigated above it is an unrecorded gap, which is treated as a finding rather than as silence.
That is the differentiating property, and it is worth being blunt about why it is in your interest. A vendor who publishes six accepted risks has given you a shorter, more honest review than one who publishes a certification badge and a marketing security page, because you can argue with the six. An unrecorded gap is indistinguishable from one nobody found, and the second kind is the one that surprises everybody in production.
- Heuristic injection detection has false negatives
- Regex and scoring rather than a model, on both prompts and tool results. The rationale is that a classifier with a meaningful false-positive rate on the inline path would block real work, and that findings feed policy rather than acting as the only control.
- The audit chain is tamper-evident, not tamper-proof
- Four things a signature does not close, stated plainly: key theft, pre-anchor history, sink collusion where every sink is administered by the party running the database, and time — only an RFC 3161 authority or a public ledger proves when.
- The on-behalf-of header is unauthenticated
- No signed actor claim. The mask narrows and never grants, and the agent’s own permission decision is taken before the principal is read; two of the three enforcement settings are instrumentation rather than control.
- Identity-provider group claims are a snapshot
- A revoked group keeps granting until the person next signs in or the capture ages out, twenty-four hours by default. Following a directory API live would mean a new credential, a new egress host, a directory-read-class permission and a network dependency inside a login — all wrong for a product that ships air-gapped. Entra group-overage principals capture zero groups and are denied, so that failure direction is closed.
- No multi-factor authentication on local control-plane accounts
- Accepted conditionally: TLS terminating in front, local login disabled once single sign-on is rolled out, and the provisioning token kept in a secret manager. Provisioning is a bounded user push, not a live directory mirror, and it can never set a role or an evidence scope.
- Agent credentials are long-lived bearer tokens
- Conceded, with a reason: workload identity in the SPIFFE sense cannot be presented by the agent frameworks that have to be supported today. Revocation and expiry compensate; revocation is one write and bites on the next authentication attempt.
The connection points inwards, and you can check that in five minutes
Token Observe is self-hosted and bring-your-own-key. There is no telemetry, no phone-home, no licence callback and no hosted component, and that is a property of the code rather than a policy that could change with a configuration flag. The verification path is deliberately short: list every outbound call site with one grep over the server source, list every hard-coded URL with a second grep over the server and core packages, run it with egress allowed only to your providers and confirm nothing is blocked, and read the dependency list — the package holding the entire governance domain has zero runtime dependencies, and the server’s own list is short enough to read in one sitting. Count it in the manifest and against the software bill of materials attached to the release rather than against a number in a document; the documented count is behind the manifest at the time of writing.
The same argument runs through the shadow-AI connectors, and it is the shorter security review as well as the smaller blast radius. Token Observe holds no credential into your security stack; your stack pushes evidence to it. The worst a compromised install can do to your SIEM is stop receiving from it. Two pull connectors exist and they are the exception rather than the pattern.
Where hardening is genuinely yours, it is named rather than implied. Terminate TLS in front of it — the process speaks plain HTTP and manages no certificates. Keep the metrics endpoint on the monitoring network, because it follows Prometheus convention and is unauthenticated while exposing agent identifiers and month-to-date spend. Narrow both egress allowlists to your own endpoints and credential names. Treat the database file as evidence: restrict access, back it up to storage the operator cannot rewrite, and check that chain verification returns valid after every restore.
- Allowed provider hosts
- Which hosts a provider base URL may name. Narrowing it is what stops an admin-level registry write from becoming a read of every secret in the process environment.
- Allowed key environment prefixes
- Which environment variables a provider row may reference, so the session secret and every unrelated cloud credential in the process stay unnameable. Neither list may be empty.
- Rejected credentials are not stored, not even hashed
- A digest of a credential a rejected caller presented would be an offline oracle against a secret that may well be live elsewhere in your estate. A governance product must not turn someone else’s mistyped production key into a durable cracking target.
- Browser trust boundary
- Console responses carry a same-origin content-security policy asserted by test to contain no external origin and no wildcard, with frame-ancestors set to none — without it, a page on any origin can frame the console and land a click on the kill switch.
What the audit chain proves against a motivated insider, layer by layer
The default is hash-chained and unkeyed, and what that buys is stated exactly: an operator with write access to the database file can rewrite an entry, recompute every downstream hash, and verification will report valid. That is not an inference — the repository contains a test that performs the forgery and asserts it succeeds without a key and fails with one, so neither half of the claim can drift. The property genuinely on offer at the default is tamper-evidence against alteration that does not also recompute the chain, and it should not be presented to an auditor as more than integrity verification.
Setting an audit key changes the entry digests to keyed MACs sealed at every boot by a checkpoint, so rewriting history needs the key as well as database access. Enablement and rotation are external two-boot ceremonies with one-shot authorisation flags, and an ordinary keyed boot refuses a missing checkpoint schedule even when the rows form a valid plain chain — otherwise a database writer could delete every checkpoint, rehash in plain, and ask the product to seal the downgrade as if it were first enablement.
Anchoring adds an Ed25519 signature over the chain head, published off-box, because a MAC has a structural problem as evidence: the key that verifies the chain is the key that can forge it. The claim an anchor supports is one sentence — any copy of the anchors you kept off-box beats any rewrite made after you took it — and the product refuses to sign a chain that does not verify, a head that has moved backwards, or an already-anchored entry that no longer matches. Refusing is strictly better than proceeding, because signing over a forged head would launder the rewrite under a key the auditor was told to trust.
Anchoring is off unless the signing key is configured, and the residual is published beside the mechanism. Key theft signs anything. History before the first anchor is covered by no anchor. A sink administered by the same party that runs the database is not independent. And the signer asserts its own timestamp, so only a timestamping authority proves when.
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.
Agent permissions
Deny by default, explicit deny wins, and delegation intersects — so an agent cannot borrow authority it was never granted.
Policy engine
One deterministic verdict on every governed request: allow, block, redact, or park it for a human.
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.
Human approvals
One human decision, bound to one exact payload, spendable once.
Shadow AI radar
Five evidence sources for AI activity that never touched the gateway, and a coverage model that refuses to call a dead feed a clean estate.
What is the single largest risk of adopting Token Observe?
That it stops. Governance is inline and fails closed by design, so if Token Observe is unavailable, governed agents cannot call models — and its availability therefore becomes a governance property of your environment rather than a vendor’s problem. There is no fail-open configuration to reach for during an incident, because a control you can bypass by turning it off is not a control. The design-partner gate will not close until a named person has recorded, in advance, what happens when the fail-closed gateway is unavailable. Treat that as a decision to make in the review rather than a risk to discover in production.
Does the vendor ever see our prompts, keys or trace database?
No, in the ordinary supply of the software. There is no telemetry, phone-home, licence callback or hosted component, the licence carries that as an undertaking rather than a diagram — in a file still marked as a template pending counsel’s approval, so the undertaking is intended rather than executed — and there is no code in the product that could send it — which is why the verification takes two greps and an egress watch rather than a trust exercise. The one exception is stated explicitly: anything you voluntarily send during support or incident response, which is governed by your support agreement. Redact it before you send it, and if it would contain personal data, execute a data processing agreement first.
Can we run our own penetration test before we buy?
That is the intended use of the evaluation terms: thirty days from first installation to read, run and attack the software before a purchase order is raised, including commissioning a third party to do it for you. Publication of the findings is permitted after coordinated disclosure, there is no gag clause, and benchmark results need no pre-approval. The caveat is on the instrument rather than the intent — the published licence is a template awaiting counsel’s approval, so put the evaluation window in the document your lawyers actually sign. The security policy also offers safe harbour for good-faith testing. Start with the published defect list and the threat model; both exist partly to stop a paid test spending its budget rediscovering known findings.
What is in scope if we find something?
Everything in the shipped packages and scripts, the published container image and compose file, and — importantly — the default configuration: anything insecure by default, or that becomes insecure by following the documented setup path, is a valid report even where an option exists to avoid it. Documentation that materially overstates a security property is treated as a security defect rather than a typo. A new path that evades or weakens the keyed epochs, checkpoints, signed anchors, boot verification or off-box head comparison is expressly in scope, because the database writer is inside the evidence-integrity threat model. Third-party deployments, the providers being fronted and your own infrastructure are out.
How does it behave when its own evidence layer is broken?
It stops writing rather than continuing quietly. An intrinsic audit verification failure latches readiness and audit writes unavailable, later governed requests receive a typed 503, and the detecting response deliberately does not append an audit row onto the chain it has just found unsafe. A singleton incident row is the deployment-wide latch and it is monotonic: restarting does not clear it, and there is no online endpoint that can. Recovery is restoring a trusted pre-incident database, or the documented drained offline verification and explicit maintenance-clear ceremony — which is a planned piece of work rather than a button, and belongs in the runbook before it is needed. The same principle sets the support severity: a deployment serving traffic happily but no longer recording it is a severity one, because the product exists to produce that record.
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