AI Agent 高危操作防护：用 Emilia Protocol 实现人机协作审批
一个 8 万美元的 Wire 转账
想象一下：你的 AI Agent 正在执行一个自动化任务，突然它决定向一个账户发送 82,000 美元的汇款。在大多数系统中，这直接发生了——没有二次确认，没有人类审批，只有 Agent 的一句”已完成”。
这不是科幻场景。随着 AI Agent 被赋予越来越多的权限——访问数据库、操作生产环境、发送 API 请求——高危操作的管控成了一个现实且紧迫的问题。目前的身份验证方案（OAuth、API Key、JWT）只能回答”谁在操作”，但回答不了”这个具体的高危操作是否应该被允许”。
问题的本质：授权粒度缺失
传统安全模型有一个根本性缺陷：认证 ≠ 授权。在 AI Agent 场景下，这个问题被放大了：
| 维度 | 传统方案 | AI Agent 场景的问题 |
|---|---|---|
| 身份认证 | 验证用户身份 | Agent 执行时没有”实时人类在场” |
| 权限控制 | 固定角色权限 | Agent 动态决策，权限需求不固定 |
| 操作审计 | 事后日志 | 只记录结果，无法在事前拦截 |
| 防篡改 | 忽略 | Agent 可以修改自己的配置文件绕过限制 |
EMILIA Protocol（EP）就是为了填补这个缺口而设计的——在 AI Agent 执行高危操作之前，确保一个具体的人类签署了明确的审批，且这个审批结果可以在任意设备上离线验证。
EMILIA Protocol 是什么
EMILIA Protocol 是一个开放协议（Apache 2.0），提供”预操作信任执行”（pre-action trust enforcement）。它不是另一个身份平台，也不是钱包或社交信誉层——它是让 AI Agent 在执行不可逆操作前，先通过加密仪式获得人类明确批准的标准协议。
一句话描述：在 Agent 做任何不可逆的事情之前，让一个有名字的人签署明确的”同意”，并生成一份任何设备都能验证的收据。
项目地址：github.com/emiliaprotocol/emilia-protocol
协议有三套独立的参考实现——JavaScript、Python 和 Go——三者在每次 CI 推送中都证明对标准对抗向量有一致的处理，这是 IETF 级别的标准门槛。
核心架构：三层协议栈
EP 由三个核心层组成：
EP Core（核心标准）
三个可互操作的对象：
- Trust Receipt（信任收据）：一个已观察到的与信任相关的事件的便携记录。回答了”发生了什么”。
- Trust Profile（信任档案）：可观察的信任状态的标准化摘要。回答了”已知什么”。
- Trust Decision（信任决策）：经过策略评估的结果，包含原因和申诉路径。回答了”现在该做什么”。
第三方可以实现这三个对象并与协议互操作——这就是标准的真正检验。
EP Extensions（可选扩展）
在高风险工作流中提供更强的执行保障：
- Handshake：绑定操作者身份、授权上下文、策略、精确操作内容、Nonce、过期时间和一次性消费的预操作授权流程
- Accountable Signoff：在需要人类最终所有权时，要求具名人类签署
- Commit：原子性、不可变操作关闭
- Delegation & Attribution：委派与归因
EP Product Surfaces（产品层）
参考实现和商业层，包括开源运行时、云控制平面和企业部署层。
EP 的设计哲学非常清晰：Core 是最小的可互操作标准。Extensions 是你选择加入的更强执行保障。Product Surfaces 是建立在协议之上的工具——不是协议本身。
快速上手：一条命令集成到 Claude Code
EP 提供 MCP Server 集成，只需一条命令：
npx -y @emilia-protocol/mcp-server
在 Claude Code 或 Cursor 中配置 MCP 服务后，你的 Agent 在执行高危操作前会自动发起 Handshake 审批流程。
更直接的体验方式：在本地运行内置的碰撞测试：
git clone https://github.com/emiliaprotocol/emilia-protocol cd emilia-protocol node examples/crash-test.mjs
这个测试模拟一个 AI Agent 试图发送 82,000 美元的 Wire 转账——EP 的策略引擎会拦截它，要求人类签署审批，生成 Trust Receipt 供离线验证，而任何伪造的收据都会验证失败。
五步审批流程
EP 的核心工作流包含五个步骤：
- 创建策略（Create Policy）——定义什么行为属于”高危操作”，需要什么级别的人类审批
- 发起握手（Initiate Handshake）——Agent 检测到高危操作，主动触发审批请求
- 提供证据（Present Evidence）——Agent 提供当前操作的完整上下文信息
- 验证（Verify）——人类审批者在自己的设备上验证操作的合法性
- 签署并消费（Signoff and Consume）——人类签署审批，一次性消费该授权
整个过程形成了一个加密约束链：操作者身份 → 授权上下文 → 策略评估 → 精确操作绑定 → 一次性消费。
技术指标：不止是概念
EP 不是一个”我们会做到的”项目，而是一个已经过严格测试的协议：
| 指标 | 数值 |
|---|---|
| 自动化测试 | 3,672 个测试，覆盖 142 个文件 |
| TLA+ 安全属性 | 26 个已验证（T1-T26），零错误 |
| Alloy 关系断言 | 35 个事实，22 个断言 |
| 红队测试用例 | 85 个已归档 |
| 已修复安全发现 | 31 个 |
| Handshake p95 延迟 | 575ms（50 个并发用户） |
npm 验证包 @emilia-protocol/verify 零外部依赖、Apache 2.0 许可，可在浏览器中直接运行——只需
四大高危操作场景
EP 的设计锚定在四个具体的高风险行为上下文中：
| 场景 | 示例 |
|---|---|
| 政务场景 | 支付目标变更、福利重定向、管理员覆盖 |
| 金融场景 | 受益人变更、收款地址修改、资金审批 |
| 企业场景 | 生产环境权限变更、密钥轮换、权限升级 |
| AI / Agent 场景 | 破坏性工具调用、自主不可逆操作 |
对于 AI Agent 开发者和运维者来说，最后一类是最直接的——当你的 Agent 获得了 DELETE FROM production.users 或 transferFunds() 的能力时，EP 提供了一个轻量的授权闸门。
实战：将 EP 集成到 Agent 工作流
1. 安装验证包
npm install @emilia-protocol/verify
2. 创建策略
在你的 Agent 配置中定义高危操作的策略规则。例如：所有涉及金额超过 $1,000 的操作需要二级审批。
3. 配置 MCP 服务
在 Claude Code 的 ~/.claude/settings.json 中注册 MCP 服务：
{
"mcpServers": {
"emilia": {
"command": "npx",
"args": ["-y", "@emilia-protocol/mcp-server"]
}
}
}
4. 测试审批流程
启动 Claude Code 并执行一个被策略标记为”高危”的操作——EP 会自动弹出审批请求，等待你通过 Face ID 或其他设备验证签署。
5. 验证信任收据
任何第三方都可以在你的网站上验证信任收据：
GET /.well-known/ep-trust.json GET /.well-known/ep-keys.json
或直接在浏览器中打开 emiliaprotocol.ai/verify 粘贴收据内容。
与现有方案对比
| 能力 | EP | API Key + 审计日志 | OAuth/SSO | Guardrails |
|---|---|---|---|---|
| 预操作拦截 | ✅ | ❌ | ❌ | 部分 |
| 离线验证 | ✅ | ❌ | ❌ | ❌ |
| 防重放攻击 | ✅ | ❌ | ❌ | ❌ |
| 一次性消费授权 | ✅ | ❌ | ❌ | ❌ |
| 开源协议 | ✅ | N/A | 部分 | ✅ |
| 多语言参考实现 | ✅ (JS/Python/Go) | N/A | N/A | 通常单一 |
注意事项
- EP 是协议层而非全栈产品——它定义加密约束和标准格式，业务层（策略管理、审批面板）需要自行构建或使用商业产品
- 2⭐ 的 GitHub 星级反映了项目还处于早期阶段，但 3,672 个测试和 26 个 TLA+ 形式化验证证明了其工程严谨性
- Handshake 流程增加 575ms 的 p95 延迟，适合高价值低频操作而非每一行代码的审批
- 对大多数单体 AI Agent 项目来说，EP 可能过于重量级——它最适合金融、政务、企业生产环境等高合规要求的场景
- 有一个 30 秒在线 Demo 可以在浏览器中直接体验完整流程
总结
EMILIA Protocol 解决的不是一个”高大上”的问题，而是一个非常具体的工程痛点——你的 AI Agent 在做一个不可逆操作前，怎么确保有个人类明确说了”可以”。
在 AI Agent 权限不断膨胀的今天，从”认证谁在操作”到”认证这个操作是否该被允许”的跃迁，可能是安全治理中最被低估的一步。EP 以开放协议 + 三语言参考实现的方式提供了一个可以实操的方案，值得关注 AI Agent 生产安全的开发者一试。