Preventive vs Detective AI Controls: Definitions and Examples

Definitions applied to AI interactions

In classic control taxonomy, a preventive control reduces the chance that a disallowed event occurs, and a detective control reveals that one has occurred. A corrective or recovery control then limits the impact and restores a safe state. The taxonomy is not unique to AI, and the NIST AI RMF itself lists detective controls alongside compensating, deterrent, directive and recovery controls as options when responding to AI risk. The preventive and detective mapping in this guide is an editorial application of that vocabulary, not framework wording.

The useful unit for AI is the individual interaction or tool call. A prompt is submitted, a model responds, an agent invokes a tool, an MCP server returns data. Each step is an event, and each event can be evaluated against policy at one of two moments: before it takes effect or after. A preventive control sits at the first moment and can change the outcome. A detective control sits at the second and can only report on it.

This matters because the two are often treated as interchangeable. A dashboard that flags a prompt containing regulated data after it reached an external model is a detective control. It does not make the disclosure preventive, however fast the alert arrives.

How the two control types differ

The differences are easiest to see across four dimensions. The evidence row describes what each mechanism naturally produces, not a requirement set by any specific framework.

• Timing: Preventive: evaluated before the action takes effect. Detective: evaluated after the action has occurred.
• Mechanism: Preventive: enforcement in the execution path that can allow, redact, block, rate limit or escalate. Detective: analysis, alerting and review of recorded activity.
• Outcome: Preventive: the disallowed action does not complete, or completes in a modified form. Detective: the action has completed and the response is investigation or correction.
• Evidence output: Preventive: a record of the decision made on each interaction or call, and the policy applied. Detective: findings, alerts and review outcomes over recorded activity.
• Main failure mode: Preventive: overly broad rules that block legitimate work, or gaps where policy is not enforced. Detective: delay between event and discovery, and harm that cannot be undone.
• Best suited to: Preventive: high-impact, irreversible or regulated actions. Detective: lower-impact risks, novel patterns and verification that preventive controls work.

Preventive AI controls: examples

Preventive AI controls examples share one property: the decision is made before the model, tool or user receives the result of the disallowed action.

Prompt and response redaction removes sensitive data from content before it reaches a model or returns to a user. Blocking applies when redaction is not enough, for instance when a request would send restricted material to a model that is not approved for it. Both operate on the individual interaction.

Least-privilege tool scoping limits what an agent can do before any action occurs. Agent security guidance recommends granting agents the minimum tools a task requires and scoping permissions per tool, such as read-only versus write access and specific resources. A tool the agent cannot call cannot be misused.

Rate and budget limits bound call volume and loops. Unbounded agent loops are a recognised cost and availability risk, and a limit that stops the loop is preventive, provided the behaviour at the limit is defined.

Human approval escalation holds an action until a person decides. Guidance recommends human-in-the-loop controls for destructive, financial, administrative or externally visible agent actions, and says these should go beyond a simple approval prompt. The reviewer needs enough context about the action to make a real decision.

The trade-off is friction. Every preventive rule can block legitimate work, so rules need to be specific to the tool and action category, tested, and tuned from evidence.

Detective AI controls: examples

Detective AI controls examples operate on records of what already happened. They include post-hoc policy violation detection across recorded interactions and tool calls, review of unusual tool-call patterns, sampled human review of model outputs, and periodic audit review of whether approvals and exceptions were handled as designed.

Detective controls have three legitimate roles. They cover risks where blocking is impractical, such as judging output quality or subtle policy breaches that cannot be assessed reliably in real time. They find what preventive rules missed, which feeds rule improvements. They also verify that preventive controls are operating, by showing that the interactions that should have been blocked or redacted were.

Their limit is built in. Detection cannot reverse a disclosure or an executed write to a production system. Reliance on after-the-fact review alone means every incident is discovered only once it has already happened, so the response is corrective rather than preventive.

The NYDFS industry letter on AI-related cybersecurity risk describes layered controls with overlapping protections, so that if one control fails, others are there to prevent or mitigate the impact. Preventive and detective controls fit that model: one stops, the other catches what the first did not.

What to require of runtime enforcement and its evidence

Runtime AI policy enforcement means the policy decision is made in the path of the interaction, not afterwards. When evaluating an approach, ask which actions are stopped or modified before execution and which are only recorded for later review. Ask how permissions are scoped per agent, tool and resource, which action categories require approval and what the approval step contains, and what happens when a limit is reached. Define the behaviour at predetermined limits explicitly. The EU AI Act describes technical robustness solutions that let a system safely interrupt its operation when it operates outside predetermined limits.

Evidence is the second requirement. For high-risk systems, the EU AI Act requires a risk management system that is established, implemented, documented and maintained, and it describes that system as continuous and iterative, with significant decisions and actions documented. It also requires that people can effectively oversee high-risk systems in use, so approval and escalation paths need to be designed in. Preventive controls should produce a durable record of each decision and the policy behind it. Detective controls should produce findings and review outcomes. Both need retention that can be reviewed during an audit. These regulatory points are stated as of October 2026, and provision-specific obligations should be checked against the current text for each system.

Trussed is one example of this approach. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, with actions to allow, redact, block, rate limit or escalate for human approval, at the level of individual interactions and tool calls. Enforcement generates continuous audit-ready evidence mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST. It deploys self-managed in the customer cloud, with configurable retention and data residency.