Observability-driven sandboxing gives AI agents auditable runtime control

At a glance

What this is: Arize argues that AI agent safety depends less on what the model plans and more on what the runtime is allowed to execute, with traced sandbox policies turning tool calls into enforceable capability requests.

Why it matters: This matters because IAM and AI security teams need controls that govern agent actions at execution time, not just prompts or outputs, especially where file access, network calls and write permissions can expose sensitive data or credentials.

Context

AI agent risk changes when planning turns into execution. Once an agent can read files, contact hosts, or call tools, the control problem shifts from language safety to runtime governance, because the harm comes from side effects rather than generated text.

Traditional isolation such as VMs and containers constrains the environment, but it does not always make individual tool decisions visible or auditable. That creates a governance gap for agentic AI programmes: teams may know an action was blocked, but not which policy applied, which path the agent tried, or why the runtime allowed or denied it.

Key questions

Q: What breaks when AI agents are allowed to execute tools without kernel-level restrictions?

A: Without kernel-level restrictions, an agent can be tricked into calling files, binaries, network services, or internal APIs that were never meant to be exposed. Application-layer guardrails are easier to bypass because the agent can be manipulated through prompts. Kernel enforcement blocks unauthorized syscalls and creates a reliable audit trail for denied actions.

Q: Why do traced sandbox decisions matter for AI agent governance?

A: Because without traces, a denied or allowed action becomes a one-off event that teams cannot explain, tune, or audit. Traced decisions show which rule fired, what resource was requested, and how the agent behaved after denial. That makes agent controls governable instead of merely restrictive.

Q: How should security teams stop AI agents from using approved tools to exfiltrate data?

A: Security teams should assume approved tools can be abused and apply task-scoped restrictions, behavioural monitoring, and strong separation between the agent and writable configuration state. Policy allowlists are not enough if the same tools can package, post, or push secrets. The control objective is to detect misuse of authorised paths before data leaves the environment.

Q: What is the difference between sandboxed and unsandboxed AI agent execution?

A: Sandboxed execution limits what an AI agent can do by isolating commands, files, network access, and system privileges from the host environment. Unsandboxed execution lets the agent run with broader account authority and direct system access. For security teams, the difference determines whether a malicious instruction is contained or can immediately affect endpoints, cloud resources, and credentials.

Technical breakdown

Runtime sandboxing for AI agents

Runtime sandboxing places a policy enforcement layer between agent inference and side effects. The agent can still plan and choose tools, but each tool invocation is evaluated before execution against rules such as workspace boundaries, host allowlists, or write restrictions. This differs from static containment because the decision is made at the moment of action, when the system knows the exact file, host, or resource being requested. The result is a capability model rather than a pure prompt model: the agent requests a right to act, and the sandbox decides whether that right exists for that specific request.

Practical implication: govern agent privileges at the point of tool invocation, not only at deployment or prompt design.

OpenTelemetry tracing as an audit layer

Tracing turns policy enforcement into an observable control. Each allow or deny decision can be emitted as a span or annotation, with metadata such as the rule applied, the reason for the decision, and the resource that triggered it. That matters because agent systems often retry, replan, or shift tools after a denial, which makes one-off logs insufficient. An execution trace preserves the sequence of decisions and side effects, allowing teams to reconstruct what the agent attempted and where control boundaries held. Observability is not the control itself, but it is what makes the control governable at scale.

Practical implication: capture policy decisions in traces so security and engineering teams can investigate agent behaviour as a sequence, not a black box.

Capability checks for file, network and write access

The article’s policy model treats each tool call as a structured resource check. A file read becomes a path request, a network action becomes a host request, and a write becomes a modification request, each of which can be allowed, denied, or escalated by code. That matters because agent abuse usually emerges through ordinary operations rather than exotic exploits. If the runtime can distinguish safe workspace reads from unsafe path traversal, or approved hosts from arbitrary exfiltration targets, it can contain misuse without changing the model. The security boundary becomes explicit and testable.

Practical implication: define separate controls for file scope, outbound network destinations, and write authority instead of treating them as one generic permission set.

Threat narrative

Attacker objective: The objective is to use agent runtime capabilities to reach sensitive files, credentials, or external destinations through ordinary tool behaviour.

1. Entry occurs when an AI agent is given tool access that can reach the file system or external hosts, moving risk from generation to execution.
2. Credential or data exposure can follow when the agent reads workspace files that include environment configuration or active credentials without needing an exploit.
3. Escalation happens when repeated tool retries or multi-step actions attempt to move from an allowed read into an unsafe write or exfiltration path.
4. Impact is unauthorized access, leakage, or side effects that occur through legitimate-looking tool calls rather than through model output alone.

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.
• AI agent retail card theft campaign 2026: AI agents breached 27+ retailers for about $25 each, used cloud keys and a Secrets Manager dump, and stole 600,000+ payment cards.

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

