Uber 的 Agent 安全实践：有权限执行，不代表符合用户本意

来自 @UberEng 一如既往的优质分享：Uber 的内部安全体系 Secure AI，不只检查智能体有没有权限，还检查具体动作是否符合用户请求。它把上线前审查、运行时约束和持续测试结合起来，但没有公布量化防护效果。
https://www.uber.com/us/en/blog/securing-ai-agents/

为什么传统权限不够

智能体会读取网页、文档、工具结果，再自行决定下一步。即使账号、工具和接口调用都合法，它仍可能被外部内容里的恶意指令带偏，执行用户根本没有要求的操作。

因此，身份认证和授权之外，还需要回答：这个动作为什么发生，依据来自用户，还是来自不可信内容？

三层防护怎么配合

1. 上线前明确边界。 AI Registry 登记智能体的用途、负责人、允许的行为和风险等级；Argus 分析代码、提示词与工具调用路径，对照申报用途和实际能力。第三方工具、MCP 服务器和模型也要接受安全检查。

2. 运行时核对动作。 AI Guard 结合用户请求、角色、会话上下文和智能体用途作判断，再由运行时组件执行。关键设计是把高权限动作追溯到用户实际提出的请求，防止网页或文档中的指令冒充授权。为控制延迟，Uber 使用本地小型专用模型，并行执行多项检查。

3. 上线后持续校准。 系统追踪动作、工具调用和防护判断，通过历史交互回放测试新规则，再结合红队测试调整策略。提示词和回复仅在必要时保存，并采取敏感信息处理、访问限制和到期删除措施。

难点不是检测，是取舍

规则过严会拦住正常工作，过松又会漏掉攻击。Uber 采用先观察、不拦截的影子模式，并按不同智能体逐个校准，而不是依赖统一阈值。

团队也承认：防护只能降低风险、提高攻击成本，对新型提示词注入的效果仍较难预测。全文没有公开拦截率、误拦率或延迟数据，因此应把它看作部署经验，不能当成有效性的完整证明。