---
title: "Capability: Policy engine"
canonical_url: "https://tokenobserve.com/platform/policy-engine"
published: 2026-09-02
last_updated: 2026-10-21
---

# Capability: Policy engine

One deterministic verdict on every governed request: allow, block, redact, or park it for a human.

## What it is

A Token Observe policy is a trigger, an action and a scope, evaluated inline on every governed request before the payload reaches a provider. Triggers match on the tool and its argument values, the model and its estimated input size, accumulated spend, request rate, the sensitive-data classes detected, the injection score and its source, or the hour in UTC. Actions are block, require a human approval, redact, warn and suspend the agent, resolved to one verdict in which a block beats an approval and an approval beats a redaction.

## Facts

- Trigger kinds: Seven: tool, model, spend, rate, data, injection, time
- Actions: Five: block, approve, redact, warn, suspend
- Data classes: Eleven, three checksum-validated
- Injection heuristics: Nine weighted patterns, 1.25× on a tool result

## The limit

Not a classifier: Injection scoring is nine fixed patterns, not a model

## Why it exists: A rule inside the agent’s own code is not a control.

Whether an agent may put a card number in a prompt, or act on a ticket saying “ignore your previous instructions”, is usually decided inside the agent: a regular expression in a try block, a threshold written by whoever built it. Each is enforced by the thing being governed, changes whenever somebody redeploys, and is invisible to whoever answers for it in an audit.

Injection in a user’s message is the demonstration. Injection in a tool result (a ticket body, a scraped page, a row somebody outside your organisation can write to) is the channel that hijacks agents, because the model reads data as instructions.

## How it works

- Sanitise first, then scan each fragment under its own source: Model-visible text is normalised before any detector reads it: the Unicode tag block, which encodes a complete invisible ASCII alphabet, plus zero-width characters and bidi overrides. Then eleven PII detectors and nine injection heuristics run over the system prompt, message blocks, tool results, arguments, tool definitions and vendor passthrough fields.
- Decide, first hard failure wins: A kill switch beats everything, then lifecycle status, then deny-by-default permissions including the delegation chain, then budget and rate ceilings. Only then are policies evaluated, in ascending priority. A shadow match is recorded and skipped; among enforcing matches the first block wins.
- Enact, or refuse rather than rewrite: On allow, the plan is applied and a redaction event records kinds and counts, never values. Data-class rules run again on the response leg: after a buffered response, before the first byte of a streamed one. Two cases are refused rather than rewritten: sensitive data in a JSON key, and in an image.
- Stage it before it bites: A new rule defaults to shadow: evaluated exactly as an enforcing one, then recorded and skipped. Where the deployment turns the promotion gate on, no rule enforces until a backtest of that exact rule is acknowledged by a named person.

## Where it runs in the request path

Step 6 of the request path

## What it does not do

- Injection detection is nine fixed weighted patterns, not a classifier. A novel phrasing matching none of them scores zero, and a rule with a minimum confidence never fires on it. Text past a 64 KB cap is not scanned.
- The eleven data classes are the detectors written into the code. A policy chooses which to match on; it cannot add a twelfth, and no free-text trigger blocks a prompt for a phrase.
- Redaction rewrites text. It does not rewrite a JSON object key or the pixels of an image: those requests are refused rather than changing an executable contract or claiming to have masked something unreachable.
- A backtest cannot replay tool-call arguments: the governance feature vector it reads carries no argument values, so a rule with argument conditions reports coverage none rather than zero impact. Spend and rate rules never score better than partial.
- Shadow mode records that a rule matched, not the payload it would have produced: a shadow redact rule is skipped before any plan is built. It also only sees traffic arriving while it runs, so a rule staged on a Tuesday says nothing about month-end.
- None of this governs an agent that does not route through Token Observe. A call made straight to a provider is not sanitised, scanned or policed; finding it is the radar’s job.

## Read next

- https://tokenobserve.com/platform/agent-permissions
- https://tokenobserve.com/platform/human-approvals
- https://tokenobserve.com/platform/flight-recorder

## Questions and answers

Q: What can a Token Observe policy match on?
A: Seven kinds: a tool call, by name pattern and conditions on its argument values; a model request, by pattern and estimated input size; accumulated spend against a USD threshold; requests or tokens per minute; sensitive-data classes with a direction; the injection score, optionally by source; and the hour in UTC.

Q: Does Token Observe use a model to detect prompt injection?
A: No. Scoring is nine weighted regular expressions run over sanitised text, summed, multiplied by 1.25 on a tool result, capped at 1. No machine-learning dependency and no semantic understanding, which is why it runs inline on every request, and why it misses a phrasing nobody wrote a pattern for.

Q: What does a policy backtest prove?
A: That the candidate rule, run against your own recorded traffic, would have newly blocked or gated a stated number of requests, or that the recording cannot answer. Requests that never reached policy evaluation are excluded from the denominator rather than counted as safe, and where a trigger depends on something the feature vector does not carry, the counters come back null. Null is a question; zero is a false answer that reads as safe to promote.

The long-form detail on this capability (the anchored sections, the worked policies and the error envelopes) is on the page itself at https://tokenobserve.com/platform/policy-engine.
