Enforcing AI policy vs filtering AI output: what changes when the control can say no

Where each control sits and who decides

Output screening is a recognised control. OWASP describes it as scoring the primary model's response against a policy before the response is returned to the user or passed to a downstream tool. It describes input screening in similar terms: a classifier reviews prompts and retrieved or fetched context before the primary model sees them. NIST's Generative AI Profile adds that these filters can be rule-based or use additional machine learning models, and advises comparing outputs against pre-defined organizational risk tolerance.

The defining trait is what the filter is asked to do. It classifies content. OWASP places output screening where injections that produced system prompt leakage, exfiltration markup or policy-violating content can be caught after the fact. The filter reports on text. It is not, by design, the component that decides whether a call or action should happen.

A control that can say no is positioned differently. It sits in the path between the caller and the model, and between the model and the tools it invokes. Because it holds decision authority, it can return a verdict that stops, alters or pauses the interaction. In practice the useful set of outcomes is allow, redact, block, rate limit and escalate for human approval. Mapping those outcomes to a control is an architectural choice rather than a published standard, but each one only makes sense when the control is positioned to act before the result takes effect.

Output filter and execution-path enforcement compared

The table summarizes the architectural differences. Real products blend these properties, so use it as a checklist of questions rather than a classification of vendors.

• Placement: Filter: at the response boundary, after generation. Enforcement: in the execution path, before the model call or tool call proceeds.
• Decision authority: Filter: classifies or scores content and may flag it. Enforcement: allows, redacts, blocks, rate limits or escalates for human approval.
• Scope: Filter: text of responses and, in some designs, inputs. Enforcement: individual interactions and tool calls, including parameters and destinations.
• Ambiguity: Filter: a borderline score is a threshold decision. Enforcement: an explicit configured outcome, such as stop or escalate.
• Failure behavior: Filter: a missed classification lets content through. Enforcement: timeout and error handling determine whether the action proceeds or stops.
• Evidence: Filter: a score or flag on content. Enforcement: a record of the request, policy applied, outcome and approver.

Why tool calls expose the gap

NIST's Generative AI Profile notes that systems restricting model outputs may still produce harmful recommendations in response to less-explicit, novel prompts, and cites jailbreaking as a way to circumvent output controls. That is a limit of classification itself. A filter must recognize the problem in the text, and attackers control the text.

Agents widen the gap because the harm is often an action. OWASP's 2026 exploit roundups describe agents that gained unintended internet access, treated reachable systems as authorized targets or repurposed shared infrastructure. They map these to excessive agency, where effective tool and network authority exceeded the intended remit. One cited case exposed a file-transfer function with an unrestricted host destination, which let sandbox output be written outside its boundary. None of those failures is primarily a question of whether a response sentence was acceptable.

OWASP's guidance therefore places controls beyond filtering at the tool boundary: enforce permissions and validate parameters, apply least privilege, screen remote content as untrusted input and treat model output as untrusted at every downstream use. Its MCP guidance says to choose controls by risk, such as explicit user confirmation, narrowly scoped authorization or policy checks enforced at execution time. It also says tool outputs should be validated and sanitized before they re-enter model context, and that pattern detection is supplementary alerting rather than the primary safeguard. Prompt wording and text labels are not an enforcement boundary.

Failure behavior, latency and evidence

Failure behavior is where the two designs diverge most. If a filter fails or misses, content passes. If an enforcement point fails, the question is what the system does next. A fail-open design lets the call proceed when the policy decision is unavailable or uncertain. A fail-closed design stops it. Neither is universally correct. A low-risk internal summarization call may tolerate fail-open, while a call that writes to a production system or sends data to an external service usually should not. The control needs to make this choice configurable by tool and risk level, and the choice should be written into policy rather than left as a product default. OWASP's guidance points the same way: define a safe failure path for tasks that cannot be completed and require a stop before any change of target.

Latency follows from placement. A control in the execution path adds a decision step to every evaluated call, so its cost is paid on the critical path, whereas an asynchronous filter can be scored off the path but then cannot prevent anything. Measure decision latency at the percentiles your applications care about, under your own policy set, and decide which calls justify synchronous enforcement.

Evidence differs because the artifacts differ. A filter produces a score or flag about content. Enforcement can record the request, the policy that applied, the outcome and any human approver, which is closer to showing what an AI system was permitted to do. NIST's OSCAL-COMPASS material describes controls as rules tested against evidence, linking policy-as-code and compliance-as-code. That is a technical model, not a legal requirement, but it shows why evidence is easiest to produce at the point where the decision is made.

Where Trussed fits

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, with allow, redact, block, rate limit and escalate for human approval. Policy is enforced at runtime, not reviewed after the fact, and the scope is individual interactions and tool calls. Enforcement generates audit-ready evidence mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST. Deployment is self-managed in the customer cloud, with configurable retention and data residency.

Trussed has run continuously in production at a regulated enterprise for more than 18 months, with 99.95% uptime on live production traffic. The criteria above apply to any control you evaluate, including this one.