向一个在生产环境中运行 AI 智能体的团队提出四个问题。 它实际上做了什么？它现在还被允许做什么？你如何向客户证明这一点？你能多快让它停下来？ 如今，大多数诚实的回答都只是耸耸肩。智能体使用一个长期有效的密钥进行认证，它的权限范围在某个配置文件里一次性定下，而它的历史记录，取决于作者碰巧写了哪些日志。
Agentic Trust & Protection Platform（ATPP）就是我们对这四个问题的回答。它分为三层，值得准确说明其中哪些今天已经可用，哪些仍处于预览阶段。
第 1 层——不是共享密钥的身份
每个已注册的智能体都会获得自己的 SPIFFE 风格身份和一个短期有效的签名凭据，而不是一个放在环境变量里的 API 密钥。每个智能体的身份都是唯一的，因此“是哪个智能体干的？”有了答案；身份还会轮换，因此泄露的凭据会自然过期。
第 2 层——它所做之事的签名记录
智能体工作时，它的操作会被上报，并在一个仅追加的账本中转换为签名的信任状态事件。徽章由该账本生成——智能体处于授权范围内时显示绿色，越界时显示红色——另有一份验证文档，让其他人可以离线核验签名。签名的意义在于：这份记录不只是智能体所有者的一面之词。
需要明确这一层的性质：它是一份 记录。它能快速、可验证地告诉你某个智能体越出了范围。但它本身并不能阻止那个越界的请求——等到被上报时，那个请求早已发出。
第 3 层——ATPP Enforce，一道检查关卡（预览版）
ATPP Enforce 将决策前移到请求之前。一个内联网关会依据智能体的授权评估每一个出站请求，并给出允许、拒绝或暂停的答复。授权是结构化的——主机、方法、路径以及请求体大小上限——而不只是一份工具名称清单，因为如果你只检查工具，一次通过允许工具发出的攻击看起来就是在范围之内的。以下几项特性我们认为不容妥协：
- 故障即关闭。 没有策略即拒绝。
- 默认只读。 未写明写入方法的规则不允许任何写入，且请求体大小设有上限。
- 任何规则都无法覆盖的拒绝列表 ——云元数据端点和私有地址段始终不可访问。
- 影子模式优先。 在影子模式下会计算同样的决策，但只做记录，因此在真正阻断任何东西之前，你就能看到哪些请求本会被阻断。
磨合期门禁
每一种阻断型控制措施的失效模式，都是让生产环境宕机的误报，因此我们把安全的推进顺序写成了代码中的规则。在网关观察该身份完成了足够时长、足够数量决策的真实工作，并且网关本会阻断的每一个请求都已由运营者复核并认可之前，身份无法从影子模式切换到强制执行。复核按主机和方法分组，因此运营者只需对十几种模式做出裁定，而不是数百行记录。
第三方可核验的回执
经过强制执行的流量会携带一个签名回执请求头。收到智能体请求的网站可以把这个请求头交给我们，并得到三种答复之一：已覆盖且被允许、已覆盖且被拒绝，或根本未覆盖。最后一种答复只有在网站已经判定哪些流量疑似来自智能体时才有意义——范围界定是调用方的职责——但它是 ATPP 中唯一能帮助一个从未采用任何东西的一方的部分。
第三方 MCP 服务器
智能体还会安装并非由它们编写的代码。第三方 MCP 服务器被添加到智能体配置中时几乎未经审查，也没有人为其风险负责：注册表声明不承担责任，作者与安装者之间没有任何关系，而智能体框架把它当作配置来处理。ATPP 会为公开的 MCP 服务器评分，并允许发布方嵌入一个可验证的徽章，让安装者能在添加某个服务器之前先行检查。
我们不宣称什么
这种坦诚是刻意为之的。一个夸大其词的安全控制措施比没有更糟，因为人们会因此不再留意。这与我们对渗透测试发现所遵循的规则相同：说明我们是如何知道某件事的。
试一试
前十个智能体的注册和徽章查看均免费。请从这里开始： trust.redthreadsec.com，或阅读 身份文档 以及 API 参考。如果你运行的智能体会安装第三方 MCP 服务器，并希望成为 Enforce 的设计合作伙伴，请 联系我们。