The category itself

Inline enforcement

Inline enforcement means the decision to allow, refuse, alter or hold an action is taken in the path the action must travel, before it takes effect, by a component the acting system cannot bypass or overrule. The alternatives — a rule the agent is asked to follow, a check inside the agent’s own framework, an alert raised afterwards — are advisory rather than enforcing, because in each case the party being governed is also the party enforcing.

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.

in practice

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.

not the same as

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.
next

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.

The category itself

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.

get in touch

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