--- title: "Solution: Security leadership (by role)" canonical_url: "https://tokenobserve.com/solutions/security-leadership" published: 2026-09-02 last_updated: 2026-10-21 --- # Solution: Security leadership (by role) Six residual risks name you as the person who accepts them. All six are published before you ask. ## The argument Cloud hosting holds workspace evidence and supplied credentials. For customer hosting, Token Observe is a self-hosted, fail-closed governance gateway that sits inline in the agent request path and sends the vendor nothing, so what your team reviews is software running on your infrastructure rather than a processor relationship. The threat model names the CISO as the role that must record a dated acceptance of six residual risks: heuristic injection detection with false negatives, an audit chain that is tamper-evident rather than tamper-proof, an unauthenticated on-behalf-of header, group claims held as a snapshot, no multi-factor authentication on local accounts, and long-lived bearer credentials. None is evidence of approval until a named person dates it. There has been no independent penetration test; the evaluation terms exist so your team can run one first. ## Facts - Risks requiring your dated signature: Six, published in the threat model before a buyer asks - Vendor egress: Cloud: service-held evidence and credentials. Customer hosting: no vendor runtime phone-home - Credential into your stack: No standing broad credential; two read-scoped pull connectors you can withhold - Failure mode: Fail-closed: missing, unresolvable or erroring state denies the request ## The limit The trade you accept first: Inline and fail-closed means Token Observe is a single point of failure in the agent request path, and there is no fail-open switch ## What this reader is under pressure about - 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. - 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. - 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. ## What this reader asks, and the answer Q: You have not had a penetration test. A: 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. Q: Where do the audit keys live? A: 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. Q: The on-behalf-of header is unauthenticated. Anyone can forge a principal. A: 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. ### Six 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. ### 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. ## The capabilities that matter most to this reader, in order - https://tokenobserve.com/platform/agent-permissions - https://tokenobserve.com/platform/policy-engine - https://tokenobserve.com/platform/audit-chain - https://tokenobserve.com/platform/human-approvals - https://tokenobserve.com/platform/shadow-ai-radar ## Questions and answers Q: What is the single largest risk of adopting Token Observe? A: 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. Q: Does the vendor ever see our prompts, keys or trace database? A: 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. Q: Can we run our own penetration test before we buy? A: 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.