Inline enforcement
also called in-path enforcement · inline policy enforcement · runtime enforcement · in-line governance
There is one test, applied literally. Can the action reach its target without the decision being taken? If it can, by any route — a second credential, a direct provider call, a code path that skips the wrapper, a configuration flag — then the decision is advisory for that route, and coverage is a claim rather than a fact. This is why almost every serious implementation converges on the same shape regardless of vendor: something stands between the agent fleet and the things it can affect, resolves who is calling, decides whether the call may proceed, and records the outcome either way. What differs is the order of the checks and the honesty of the record, not the topology.
Three properties separate inline enforcement worth its cost from the decorative kind. It has to be able to refuse, not merely to record — a component that observes every request and stops none of them is a monitoring product in a load-bearing position, which is the worst of both trades. It has to be the only route, or the coverage gap has to be measured rather than assumed. And it has to be stageable: a rule whose false-positive rate you can only learn by switching it on will teach you that rate by stopping somebody’s work at an inconvenient hour. Shadow mode — running a rule over real traffic and recording what it would have done without doing it — is the mechanism, and the discipline that goes with it is that a shadow rule nobody looks at is not a dry run, it is a rule that does nothing.
Inside the path, order is load-bearing rather than tidy, and each position buys a specific guarantee. Text normalisation has to run before detection, because a scanner reading un-normalised input is examining a different document from the one the model will read — invisible Unicode can carry a complete instruction that a human reviewer and a naive pattern match both miss. The record has to be opened before anything can reject the request, because a request that vanished from the log is indistinguishable from one that was never made, and a refusal is evidence. And where a human is going to be asked to approve something, every narrowing check has to run first, so nobody spends attention approving a request that would be refused anyway. A system that performs the same checks in a different order is not doing the same thing.
The costs are real and should be stated beside the claim rather than under it. Enforcement adds latency to every governed call. It makes the enforcing component a dependency of everything it governs, which converts a governance property into an availability property. And it creates an approval queue, which is a durable organisational cost: an approval queue nobody reads is worse than no gate at all, because it manufactures the appearance of oversight and trains a human to click through it. Any of the three can make inline enforcement the wrong choice for a given estate — an estate of drafting assistants whose output a person reads before anything happens gains little from an inline refusal and pays the full price of the dependency.
Two places are hard to reach inline, and both invert the usual argument. The first is traffic that never arrives: an agent configured with a provider key directly is outside the perimeter by construction, which makes discovery a prerequisite for any coverage claim. The second is a developer’s own machine. Every major coding assistant’s tool hook fails open when it times out, so a hook that round-trips to a central server converts every outage, every slow connection and every name-resolution blip into a silent, organisation-wide bypass. The workable design is the counter-intuitive one — decide locally against a signed policy bundle issued in advance, treat any missing, malformed, unsigned, mis-addressed or expired bundle as a denial, and accept that a snapshot is not live state, so a kill switch engaged after issuance does not reach the machine until the next bundle. Token Observe ships that surface as a preview and says in its own documentation that it does not equal an inline network gateway on a device the organisation does not administer.
The rule that was never allowed to be switched on blind
A team writes a rule holding any refund over £200 for human approval. Switched straight on, it either works or it stops the support queue at nine on a Monday morning, and nobody knows which until it happens. Run in shadow first, it decides every real refund request for two weeks and records the verdict without acting on it, and the team reads the result: it would have held eleven requests, of which nine were routine renewals a threshold of £500 would have let through and two were the cases the rule was written for. They change the threshold and the scope, watch another week, and then promote the rule to enforcing as a separate, attributable act with a name attached to it. The rule that reaches production is not the rule that was written, and the difference was found by evidence rather than by an incident.
What inline enforcement is routinely confused with
- Detection and monitoring
- Monitoring answers what happened and, at best, raises an alert. Enforcement answers whether it may happen and returns a refusal. The gap between them is the window between the action and the response, which for an agent issuing refunds at machine speed is the whole of the exposure.
- Guardrails
- Guardrails usually run in-process, inside the agent framework, and are shipped by the team that ships the agent. They are useful and they are not enforcement in this sense, because the same deploy that changes the agent can change or remove them, and nothing outside the agent’s own repository records that it did.
- Shadow mode
- Shadow mode is inline in position and advisory in effect: the rule is evaluated on the real request and its verdict is recorded rather than applied. That is the correct way to introduce a rule, and it must be visibly distinguishable in the record from a rule that is enforcing — otherwise a control that is off looks exactly like a control that is quiet.
Related terms
Fail-closed
Fail-closed describes a control that denies the action it governs whenever it cannot complete its own check — because a dependency is unavailable, a required piece of evidence is missing or stale, a value cannot be evaluated, or the control itself is down. The opposite arrangement, fail-open, permits the action in those same circumstances, which turns every outage in the control into a temporary and silent absence of the control.
AI control plane
An AI control plane is the layer that holds the authoritative configuration for an organisation’s AI agents — which agents exist, who owns each one, what each may call, what each may spend, and what happens when a rule is broken — and that makes the configuration binding by sitting in, or being consulted by, the path those agents’ requests take. The name is borrowed from networking, where the control plane decides what should happen and the data plane carries the traffic that does it; the distinction matters here because a product can implement either half and still be sold under the same label.
AI gateway
An AI gateway is a policy-bearing proxy for AI traffic: it terminates the calls an application or agent makes to models, tool servers and other agents, and applies authorisation, inspection, quota and logging rules to them before they reach the upstream. The term is used for at least three different products — an API gateway extended to model traffic, a security-inspection layer sold as an AI firewall, and a cloud runtime that bundles gateway, identity and observability — so the label describes a position in the architecture rather than a set of guarantees.
AI agent governance
AI agent governance is the practice of deciding, outside the agent and before it acts, whether the authority it is about to exercise is authority somebody actually delegated to it — and of recording afterwards what it did with that authority in a form that survives the people who could edit it. What separates it from model safety, from observability and from identity management is where the decision sits: in the path the action must travel, where it can refuse, rather than in a policy document, a dashboard, or a nightly reconciliation.
Where Token Observe does this
The definition above is the field's, not the product's. This is the part of the product that implements it, for a reader who wants to see one.
Policy engine
One deterministic verdict on every governed request: allow, block, redact, or park it for a human.
Injection scoring is nine fixed patterns, not a model
Human approvals
One human decision, bound to one exact payload, spendable once.
An approval takes effect only when the agent retries
Agent permissions
Deny by default, explicit deny wins, and delegation intersects — so an agent cannot borrow authority it was never granted.
Off by default; only enforce refuses anything
The terms next to this one
What the field is called, what its members have in common, and the one property that separates them from each other.
Definitions are the easy part.
The glossary is written to be useful whether or not you ever buy anything. If you have got to the point of deciding how to implement one of these in your own estate, say what your agents do and you will get a straight answer about what it would actually take.
no form · no qualification step · no sales desk · the other three ways in