AI Agent 执行操作如同”裸奔”？Attestor 用零信任边界在每条高风险命令前设一道闸

问题：Agent 的权限太大了

你的 Claude Code 或 Codex Agent 正在自动化处理支付退款、导出客户数据、修改基础设施配置。这些操作一旦出错，后果可能是真实的资金损失或数据泄露。

但问题是——当前 AI Agent 的安全模型非常粗糙：API Key 或 OAuth Scope 在会话开始时一次性授予，之后 Agent 在整个会话期间拥有相同的权限，不管它实际在做什么操作。

这意味着什么？一个 Agent 在写代码时正常，但被 Prompt Injection 诱导后，可以拿着同样的 API Key 去调用退款接口、读取敏感数据、修改生产配置。大模型本身无法区分”用户意图”和”恶意注入”的区别，而静态权限模型给了 Agent 在整个会话期间”畅行无阻”的能力。

Attestor：Agent 操作的零信任边界

Attestor 正是为了解决这个问题而诞生的——它是一个AI 操作控制平面（AI Action Control Plane），在 Agent 准备好操作和实际执行之间，设置一道可编程的零信任边界。

用一句话概括：Attestor 在 Agent 想做任何事之前先”过一遍安检”，只有通过策略、权限、合规、新鲜度、防重放等多项检查的操作才能放行。

它的核心理念来自传统安全领域的零信任架构（Zero Trust Architecture）：不信任任何请求，每次操作都重新验证。

Attestor 的四道安检门

当一个 AI Agent 通过 Attestor 发起操作请求时，Attestor 会返回四种决策之一：

这四道门共同构成了 Agent 操作的执行前拦截（Pre-execution Gate）——任何可能造成实际影响的操作，在到达真实系统之前，都被 Attestor 挡下来做检查。

它覆盖六类操作场景

Attestor 不局限于某一类操作。它的策略引擎覆盖了 AI Agent 可能触及的六大操作类别：

1. 资金操作（Money Movement） — 退款、打款、供应商支付、信用调整。这是风险最高的类别，通常需要人工审批。

2. 数据操作（Data Movement） — 客户数据导出、数据仓库查询、报告发布。防止 Agent 在上下文中”顺手”导出不该导出的数据。

3. 权限变更（Authority Change） — 授权、撤销权限、解锁、委托。Agent 不应该能自己给自己升级权限。

4. 外部通信（External Communication） — 面向客户的邮件、法律通知、计费消息、公开声明。AI 生成的客户沟通内容需要审核。

5. 运维执行（Operational Execution） — 部署、密钥轮换、基础设施变更、事件响应。”Agent 说部署就部署”需要闸门。

6. 可编程资金（Programmable Money） — 智能合约调用、钱包操作、结算指令。Web3 场景的 Agent 操作控制。

快速体验：本地跑一个退款审批流程

Attestor 使用 TypeScript 构建，最简单的上手方式是运行其内置的 Golden Refund 演示：

git clone https://github.com/Open-AGS/attestor.git
cd attestor
npm ci
npm run demo:golden-refund

这个演示会模拟两个退款场景——一个被放行（admit）、一个被阻断（block），展示 Attestor 的完整决策链路：

proposed refund -> Attestor decision -> proof refs -> downstream gate shape

输出包括决策轨迹（检查了哪些策略、为什么放行或拦截）、场景覆盖（正常、证据缺失、证据过期、重复退款、审批拒绝等）、以及证据摘要。

你也可以用 --json 参数查看机器可读的输出格式，了解 Attestor 内部的数据结构：

npm run demo:golden-refund -- --json

更详细地说，Attestor 的决策流程在代码层面是这样工作的——Agent 提交一个操作提案，Attestor 对其做结构化评估：

const admission = createConsequenceAdmissionFacadeResponse({
  mode: 'review',
  actor: 'support-ai-agent',
  action: 'issue_refund',
  domain: 'money-movement',
  downstreamSystem: 'refund-service',
  tenantId: 'tenant_demo_retail',
});
// admission.decision → 'admit' | 'narrow' | 'review' | 'block'

对于完整的生产部署，Attestor 也提供了 Docker Compose 拓扑（API 服务 + Worker 进程 + PostgreSQL + Redis）：

docker compose up

启动后 API 服务运行在 localhost:3700，支持多租户隔离和完整的策略引擎。

对于不想直接拦截的团队，Attestor 提供了影子模式（shadow pilot mode）——在这种模式下，Attestor 只记录决策日志，不实际拦截任何操作。团队可以先观察 Attestor 会如何评估真实操作流，确认策略配置正确后再切换到全拦截模式。

集成方式：不改变现有系统

Attestor 的设计哲学是”与现有系统共存，不强制替换”。它提供了三种集成路径：

路径一：API 网关前置 — 在 Agent 和真实服务之间插入 Attestor API。Agent 先请求 Attestor 评估，通过后再执行真实操作。

路径二：嵌入中间件 — 在现有服务中嵌入 Attestor 客户端 SDK，作为请求进入真实服务前的拦截层（见 examples/customer-middleware/ 目录）。

路径三：影子模式观察 — 先从观察开始。Attestor 监听 Agent 操作日志，给出”本操作会 admit/block/review”的建议，团队据此调整策略，再逐步切换到拦截模式。

数据隐私设计

值得注意的一点：Attestor 是一个控制点，不是数据湖。它只需要结构化的请求上下文和证据引用，不需要 Agent 访问的原始数据。客户的模型、Agent、工作流、数据库、服务调用仍然保留在客户自己的系统中。Attestor 只关注”这个操作该不该放行”以及”为什么”。

适用场景

Attestor 当前处于 v0.3.0-evaluation 阶段，适合：

• 正在将 AI Agent 接入生产环境的团队
• 对 AI 安全有合规要求（EU AI Act、NIST AI RMF）的团队
• 使用 Claude Code / Codex / Cursor 等编码 Agent 且允许其执行有风险操作的团队

总结

AI Agent 的能力越来越强，能触及的操作范围也越来越广。传统的”一把 API Key 用到底”的权限模型已经无法满足生产环境的需求。Attestor 提供了一个结构化的零信任执行边界——不信任每一次操作请求，每次都要过安检。对于需要让 Agent 安全地操作真实系统的团队来说，这是一个值得关注的方向。

参考链接

• Attestor GitHub 仓库
• Attestor 技术白皮书
• NIST AI 风险管理框架