Token Observe vs LLM observability

The two products answer questions that sound similar and are not. A tracing tool answers what happened, in enough detail to debug it. Token Observe answers whether this may happen, at the moment it is proposed, and then keeps the answer in a form that survives being asked about a year later. A scoring pipeline that flags a policy violation after the fact has produced a finding; an inline verdict has produced a refusal, and the difference is whether the customer’s card number left the building.

That timing is why the request path is ordered the way it is and why the order is not casually changeable. Unicode sanitisation runs before anything else looks at the payload, so smuggled invisible characters cannot slip past a detector that is reading a different string from the one the model will read. Detection runs before the verdict. The verdict is a single point — allow, block, redact or require approval — rather than a set of independent middlewares that can each decide something different. Where a named human principal is supplied and the deployment enforces it, their directory groups intersect the agent’s authority after the verdict and before the approval branch, so a human is never asked to approve something the intersection forbids.

The response side matters as much and is where most of the engineering sits. A streamed response cannot be re-decided once bytes are on the wire, so response-side policy is resolved before the first byte from the policies that could apply rather than from the classes that turn out to be present, and a blocking class ends the stream with an in-band frame the instant it is seen. A tracing tool has no equivalent problem, because it is not holding anything back.

Telemetry is written for the team that owns the service and is usually readable by all of them. Evidence has a different set of obligations, and the flight recorder is built to the second standard: trace list, search, detail and export reads are attributable, spend figures and recertification evidence are gated on the reader’s team scopes as well as their role, and surfaces that join records with no trustworthy team key — radar findings, organisation-wide audit views, the executive dashboard — require an explicit organisation-wide scope and return 403 rather than presenting a misleading partial view.

Search is deliberately constrained for the same reason. A compliance officer’s question in English is translated into a validated filter object over fourteen allow-listed fields, never into SQL, because trace content is attacker-influenced by construction and anything derived from it that reached an interpreter would be an injection surface. The interpreted filter comes back beside the results as editable chips, so the reader can see how their question was read before acting on the answer, and when no translation model is configured or the call fails, a deterministic keyword parser answers instead. The cost of that design is stated in the same place: the filter cannot group, count or correlate, so which agents used the same card number twice is not a question you can ask.

Exports are sealed rather than signed, and the wording is worth keeping precise because it is the kind of thing a security reviewer checks. A compliance export contains the traces and events for the period, the approvals with approver identity and rationale, the audit entries covering every governance-plane change, a chain verification result naming the sequence number of any break, and a SHA-256 digest of the bundle generated at a recorded time. The bundle is not itself signed. Durable origin evidence comes from the keyed audit chain plus an Ed25519 anchor retained independently of the database, and what an anchor buys is exactly one thing: any copy you kept off-box beats any rewrite made after you took it.