Core Event: Agent Security Infrastructure at System Level Takes Shape
As AI Agents evolve from simple chat interfaces to actual production operations—including writing code, calling APIs, operating Git, and deploying K8s—the challenges of permission control and secure execution have become central barriers to real-world adoption. In September 2026, NVIDIA launched the Open Agent Safety Platform, positioning OpenShell as its core secure runtime component. Meanwhile, a multi-layered ecosystem of open-source projects is collectively building the infrastructure for safe Agent operation.
Key initiatives include:
- AIOS (LLM Agent Operating System): An early academic exploration providing an integrated Kernel layer handling Agent scheduling, context/memory management, and access control
- NVIDIA OpenShell: Already capable of running Claude Code, Codex, OpenCode, and GitHub Copilot CLI; supports Linux/macOS/WSL2 with flexible backends including Docker, Podman, MicroVM, and Kubernetes
- Agent Sandbox variants: Built on containers, VMs, or MicroVMs to isolate Agent execution and restrict both permissible commands and accessible resources
- Sandlock: Leverages native Linux kernel security primitives directly, eliminating the need for root privileges, cgroups, or namespaces
- AgentOS: Combines sandboxing, AppArmor, credential vaults, and audit capabilities into a unified, Agent-specialized environment on top of Ubuntu or Linux
Paradigm Shift: From Resource-Based to Behavior-Based Permissions
Traditional permission models follow a hierarchy: user → role → resource (e.g., admin can read/write orders table). Agent permissions are evolving into a multi-layer structure: task → policy → tool → action → resource.
Concrete behavior-level controls already emerge:
- Coding Agent on GitHub: May read, create branches, commit, and open PRs—but prohibited from merging to production branches
- On databases: SELECT-only, with no UPDATE or DELETE permissions
- On Kubernetes: Can query pods, read logs, restart pods—but cannot delete namespaces
OpenShell’s Policy system enables HTTP-level behavioral granularity: for instance, permitting GET /repos/xxx while blocking POST /repos/xxx/issues. This transition—from “allowed access to GitHub” to “allowed to perform this specific HTTP verb”—marks the entry into behavior-based access control for Agents.
Notably, Linux is being augmented, not replaced. OpenShell and similar projects explicitly build atop existing infrastructure (Linux/K8s/containers) rather than rewriting the kernel or creating alternative operating systems. This approach reduces adoption friction while leveraging mature ecosystem components.
Multi-Layer Architecture: Different Projects Address Different Layers
The Agent security stack can be abstracted into five layers:
| |
Project positions are clearly differentiated:
| Category | Representative | Primary Focus | Typical Implementation |
|---|---|---|---|
| Agent OS | AIOS | Resource scheduling for large-scale Agent management | Agent Scheduler + Context/Memory/Storage management |
| Secure Runtime | OpenShell | Secure execution and policy enforcement | Declarative Policy + runtime interception |
| Sandbox | Container/VM variants | Environment isolation | Docker/Podman/MicroVM/K8s |
| Kernel-Level Security | Sandlock | Lightweight restrictions without root | Linux kernel primitives (Seccomp, AppArmor, etc.) |
| Integrated Solution | AgentOS | Dedicated Agent hosting platform | Combined sandbox/AppArmor/Vault/audit |
Sandlock’s lightweight design stands out: By avoiding heavy virtualization (no root/cgroups/images/mandatory namespaces), it offers faster startup and lower resource overhead—critical for scenarios involving many short-lived Agents.
Enterprise Adoption Guidance: Match Solutions to Use Cases
- Immediate adoption candidates: OpenShell or Sandbox-based approaches. Organizations with existing container/K8s infrastructure can integrate quickly; OpenShell’s policy mechanism is especially valuable for fine-grained network and API-level control
- Watch for mid-term: AIOS-style frameworks suit large-scale multi-Agent orchestration platforms; Sandlock-like kernel-level solutions serve latency- and resource-sensitive scenarios; AgentOS fits standardized Agent deployment patterns
- Who should proceed now: Enterprise AI applications, production Coding Agents, and industries requiring compliance auditing (financial services, healthcare)
- Who should wait: Internal demos or test environments without real data exposure may defer adoption until standard interfaces mature; ultra-lightweight scenarios should assess Sandlock derivatives for production stability and compatibility
Final Thoughts
Agent capability increases are no longer the sole focus—the real question enterprises ask is ‘dare we grant permission?’ The dual-engine model of AI Agent adoption is emerging: model-layer iteration determines what Agents can do, while security-layer infrastructure determines what they can safely do.
