核心事件：Agent权限安全基础设施加速成熟

随着AI Agent从简单对话走向实际生产操作（如写代码、调API、操作Git、部署K8s），权限与安全运行已成为阻碍其落地的核心挑战。2026年9月，NVIDIA推出Open Agent Safety Platform，将OpenShell作为其核心安全运行时组件发布。与此同时，学术界与开源社区的多个项目构成了多层次的Agent安全基础设施生态：

• AIOS（LLM Agent Operating System）：学术界早期探索，提供Agent调度、上下文/内存管理与访问控制的统一Kernel层
• NVIDIA OpenShell：已可运行Claude Code、Codex、OpenCode、GitHub Copilot CLI等主流Agent，支持Linux/macOS/WSL2，后端可选Docker/Podman/MicroVM/K8s
• Agent Sandbox派：基于容器/VM/MicroVM构建隔离环境，限制Agent可执行的命令与可访问的资源
• Sandlock：直接利用Linux Kernel原生安全原语，无需root、cgroups或Namespace即可实现细粒度限制
• AgentOS：在Ubuntu等基础上组合Sandbox/AppArmor/Credential Vault/Audit等形成专用Agent运行环境

权限控制范式的重大转变：从“资源权限”到“行为权限”

传统权限模型通常以“用户-角色-资源”为层级，例如管理员可读写订单表。而Agent的权限模型正演进为“任务-策略-工具-行为-资源”的多层结构：

• Coding Agent对GitHub：可读、创建分支、提交、创建PR，禁止合并至生产分支
• 对数据库：仅允许SELECT，禁止UPDATE与DELETE
• 对Kubernetes：可查询Pod、查看日志、重启Pod，禁止删除命名空间

OpenShell的Policy机制已实现HTTP层面的行为级控制：例如允许GET /repos/xxx，但禁止POST /repos/xxx/issues。这种从“是否允许访问GitHub”到“是否允许执行此HTTP方法”的精细化控制，标志着Agent安全进入行为权限阶段。

值得注意的是，Linux并非被替代，而是被增强。OpenShell等项目明确选择在现有基础设施（Linux/K8s/容器）之上构建一层Agent Runtime，而非重写内核或创建全新操作系统。这既降低了落地门槛，也延续了现有生态的成熟度。

多层次架构图谱：不同项目解决不同层次问题

多层次Agent安全架构可抽象为五层：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

AI Agent
   ↓
Agent Framework（任务编排）
   ↓
Agent Runtime（执行环境）
   ↓
Agent Security / Policy（权限控制）
   ↓
Sandbox（隔离机制）
   ↓
Linux Kernel（原生安全原语）
   ↓
Hardware

各代表性项目定位清晰：

Sandlock的轻量化设计尤为值得关注：它不依赖重虚拟化技术（无需root/cgroups/镜像/强制Namespace），启动更快、资源消耗更低，对大量短生命周期Agent极具意义。

企业落地建议：按场景选择安全方案

• 近期可落地：选择OpenShell或Sandbox方案。若已有容器/K8s基础设施，可在其上快速集成；需细粒度网络与API级别的控制时，OpenShell的Policy机制是成熟选择
• 中长期关注：AIOS类框架适合构建大规模多Agent调度平台；Sandlock类内核方案适合对启动延迟和资源开销敏感的场景；AgentOS适合构建标准化的Agent部署平台
• 适合谁用：企业级AI应用、生产环境中的Coding Agent、需满足合规审计要求的金融/医疗场景
• 建议再等等：若当前Agent仅用于内部演示或测试环境，尚未涉及真实数据操作，可等待更成熟的标准化接口出现；超轻量场景则需评估Sandlock等新生项目是否满足稳定性和兼容性要求

写在最后

Agent能力的提升已非唯一焦点，企业真正关心的是‘敢不敢给权限’。模型层的迭代与安全层的基础设施建设将构成AI Agent落地的双引擎——前者决定Agent能做什么，后者决定它能安全地做到什么程度。