AI agents now open pull requests, query databases, call APIs and run shell commands on their own. That makes AI agent sandboxing and AI agent identity two of the most urgent topics in IT security right now. Gartner even named “AI Agent Identity” one of its top strategic technology trends for 2027, predicting that by 2028 around 25% of enterprise security incidents could stem from AI agent misuse.

In this guide we cover the new tools announced in the past few weeks and a practical blueprint to run agents safely.

Why Agents Need a Sandbox

An AI agent is effectively untrusted code generated at runtime. It can be manipulated through prompt injection, poisoned documentation or malicious tool output. Recent incidents show the risk is real – for example, an attack on the OpenCode agent tool stole some users’ API keys. A sandbox limits the blast radius: even if an agent is tricked, it can only touch what you explicitly allowed.

New Agent Sandboxing Tools (Late 2026)

Tool	What it does
gVisor (now in CNCF)	User-space kernel that isolates containers; donated by Google to the CNCF on Nov 5, 2026 alongside Agent Substrate
NVIDIA OpenShell	Runtime that puts agents in isolated environments with policy; being integrated into Red Hat OpenShift and Red Hat AI
AWS Strands Box	Open-source agent sandbox with a policy engine called Dogwood
1Password for Agents	Credential brokering so agents never see raw secrets

Blueprint: 6 Layers of Agent Safety

1. Isolate execution

Run agent tool calls in a sandboxed container or microVM, never directly on a developer laptop or production host. On Kubernetes, use a gVisor runtime class:

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: gvisor
handler: runsc
---
apiVersion: v1
kind: Pod
metadata:
  name: agent-runner
spec:
  runtimeClassName: gvisor
  automountServiceAccountToken: false
  containers:
  - name: agent
    image: my-agent:1.0
    securityContext:
      runAsNonRoot: true
      readOnlyRootFilesystem: true
      allowPrivilegeEscalation: false
      capabilities: { drop: ["ALL"] }

2. Restrict the network

Default-deny egress and allow only the APIs the agent truly needs:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: agent-egress
spec:
  podSelector: { matchLabels: { app: agent-runner } }
  policyTypes: ["Egress"]
  egress:
  - to:
    - ipBlock: { cidr: 10.0.20.0/24 }   # internal API gateway only
    ports: [{ port: 443, protocol: TCP }]

3. Give every agent its own identity

Stop sharing a human’s personal access token or a long-lived service account. Issue each agent (or each task) a distinct identity with short-lived, scoped credentials – for example via OIDC workload identity in your cloud, or a credential broker.

4. Least privilege per task

A code-review agent needs read access to the repo – not permission to merge to main or read production secrets. Define permissions per task, not per agent product.

5. Human approval for irreversible actions

Require a human click for actions like deploying, deleting data, sending external messages or spending money. This is the core of what Gartner calls an “agent coding harness”.

6. Log and audit everything

Record every tool call, its inputs and outputs. When something goes wrong you need to answer “what did the agent do, and why?”

Quick Checklist

• Agents run in sandboxed containers or microVMs.
• Egress is default-deny with an allowlist.
• Each agent has a unique identity and short-lived tokens.
• Secrets are brokered, never pasted into prompts or env files.
• Destructive actions require human approval.
• Full audit logs are retained.

Conclusion

AI agent sandboxing is quickly becoming as fundamental as HTTPS. The good news: the ecosystem is maturing fast, with gVisor in the CNCF, OpenShell coming to OpenShift and new open-source options like AWS Strands Box. Combine isolation with proper agent identity and human approvals, and you can enjoy the productivity of AI agents without handing them the keys to the kingdom.

Related: AI Coding Agent Security in 2026: Stop MCP Prompt Injection.