Security leadership
Six residual risks name you as the person who accepts them. All six are published before you ask.
This is already on your desk.
- 01
The actions are consequential now, and irreversible
Agents write code, query databases and move money. Once an agent can issue a refund or merge a deployment, the question stops being what the model said and becomes what happened downstream. An API returning 200 does not answer that. - 02
Indirect injection arrives through the channel the agent trusts
Tool results, not the prompt a human typed, 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 says where the risk sits without claiming to have solved it. - 03
You are installing the process that concentrates every provider key
The gateway resolves the environment variable a provider row names and sends its value to that row's URL as a bearer credential, so an unconstrained registry write reads every secret in the process. The two egress allowlists are the hardening step that closes it.
- 01
You have not had a penetration test.
Correct, and it is published before a buyer asks. No third-party assessment, red-team engagement or external code audit has been carried out. The internal work is real (an adversarial review with a refutation panel per finding, a STRIDE threat model, a deliberately forged audit chain), but it is not the same thing and is not presented as one. The licence sets thirty days for your team, or a third party you commission, to read, run and attack the software before a purchase order exists.
- 02
Where do the audit keys live?
Wherever your database administrator cannot read them: injected from an external key manager at process start rather than persisted as platform environment variables. 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. Set it regardless: keyed mode still defeats a database-only writer, such as a leaked backup, an errant restore or anyone holding the volume but not the process environment.
- 03
The on-behalf-of header is unauthenticated. Anyone can forge a principal.
They 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 deployment state: enforcement has three settings, off is the default, and only enforce refuses anything.
Cloud custody and optional customer-hosted controls are described separately. The 24 limits we publish, and the 9 risks a named person has to accept in writing, are on one page.
What we do not claimSix risks need a named decision.
The acceptance section is not a disclaimer page. It records, per risk, the role that must accept it and the rationale, and none counts as approved until that role writes a dated acceptance into the evidence pack. Anything not on the list and not mitigated is an unrecorded gap, treated as a finding rather than as silence.
- Injection detection has false negatives
- Regex and scoring rather than a model, on prompts and tool results alike. Findings feed policy rather than being the only control.
- The audit chain is tamper-evident, not tamper-proof
- A signature closes none of key theft, pre-anchor history, sink collusion where the same party runs every sink, or time.
- The on-behalf-of header is unauthenticated
- No signed actor claim. The mask narrows and never grants, and two of the three enforcement settings are instrumentation, not control.
- 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.
- No MFA on local control-plane accounts
- Accepted conditionally: TLS in front, local login disabled once single sign-on is rolled out.
- Agent credentials are long-lived bearer tokens
- Conceded: workload identity in the SPIFFE sense cannot be presented by the agent frameworks that have to be supported today. Revocation is one write.
Sample data in the real Token Observe interface, recorded from a local evaluation with a temporary database, a mock provider and one request. No live provider key was used.
Every evidence feed points inwards, except two you switch on.
Cloud hosting holds workspace evidence and supplied credentials. For customer hosting, there is no telemetry, no phone-home and no hosted component, and that is a property of the code rather than a policy: grep every outbound call site, then run it with egress allowed only to your providers. The shadow-AI feeds run the same way: Token Observe holds no standing broad credential into your stack; your gateway, proxy and SIEM push evidence to it. Two scheduled pull connectors are the named exception: GitHub Copilot seat spend and Cisco Umbrella activity, each on a read-scoped credential you supply, both off until you set it.
This is what does the work.
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, and anchored with a signature your auditor can check alone.
Questions
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 becomes a governance property of your environment rather than a vendor's problem. There is no fail-open configuration, because a control you can bypass by turning it off is not a control. The design-partner gate does not close until a named person owns that answer in advance.
Does the vendor ever see our prompts, keys or trace database?
Cloud hosting holds workspace evidence and supplied credentials. For customer hosting, 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, and there is no code that could send it, which is why verification takes two greps and an egress watch. The one exception is anything you voluntarily send during support. Redact it first.
Can we run our own penetration test before we buy?
For customer-hosted evaluations, thirty days from first installation to read, run and attack the software, including commissioning a third party, and the testing right reaches any person running an evaluation. Publication is narrower: both publication clauses are drafted as the Licensee's, so benchmark results need no pre-approval provided the version and configuration tested are named, and security findings follow coordinated disclosure first.
Bring the objection that is not on this page.
Create a cloud account and workspace. No card or server installation. Model calls and Google BigQuery scans can incur separate provider charges.