AI Policy Enforcement Points: Before the Model, After the Model, or at the Tool

Enforcement is a runtime action, not a review step

An enforcement point is a place in the execution path where a policy decision is made and acted on while the interaction is in progress. The decision can be to allow, redact, block, rate limit or escalate for human approval. A control that only reports what happened after the fact is monitoring, not enforcement.

In a tool-using assistant, the path is a loop rather than a line. User input goes to the model, the model proposes a tool call, the tool returns output, and that output goes back to the model, which may call another tool. Every pass through the loop is a chance to enforce policy, and every pass is a chance for a gap.

Protocols such as MCP make this more pressing. Unlike a traditional API integration, MCP lets the model decide which tools to invoke, when, and with what parameters, often against sensitive systems. The caller's intent is no longer fixed in application code.

What each point can see and what it can act on

Pre-model enforcement sees the user prompt, any retrieved or attached content, and, if the loop is covered, tool output returning to the model. It can redact sensitive values or block a request before the model is exposed to them, and it can rate limit abusive usage. It cannot see what the model will generate, and it cannot stop a tool call the model decides to make later. Inspecting only the user prompt also misses indirect prompt injection, where hostile instructions arrive inside tool output rather than user input.

Post-model enforcement sees the response and any proposed tool call before either is released. It can catch system prompt leakage, exfiltration markup and policy-violating content before the response reaches the user or is passed to a downstream tool or system. Its limits follow from its position. It operates after generation, so it cannot undo data already sent to the model or an action that has already run. It is useful only if it sits ahead of whatever consumes the output.

Tool-level enforcement sees the tool identity, the parameters, the calling agent or role, and the permission scope. It can validate parameters, apply least privilege, run policy checks at execution time, require explicit confirmation for higher-risk actions, and rate limit calls. These controls do not depend on the language of the prompt, which is why they hold up against injected text in any form. The tool layer cannot see the conversation that led to the request, cannot prevent data exposure to the model itself, and may judge each call as permitted when a sequence of permitted calls is harmful.

Mapping common risks to the best-suited point

The table assigns each risk to the point with the strongest position to act on it. Most risks have a secondary control elsewhere, which is the practical argument for layering.

• Sensitive data sent to the model: Pre-model. Redact or block before exposure. Tool-side scoping limits what data can be returned in the first place.
• Direct prompt injection: Pre-model inspection helps, but tool permissions and parameter validation hold regardless of how the injection is phrased. Post-model screening catches results.
• Indirect injection through tool output: Inspect tool output before it returns to the model. Least privilege at the tool limits what an injected instruction can do.
• Non-compliant or unsafe model output: Post-model. Screen before the response reaches users or downstream components.
• Unauthorized or out-of-scope action: Tool. Enforce permissions, validate parameters, and escalate higher-risk actions for human approval at execution time.
• Unverifiable decisions: All three points. Each must emit a structured decision record, because no single point sees the whole interaction.

Why single-point designs fail

Each single-point design has a predictable failure mode. A pre-model-only design inspects the prompt but never sees an unsafe output, and it cannot stop an action the model initiates. A post-model-only design can screen a response, but by then a tool call may have executed, and the sensitive data has already reached the model. A tool-only design enforces permissions well but is blind to the context behind a request and leaves data exposed to the model.

Two further gaps cut across all three. Tool output is an input to the model, so it is an injection path that user-prompt inspection does not cover. And legitimate tools can be used in harmful sequences where each call is in policy and holds the right permissions. These are inferences from how the points are positioned, not properties of any one product, but they explain why privilege minimization is usually treated as the strongest single control and still is not sufficient alone.

A layered model and the evidence it produces

A layered design applies the relevant control at each pass through the loop. User input and returning tool output are checked before the model sees them. Model output and proposed tool calls are checked before they are released. Each tool call is authorized and validated at execution time. Control strength should match action risk: a read of low-sensitivity data may simply be allowed, while a payment or record deletion may be escalated for human approval.

Each decision should be recorded as structured data: the point in the path, the action taken (allow, redact, block, rate limit or escalate), the policy applied, and the outcome of any human review. Keep the policy decision separate from whether the legitimate task completed. A blocked request and a failed request are different facts, and an auditor needs to tell them apart.

The evidence differs by point. Pre-model records show what data was withheld or redacted before exposure. Post-model records show what output was stopped or released. Tool records show which actions were authorized, refused or approved by a person. Individual decision records may not reveal sequence-level risk, so architects should be clear about what per-interaction and per-call evidence does and does not show. What an auditor expects in these records should be settled with compliance teams against the regimes that apply.

Where Trussed applies

Trussed enforces policy in the execution path across models, agents, tools and MCP servers. Decisions are enforced at runtime, not reviewed after the fact, and the available actions are allow, redact, block, rate limit and escalate for human approval. The scope is individual interactions and tool calls.

The enforcement itself generates audit-ready evidence, mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST. Trussed can be deployed self-managed in the customer cloud, with configurable retention and data residency. In production, it has run 100+ models under one policy plane for regulated enterprises.