Notifications
Clear all
Topic starter
21/08/2026 4:48 pm
TL;DR: AI agents become risky at execution time, when tool calls can touch files, hosts, and credentials, and observability-driven sandboxing can turn those actions into traced, policy-checked capability requests, according to Arize analysis. The governance shift is from trusting model intent to controlling and auditing runtime side effects.
NHIMG editorial — based on content published by Arize: How Observability-Driven Sandboxing Secures AI Agents
Questions worth separating out
Q: How should security teams govern AI agents that can access enterprise systems?
A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring.
Q: Why do AI agents create new risk in non-human identity management?
A: AI agents create risk because they operate as software identities with delegated authority, but many organisations do not track them with the same discipline applied to users or service accounts.
Q: How do security teams know if an AI agent sandbox is actually working?
A: A working sandbox should stop execution, block privilege expansion, and prevent the agent from touching sensitive context even when the model is manipulated.
Practitioner guidance
- Define runtime capability boundaries Restrict each agent tool to a narrow set of allowed file paths, hosts, and write destinations so the runtime can enforce task-scoped access instead of broad session trust.
- Instrument every policy decision Emit trace events for allow, deny, and escalate outcomes, including rule ID, reason, and resolved path, so security teams can reconstruct the exact decision chain.
- Separate secrets from agent workspaces Keep credentials and configuration files out of directories an agent can read by default, and deny any capability that would let the agent reach active secrets during execution.
What's in the full article
Arize's full article covers the implementation detail this post intentionally leaves at the governance layer:
- Reference Python wrapper for converting tool calls into structured capability requests and policy decisions
- Detailed tracing fields and Phoenix annotations used to reconstruct allow, deny, and escalate outcomes
- Concrete workspace, network, and write-control policy examples for sandbox enforcement
- Validation scenarios showing path traversal, prompt injection, and multi-step bypass attempts
👉 Read Arize’s analysis of observability-driven sandboxing for AI agents →
AI agent sandboxing with runtime tracing: are your controls keeping up?
Explore further
21/08/2026 5:07 pm
Runtime authorisation is now the real control plane for AI agents: once an agent can invoke tools, language safety no longer constrains impact. The meaningful control becomes whether each requested side effect is authorised, blocked, and recorded before it executes. That is why observability-driven sandboxing belongs in agentic AI governance, not just in developer tooling discussions. Practitioners should treat tool invocation as a privileged event, not a benign API call.
A question worth separating out:
Q: What should organisations do when an agent tries to access credentials or sensitive files?
A: Block the access at runtime, log the policy reason, and keep the decision visible in the trace so you can assess whether the agent is being steered into an unsafe path. Then tighten workspace scope, file permissions, and secret placement so the same request cannot succeed on retry.
👉 Read our full editorial: Observability-driven sandboxing gives AI agents auditable runtime control
