Default-deny controls for AI agents: why runtime enforcement matters

At a glance

What this is: This is an analysis of why AI agents need default-deny runtime enforcement, with the core finding that prompt guidance and monitoring do not stop unauthorized tool execution.

Why it matters: It matters because IAM, PAM, and AI governance teams need a pre-execution control boundary for agents that can act on systems, not just better logging after the fact.

Context

Default-deny for AI agents means a proposed action is blocked unless policy or human approval explicitly allows it. The governance problem is that many agent deployments still treat prompts, monitoring, and output filters as if they were enforcement, even though those controls do not reliably stop a tool call before execution. In an operational environment, that gap turns AI into an actioning layer rather than a decision-support layer.

The identity angle is real because AI agents increasingly operate like non-human identities with delegated access to internal systems, workflows, and admin tools. That makes runtime authorisation, approval gates, and failure-closed behaviour part of the identity control plane, not a separate observability exercise. For practitioners, the question is whether the agent is governed at dispatch time or only inspected after business impact has already occurred.

Key questions

Q: What breaks when AI agents are not governed at runtime?

A: Without runtime governance, an agent can shift behaviour after provisioning and still execute actions that were never reviewed in context. That is where tool chaining, MCP connections, and rapid decision-making become dangerous. Static approval cannot stop a live change in intent, so teams lose control at the point of action.

Q: Why do default-deny controls matter for AI agent access?

A: They matter because AI agents should ask for access per task instead of operating from broad standing scope. That reduces blast radius, forces explicit policy decisions, and makes it easier to keep agent behaviour aligned to the specific job rather than the user’s full entitlement set.

Q: How do security teams know whether an AI agent control stack is actually working?

A: Look for three things: every agent has a traceable identity, permissions are narrow enough to explain in operational terms, and actions can be audited end to end. If any of those are missing, the control stack is incomplete even if the data layer uses advanced privacy techniques. Identity, scope, and logging should all line up.

Q: When should organisations move from monitor mode to default-deny for AI agents?

A: After they have enough real traffic to understand which tools, arguments, and targets the agent actually uses. Monitor mode is useful for discovery, but it should not become the steady state for production. The move to default-deny should follow coverage analysis, approval design, and simulation against live workloads.

Technical breakdown

Why prompt guidance is not an enforcement boundary

Prompt instructions can shape behaviour, but they cannot independently stop a runtime from dispatching a tool call. In agent architectures, the model proposes an action and the orchestration layer decides whether that action reaches execution. If policy is not attached to the dispatch path, the agent can still trigger writes, deletes, or administrative operations even when the prompt says not to. That distinction matters because governance only exists when the system can deny the call before side effects occur, not when it merely hopes the model self-restrains.

Practical implication: Place enforcement in the orchestration layer that actually sends the tool call, not only in prompts or policy text.

How default-deny works in an agent control plane

Default-deny is a runtime posture where sensitive actions are blocked unless a control, approval, or explicit rule authorises them. The article describes permit, deny, mask, and approval-required outcomes evaluated before execution, with uncovered actions resolving through a no-coverage default. That model is materially different from monitoring because it turns the absence of coverage into a security decision instead of an open door. For production agents, the important design choice is not whether policy exists, but whether the system fails closed when policy is missing, unavailable, or incomplete.

Practical implication: Treat uncovered sensitive operations as denied or approval-gated until you have evidence-based coverage.

Why observability and enforcement must be separated

Observability captures what happened. Enforcement determines whether it is allowed to happen. The article is correct to separate the two because traces, logs, and audit events cannot reverse a workflow trigger, record update, or privileged API call that already executed. Runtime governance therefore needs pre-execution checks plus signed evidence after the decision, with evaluation failures failing closed. That is the architecture pattern practitioners should remember: observe everything, but enforce only where the action can still be stopped.

Practical implication: Use observability for assurance and investigation, but require pre-dispatch authorisation for any action with business side effects.

Threat narrative

Attacker objective: The objective is to induce an AI agent to execute an unauthorised operational action that creates real business impact.

1. Entry occurs when an AI agent receives a request and proposes a tool call against enterprise systems.
2. Credential or privilege abuse follows when that proposed action reaches a write-capable, delete-capable, or administrative function without an explicit approval gate.
3. Impact occurs when the agent triggers a workflow, mutates a record, or invokes admin tooling before any human or control can stop the side effect.