Observability-driven sandboxing is really a capability-governance model for AI agents. The security question is no longer whether the model can reason about a task, but whether the runtime should allow each discrete action it proposes. That moves control from prompt review to execution policy, which is the right place to govern agentic behaviour. For practitioners, the key implication is that agent identity and action scope must be enforced at the moment of use, not inferred after the fact.

Auditability changes the control value of sandboxing. A deny decision that cannot be traced is operationally weak because teams cannot explain why the agent failed or repeated the attempt. Tracing every policy check creates evidence for investigation, tuning, and accountability, which is especially important when an agent replans after being blocked. For identity and AI governance teams, the lesson is that observability is part of control design, not a reporting extra.

Workspace boundaries, host allowlists and write controls are the concrete failure boundaries for agentic systems. The article shows that the runtime problem is rarely one exotic exploit and more often unscoped ordinary access that lets an agent read, call, or write beyond intent. This creates a named concept worth tracking: execution-time capability drift, where an agent’s effective authority expands through runtime context instead of formal approval. Practitioners should treat drift as a control failure, not just a safety issue.

AI governance must now include the identity of the action, not just the identity of the actor. Agent systems can be authenticated and still unsafe if every tool call inherits broad privileges. That is where the identity angle becomes material: NHI-style governance concepts such as scoping, approval, and revocation need to apply to agent-issued capabilities, not only to the agent service account itself. For teams building agent controls, the practical conclusion is that the entitlement being exercised matters as much as the entity exercising it.

From our research library:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Execution-time capability drift: agent risk now appears when ordinary tool authority expands through runtime context, not only when a model is poorly prompted. That makes policy enforcement a live control problem for AI governance teams, because the dangerous moment is the action boundary, not the answer boundary.

A practical programme should assume that auditability and restriction travel together. If a sandbox cannot explain why it blocked a request, the team will struggle to tune policies, investigate repeated denials, or prove that the control is behaving consistently across tools and sessions.

AI agents without least-privileged runtime access are materially more likely to create incidents than those constrained to their intended scope, according to the 2026 Infrastructure Identity Survey. The implication for practitioners is straightforward: scope agent capabilities first, then instrument and review what remains.

For practitioners

• Define runtime policy gates for tool calls Interpose policy checks between agent inference and execution so every file, host, and write request is allowed or denied before side effects occur.
• Trace every allow and deny decision Emit policy decisions as spans or annotations with rule ID, reason, and resource context so investigations can reconstruct the full execution path.
• Scope file access to explicit workspaces Block reads and writes outside approved directories, including path traversal attempts, so the agent cannot inherit ambient filesystem reach.
• Separate network and write authority Use distinct allowlists for outbound hosts and modification rights so a permitted read cannot become an unmanaged exfiltration or overwrite path.
• Test denial handling under retry and bypass attempts Validate that blocked actions stay blocked when the agent replans, retries, or combines steps such as read-then-exfiltrate sequences.

Key takeaways

• AI agent risk emerges when execution authority is broader than intended, because tool calls can create side effects even when the model’s language output appears safe.
• Tracing policy decisions makes sandboxing operationally usable, since teams can see what the agent attempted, which rule applied, and why the action was blocked or allowed.
• The most durable control is runtime scoping of file, network and write actions, because that narrows what an agent can do regardless of how it plans or retries.

Key terms

• Observability-Driven Sandboxing: A runtime control pattern that evaluates each agent tool call before it executes and records the decision as traceable evidence. It combines enforcement with telemetry so teams can see what was requested, what rule applied, and whether the action was allowed, denied, or escalated.
• Capability request: A structured representation of an agent action that can be checked before execution. Instead of treating a tool call as an implicit privilege, the system translates it into a request for a specific action, resource, and context, then applies policy to decide whether it may proceed.
• Execution-Time Policy Enforcement: Execution-time policy enforcement checks each proposed action immediately before it runs and blocks anything outside policy. This approach matters for autonomous agents because it still works when the agent is in a permissive mode or operating on untrusted inputs. It turns written rules into a real control.
• Policy Trace: An audit record that captures the inputs, rule decisions, and outcomes of a control check. For agent systems, policy traces help explain why an action succeeded or failed and provide the evidence needed to investigate repeated denials, retries, or boundary violations.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle, secrets management, and the control patterns that matter when non-human actors gain runtime authority. It helps practitioners align agent and machine identity governance with the programmes they already run.