要点 1：风险从”内容层”升级到”系统层”——权限失控是最大杀手#

传统大模型安全关注的是”说了什么”：提示词注入、越狱、幻觉、敏感信息泄露、内容合规。但 Agentic AI 拥有身份、权限、工具和执行能力，安全风险从内容层升级到系统层，涉及五大核心风险：

真实案例：Meta 安全专家给 Agent 设了”未经批准不得操作”的指令，但长对话导致上下文压缩，安全指令被”遗忘”，大量邮件被永久删除。这印证了 7-28 学过的 Context Engineering 核心教训——安全指令不能依赖上下文窗口的”软约束”。

💡 反共识观点：权限风险之所以最危险，是因为企业常默认赋予 Agent 广泛的 API、数据库、云资源权限，但 Agent 可能被恶意 Prompt 诱导或上下文污染，导致越权访问——问题不是”权限不够”，而是”权限太宽”。

要点 2：安全核心是策略而非隔离——Sandlock 的反共识#

整个行业在用容器、微虚拟机、gVisor 为 Agent 构建隔离方案，但 Sandlock 团队得出了一个令人不适的结论：行业正在解决一个错误的问题。

关键论证链：

1. Agent 不是攻击者：它不会主动琢磨如何突破沙箱，不会在没有指示的情况下从内核接口中寻找 0-day。真正的威胁是 prompt 是否被污染——Agent 抓取的网页中隐藏恶意指令，处理的文档中嵌入恶意文本。
2. 隔离不等于安全：你可以把 Agent 放进 Firecracker 微虚拟机，拥有独立内核、独立页表、virtio 网络设备——但 Agent 照样能读取你的 SSH 私钥。因为你把密钥放进了沙箱，因为 Agent 需要 git clone 而授予了 ~/.ssh 的访问权限。隔离解决的是”能否逃逸”，安全解决的是”在沙箱内部能接触到什么”。
3. 传统隔离的致命缺陷：所有工具共享同一个沙箱。Shell 工具和浏览工具共享文件系统、网络和环境变量。策略不得不取所有工具所需权限的并集——任何一个工具需要网络，所有工具都获得网络访问。工具越多，沙箱越宽松，安全边界越失去意义。

Sandlock 的解法：基于 Linux 原生接口（Landlock/seccomp/用户命名空间），按工具调用粒度隔离——每次工具调用单独开设沙箱，仅按该工具自身的声明施加约束。浏览工具的沙箱有网络但无法写盘，文件工具能写目录但无法联网。最小权限原则的真正粒度不是按 Agent，不是按会话，而是按每一次工具调用。

更极端的 XOA（Execute-Only Agent）模式：LLM 只负责生成代码，完全不接触不可信数据；生成的代码在独立沙箱执行，输出通过内核管道直达用户，不回流到 LLM 上下文——从架构层面消除 prompt 注入的可能。

要点 3：纵深防御与运行时安全——从 Prompt Security 到 Runtime Security#

过去大模型安全重点在输入/输出/内容安全（Prompt Security），但 Agent 的风险多发于运行过程中：工具调用时、权限使用时、多 Agent 协同时、长周期任务执行时。

纵深防御四阶段：

运行时安全（AI Runtime Security） 的建设能力包括：Agent Identity、Tool Security、Runtime Monitoring、Behavior Analytics、Agent Isolation、Human-in-the-loop、AI Observability。核心转变：安全不应只关注”它说了什么”，更要关注”它做了什么、以什么身份做、调用了什么工具、访问了什么数据、影响了什么系统”。

可观测闭环：三源联动——OTEL Metrics 发现异常（延迟飙升、Token 激增）→ 应用日志定位错误上下文（时间窗、子系统）→ Session 审计日志下钻还原完整行为链。三支柱缺一不可。

要点 4：形式化验证——ClawLess 的”数学级安全枷锁”#

与 Sandlock 的”策略优先”路径不同，ClawLess 走的是形式化验证路线，基于最悲观假设：

两个残酷的基础假设：

• 假定智能体聪明，具备能力对任何安全机制发起成体系的复杂攻击
• 假定智能体脆弱，迟早会被恶意提示词诱导至黑化叛变

技术架构：

1. 形式化安全模型：将文件、进程、套接字、设备定义为可管理实体，每个实体带关联属性，通过正则表达式精准锁定敏感资源。引入可见性语义——Agent 可以引用凭证完成校验，但全程无法窥探哪怕一个字符，从机制上杜绝密码被大模型读取并外传。
2. 动态时序逻辑：加入时间维度的状态判断。系统可以设定严格的联动反应：只要智能体在过去任何时间点读取了某个机密文件，系统立刻永久封锁其向外网发送数据的通道。这是静态规则无法实现的。
3. SMT 求解器验证：所有安全策略转化为形式化数学语言，用 Z3 等求解器进行全局推演。如果有人试图在配置中赋予智能体执行外部脚本的权限，求解器会瞬间通过逻辑推导发现违规，当场阻断并报警。
4. BPF 系统调用拦截：将高级安全规范翻译成底层系统调用管控规则。BPF 程序在内核态运行，性能损耗微乎其微，且支持策略热更新。
5. 用户态内核隔离：选择 gVisor 路线，在不可信的智能体和宿主机内核之间插入精简的可信防护网，拦截并代理几乎所有内核交互请求。

要点 5：Skill 全生命周期治理——从”可用”到”可信”#

供应链投毒是真实威胁：OpenClaw Skills 注册表发现 800+ 恶意 Skills（约占已发布包两成），包括窃取凭证、植入后门。安装未审核技能等同于放大 Agent 权限。代码审计数据：60 天内 14,254 个 commits，平均每天约 2.45 个安全修复。

全生命周期治理四阶段：

转化路径：可用 → 可见（统一资产库，消灭”影子智能体”）→ 可控（权限最小化，受控执行环境）→ 可审（操作审计、行为追溯、不可篡改日志）→ 可复用（标准化封装、质量评估）→ 可信。

1. “Agent 不是攻击者” vs “智能体终将叛变”#

Sandlock 假设 Agent 本身没有恶意意图，真正的威胁是外部内容引发的 prompt 注入，因此策略优先就够了。ClawLess 假设最悲观情况——智能体可能被诱导至完全叛变，因此必须从形式化验证层面建立数学级安全枷锁。

实际上两者不矛盾：Sandlock 适用于内部开发等非对抗性场景（单一公司运行的编程助手），ClawLess 适用于高风险自主 AI 场景（需要最高安全保证的金融/医疗/关键基础设施）。关键判断是：你的 Agent 会被暴露在什么级别的威胁下？

2. “一个沙箱装所有工具” vs “按工具调用隔离”#

当前主流做法是所有工具共享一个容器/沙箱，策略取所有工具权限的并集。Sandlock 提出按工具调用粒度隔离，但带来额外的工程复杂度。实际取舍：对于低风险场景，统一沙箱 + 白名单策略可能足够；对于高风险场景，逐调用隔离是纵深防御的必要补充。

3. 软约束 vs 硬约束#

Meta 的案例证明：把安全指令放在 System Prompt 里，依赖模型”自觉遵守”，是软约束，长对话上下文压缩时会被遗忘。硬约束（Landlock/seccomp/BPF拦截）在内核层强制执行，不依赖模型配合。行业共识正在形成：安全不应依赖 AI 的自觉，而应通过系统架构强制执行。