Breaches seen in the wild

• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Default-deny is the right governance model for operational agents. Once an AI agent can call tools and change systems, the security problem is no longer unsafe text generation, it is unauthorised execution. That shifts control responsibility from prompt engineering to runtime authorisation and approval design. Practitioners should treat the dispatch path as the governing boundary for agent identity and privilege.

Observability-first programmes create a false sense of control. Logging, tracing, and moderation are useful, but they do not prevent a workflow from firing or a record from changing. This is the same structural weakness we see when organisations equate inspection with enforcement in other identity systems. The practical conclusion is that audit trails must support control decisions, not substitute for them.

Runtime enforcement changes AI agents from loosely supervised assistants into governable non-human identities. That is the key identity insight in this paper. When an agent can act on behalf of a business process, it needs a clear authority boundary, a failure-closed mode, and approval handling that matches the risk of the operation. Security teams should stop asking whether the model is well behaved and start asking whether the action path is constrained.

Default-deny is not a starting state, it is a migration target. The article correctly frames the rollout problem: you do not flip all actions to deny on day one without breaking production. Mature programmes begin with monitor mode, then tighten uncovered writes, deletes, and admin functions based on evidence. The practitioner takeaway is to measure coverage growth and enforcement drift as a core governance metric.

AI agent control gaps should be named as dispatch-path governance gaps. The useful concept here is not simply

What this signals

Agent runtime governance is becoming the practical boundary for AI security. As more agents move from summarising work to doing work, the control question shifts from content safety to execution safety. Security leaders should expect their AI governance programme to absorb authorisation, approval, and failure-closed behaviour as first-class requirements.

Default-deny creates a usable pattern for governing non-human identities. The important shift is that the agent is no longer treated as a conversational interface but as an identity-bearing system that can affect production state. That means governance has to follow the action path, with policy tied to dispatch rather than intent.

Monitor-first migrations will remain the realistic adoption path. Most enterprises cannot flip every agent to deny on day one, so the programme challenge is sequencing. Teams should use coverage data to decide which operations can stay permissive, which need approval, and which must be denied outright.

For practitioners

• Implement dispatch-path authorisation for agent tool calls Evaluate every proposed tool call before execution and block or pause sensitive actions until policy or human approval authorises them. Keep the control in the orchestration layer that actually dispatches the action.
• Start new agents in monitor mode only Allow first-contact agents to observe and record decisions without blocking, then use that telemetry to define safe coverage before tightening writes, deletes, and admin operations.
• Tighten uncovered operations by risk class Set no-coverage defaults separately for read, write, delete, and admin actions so high-risk operations fail closed while low-risk reads remain easier to operationalise.
• Treat approval as a governance control, not a workflow delay Use human approval for sensitive actions that affect money, production, credentials, or administrative state, and require the denial outcome to be enforceable before side effects occur.
• Test failure-closed behaviour before production cutover Simulate evaluation errors, lost control bundles, and unconfirmed agents so you can verify that the runtime denies actions rather than guessing or falling back to permissive execution.

Key takeaways

• AI agents become a governance problem when they can execute actions, not just generate text, and that changes the control point from output review to pre-dispatch authorisation.
• Monitoring and prompt guidance are useful, but they do not stop side effects once a workflow, update, or administrative call has been sent.
• A monitor-first migration can work, but only if teams use real runtime evidence to move uncovered sensitive actions into approval or deny states.

Key terms

• Default-Deny Posture: A default-deny posture starts from the most restrictive access state and only opens specific permissions when there is an approved need. For endpoint governance, it means standard user access is the baseline and elevation is the exception, not the operating model.
• Dispatch-path enforcement: Dispatch-path enforcement is the practice of placing authorisation checks on the exact runtime step that sends a proposed action to a tool or system. It matters because prompts and monitoring do not stop execution on their own, but the dispatch path can deny, pause, or mask a call before it runs.
• Fail-closed runtime policy: Fail-closed runtime policy means an agent cannot continue acting when the policy decision service is unavailable or unreachable. The design is deliberate: if authorisation cannot be checked in real time, execution stops rather than defaulting to permit, which is the safer model for high-risk agent tool use.
• Monitor Mode: A transitional operating state in which actions are observed and recorded but not blocked. It is useful for discovering real agent behaviour, but it is not a production control because it does not prevent the action or limit the side effect.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need a rigorous way to govern non-human access across modern security programmes.