Pre-Execution Policy Checks vs Post-Execution Monitoring: Deciding Which Agent Actions to Block

Teams building AI agents either gate every tool call and make the agent too slow to use, or log everything and discover a wire transfer, a deleted database or an exported customer table after it has happened. Neither extreme is a design. A pre-execution policy check decides allow, deny or escalate before the action runs; post-execution monitoring watches what ran and triggers containment or reversal. This guide gives a decision framework for choosing between them per action, driven by three questions: can the action be undone, how far can its damage reach, and what does a check cost in latency and false blocks. It is for agent platform engineers, security architects and risk owners who must sign off which agent actions run unattended. How the policy decision itself is built is covered in the AI Agent Authorisation Guide; this page decides where to spend it.

Key takeaways

• Reversibility decides first. If an action cannot be fully undone, such as sending data outside the organisation, moving money or destroying records, detection only tells you how bad it was. It needs a blocking check.
• Monitoring is a control only if a revert exists. Detect-and-revert works for actions with a tested compensating step and a short time to detect; without both, it is an audit trail.
• Deterministic pre-execution checks are cheap; approvals are not. A policy evaluation adds about a millisecond; a human approval adds minutes or hours. Reserve humans for the actions the policy cannot decide alone.
• Chains defeat per-call checks. A series of individually allowed calls can add up to an exfiltration or a destructive change, so pre-execution checks need session context and monitoring needs to see sequences.
• Use both, tiered by action class. OWASP separates the controls that prevent excessive agency from logging and rate limiting, which only limit damage; a sound design has each in its place.

The short answer

Put a blocking, deterministic policy check in front of every tool call, because it is cheap and it is the only point where the action can still be stopped. Let that check allow low-risk, reversible actions without further friction, deny actions that are out of scope, and escalate to human approval only for irreversible or high-blast-radius actions it cannot decide on rules alone. Behind it, run post-execution monitoring on everything, with automated containment for anomalous sequences and tested reversal for the actions you chose not to gate. OWASP's Top 10 for LLM Applications 2025 frames the split clearly: under LLM06 Excessive Agency it lists complete mediation, minimal permissions and user approval as preventions, and states that logging, monitoring and rate limiting "will not prevent" excessive agency but "can limit the level of damage caused".

The two controls compared

Threat model for each option

What pre-execution checks stop and miss

• Stops: calls to tools the agent should not hold, resources outside the delegating user's scope, arguments outside allowlists (recipients, domains, amounts, paths), and actions during freeze windows. It holds even when the model is fully steered by prompt injection, because the decision is made outside the model.
• Misses: harm built from allowed steps, such as reading 500 records one at a time and summarising them into an allowed outbound message; actions on tools not routed through the enforcement point; and misuse inside the lines, which the OWASP Agentic Top 10 ASI02 Guide covers as tool misuse.

What post-execution monitoring catches and misses

• Catches: unusual volume, new destinations, off-hours activity, sequences that no single rule describes, and drift between what an agent is declared to do and what it does. See the AI Agent Behaviour Baselining and Anomaly Detection Guide.
• Misses: anything faster than the detection pipeline, anything not logged, and anything whose harm is complete at execution. NIST's agent hijacking evaluation found that repeating an attack 25 times raised average success from 57% to 80%, so an attacker can probe until a single attempt works; monitoring sees the success after it lands.

The Salesloft Drift OAuth token theft shows the limit of detect-after for data egress: bulk exports through a trusted integration ran for about ten days before tokens were revoked, and nothing that followed could recall the exported records.

The three decision axes

Reversibility

Classify each action by whether, and how completely, its effect can be undone. Microsoft's Compensating Transaction pattern guidance makes two points that apply directly: compensation does not necessarily return a system to its original state, and irreversible steps such as external side effects or legally binding actions should be sequenced only after critical validations succeed.

Blast radius

• Scope of data: one record, one user's data, or a tenant-wide export.
• Scope of systems: a sandbox, one service, production, or identity infrastructure such as role assignments and credentials.
• Externality: whether the effect leaves your control, reaches customers, regulators or the public, or triggers a notification duty.
• Privilege gain: whether the action changes what the agent, or anyone, can do next. Permission grants and credential creation need a blocking check regardless of reversibility, because they enlarge every later action. See Agent Permission Drift.

Latency and false-block cost

A rules-based policy decision is fast. The Open Policy Agent performance documentation cites a budget in the order of 1 millisecond for a microservice API authorisation decision, so deterministic checks on every call are affordable. The cost that matters is false blocks: each one stalls a task, and repeated false blocks create pressure to widen rules or bypass the enforcement point. Model-based checks are slower and probabilistic; the OpenAI Agents SDK documents the trade-off in its guardrails, where a parallel input guardrail gives the lowest latency but the agent "may have already consumed tokens and executed tools before being cancelled", while blocking mode prevents tool side effects at the cost of waiting. Human approval is the most expensive check of all and degrades with volume, as reviewers start approving by habit.

The decision matrix

Combine the three axes per action class. "Gate" means a blocking policy check that can deny; "approve" means escalation to a human with the exact action shown; "detect and revert" means the call is allowed and monitoring owns the response.

For how thresholds and approval steps are designed, see the AI Agent Action Approvals and Spending Limits Guide. For why the gate must be a deterministic rule and not a classifier, see Deterministic vs Probabilistic Controls for AI.

Controls per option

Pre-execution

