为什么安全智能体需要自己的底座

过去几年，Agent Runtime成为智能体基础设施领域的核心议题。从LangGraph Runtime到各类云厂商的Agent平台，业界已经建立起一套相对成熟的能力体系：检查点、任务恢复、沙箱隔离、权限控制、模型调用、状态持久化。这些能力解决了一个根本问题——如何让Agent稳定、持久、可扩展地运行。

概述

然而，当Agent真正进入代码审计、漏洞挖掘、内网横向移动、应急响应、APT溯源等安全场景后，一组更深层的问题浮出水面：Runtime可以知道一个任务"能不能执行"，却不知道一个安全动作"应不应该执行"。这种差异并非功能缺失，而是领域语义的本质区别。

五大安全语义缺口

通用Runtime缺失的并非具体功能，而是安全任务的领域语义。第一个缺口在于对对抗性输入的理解：安全Agent面对的往往是恶意源码、攻击者留下的日志、木马样本、Exploit等本身就可能主动攻击Agent的对象。攻击者完全可以在代码注释中植入Prompt Injection指令，或在日志中写入针对LLM的对抗性内容。因此，安全底座必须从架构层面明确一条原则——Untrusted Artifact ≠ Instruction，即被分析对象永远只是数据，不能天然升级为Agent的控制指令。

授权边界与动作语义

第二个缺口是授权范围与网络权限的区分。传统Runtime通过IAM、ACL、网络策略控制进程能访问什么资源，但安全任务还有另一层约束：授权范围Scope。例如一次渗透测试可能明确授权example.com和特定IP段，但Agent请求目标地址后可能经历DNS跳转、302重定向，最终到达完全不同的域名。通用Runtime无法判断这些"发现"的资产是否属于授权范围。真正的授权边界必须是一种不可绕过的执行约束，类似于操作系统中的Reference Monitor——所有高风险能力都必须经过不可绕过的授权检查点，且必须遵循Fail Closed原则。

认知状态与证据体系

第三个缺口涉及安全动作的执行语义。通用Runtime强调Durable Execution，支持checkpoint、retry、resume等能力，这在通用场景下非常合理。但安全场景中并非所有动作都可以安全重放——触发漏洞利用、创建测试账号、修改权限、执行Payload等动作具有明显副作用。安全底座需要为每种Tool定义Action Semantics，包括risk_level、side_effect、idempotency、replay_policy等属性，从而决定能否执行、是否需要审批、是否允许重放、失败后如何恢复。

如有侵权，请联系删除。