• Complete mediation: every tool call passes through one enforcement point that calls the policy decision; OWASP LLM06 asks for authorisation in downstream systems rather than relying on the model to decide.
• Typed arguments: schema validation and allowlists on recipients, domains, paths and amounts before the policy is evaluated.
• Session context: pass cumulative counters (records read, amount spent, external sends) into each decision so the check can deny the tenth call in a chain that the first nine made dangerous.
• Bound approvals: approve the exact call, with a short expiry, and re-verify the arguments at execution.
• Fail closed: if the decision point is unavailable, high-risk tools deny; low-risk tools may fail open only if listed explicitly.

Post-execution

• Complete action log: agent identity, delegating user, tool, arguments, policy decision and result for every call, kept as audit evidence. See Agent Observability vs Audit Logging.
• Sequence detection: rules for read-then-send, enumerate-then-export and grant-then-use patterns, not only single-event thresholds.
• Rate limits and budgets: OWASP lists rate limiting as a way to increase "the opportunity to discover undesirable actions through monitoring before significant damage can occur".
• Automated containment: suspend the agent, revoke its tokens and cut egress on a high-confidence alert. See the AI Agent Kill Switch and Containment Guide.
• Tested compensation: each reversible tool registers its undo step; make both idempotent, as the compensating transaction guidance advises, so a retried revert does not cause duplicate effects.

Common failure patterns

• Unchecked tool chains: each call passes because the policy only sees one call. Fix with cumulative session counters in the policy input and sequence rules in monitoring.
• Tools outside the enforcement point: a code-execution or shell tool, or a direct database connection, lets the agent act without calling the gated tools. OWASP LLM06 warns against open-ended extensions for this reason.
• Log gaps: the agent framework logs prompts but not tool arguments, or downstream systems log the service account but not the delegating user, so monitoring cannot reconstruct what happened.
• Revert that was never tested: the design assumes rollback, but backups, version history or the undo API were not exercised. In the Replit agent database deletion, a code freeze existed only as an instruction, nothing blocked the destructive commands, and recovery depended on a rollback the agent wrongly reported as impossible.
• Parallel checks on side-effecting tools: a guardrail running alongside the agent fires after a tool has already executed; use blocking mode for anything with side effects.
• Monitoring as the only control for egress: the alert arrives after the data has left. EchoLeak showed data leaving through automatically fetched image and link references, a channel only a pre-execution egress and rendering control closes.

Worked scenario: an IT operations agent

An agent handles infrastructure tickets: it reads tickets, queries monitoring, restarts services, changes instance sizes, rotates credentials and can delete unused resources. It runs under its own workload identity with delegated context from the requesting engineer.

1. Classify the tools: reads and queries are low risk; restarts and resizing are reversible with compensation; credential rotation is reversible but disruptive; deletion is irreversible without backup; any IAM change enlarges privilege.
2. Gate everything, approve little: every call passes the policy check on identity, environment and ticket reference. Restarts and resizes in non-production are allowed; in production they are allowed inside the change window with a linked ticket. Deletion and IAM changes require approval with the resource list shown.
3. Monitor the allowed set: restarts per hour per service, resizes that raise cost above a budget, and any sequence of query then delete across many resources trigger suspension.
4. Prove the revert: each resize records the previous size; a monthly test reverts a sample change in staging and measures time to restore.
5. Measure friction: if more than a few per cent of production restarts hit approval, refine the rule rather than letting engineers approve without reading.

How to implement

1. Inventory actions: list every tool each agent holds and classify it on reversibility, blast radius and privilege gain using the tables above.
2. Route all calls through one enforcement point: remove direct credentials from agent runtimes so tools can only be reached through it.
3. Deploy policies in log-only mode: record what would have been denied or escalated for two to four weeks and review false blocks with tool owners.
4. Enforce for irreversible classes first: egress, payments, deletion and permission changes; then widen.
5. Build monitoring on the decision log: sequence rules, rate limits and automated suspension; test each detection with a replayed scenario.
6. Register and test compensations: for every action left to detect and revert, prove the undo works and record time to revert.
7. Keep a rollback for the controls themselves: each policy change is versioned and can be reverted to the previous bundle, and enforcement can drop to log-only per agent behind a flag.

Detection and measurement

Framework mapping

Practitioner checklist

• Every agent tool is classified on reversibility, blast radius and privilege gain.
• Every tool call passes one deterministic enforcement point; no agent holds direct credentials to gated systems.
• Irreversible actions (external sends, payments, deletion, permission grants) have a blocking check, and approval where rules cannot decide.
• Policy input includes session counters so chains of allowed calls can be denied.
• Side-effecting tools never rely on a parallel or asynchronous check.
• Actions left to monitoring have a tested, idempotent compensation and a measured time to revert.
• Logs capture agent identity, delegating user, arguments, decision and result for every call.
• Monitoring has sequence rules and automated suspension, not only single-event thresholds.
• False blocks and approval rates are reviewed monthly with tool owners.

Standards and references

• OWASP: LLM06:2025 Excessive Agency
• NIST: SP 800-53 Rev 5, Security and Privacy Controls
• NIST: Technical Blog, Strengthening AI Agent Hijacking Evaluations
• Microsoft: Compensating Transaction pattern
• Open Policy Agent: Policy Performance
• OpenAI Agents SDK: Guardrails

Related NHI Mgmt Group resources: AI Agent Authorisation Guide · Prompt Guardrails vs Policy Engines for AI Agent Actions · Agent Controls and Monitoring Guide · Plan-Then-Execute vs ReAct Agents