Uber 分享 Agent 安全实践 Secure AI 的三层防护设计
Uber 的 Agent 安全实践:有权限执行,不代表符合用户本意
Uber Engineering 分享了内部智能体安全体系 Secure AI,除检查智能体权限外,还核对具体动作是否符合用户请求,由上线前审查、运行时约束和持续测试三部分组成,但未公布量化防护效果。上线前由 AI Registry 登记智能体用途、负责人、允许行为和风险等级,Argus 分析代码、提示词与工具调用路径;运行时 AI Guard 结合用户请求、角色、会话上下文和智能体用途判断,并用本地小型专用模型并行检查以控制延迟。团队采用先观察不拦截的影子模式并按智能体逐个校准,同时承认防护只能降低风险,对新型提示词注入的效果仍较难预测。
查看原帖https://t.co/XFWteI3jUO
查看原文
https://t.co/XFWteI3jUO
正文
Uber 的 Agent 安全实践:有权限执行,不代表符合用户本意
来自 @UberEng 一如既往的优质分享:Uber 的内部安全体系 Secure AI,不只检查智能体有没有权限,还检查具体动作是否符合用户请求。它把上线前审查、运行时约束和持续测试结合起来,但没有公布量化防护效果。 https://t.co/iyVjrkQAge
为什么传统权限不够
智能体会读取网页、文档、工具结果,再自行决定下一步。即使账号、工具和接口调用都合法,它仍可能被外部内容里的恶意指令带偏,执行用户根本没有要求的操作。
因此,身份认证和授权之外,还需要回答:这个动作为什么发生,依据来自用户,还是来自不可信内容?
三层防护怎么配合
1. 上线前明确边界。 AI Registry 登记智能体的用途、负责人、允许的行为和风险等级;Argus 分析代码、提示词与工具调用路径,对照申报用途和实际能力。第三方工具、MCP 服务器和模型也要接受安全检查。
2. 运行时核对动作。 AI Guard 结合用户请求、角色、会话上下文和智能体用途作判断,再由运行时组件执行。关键设计是把高权限动作追溯到用户实际提出的请求,防止网页或文档中的指令冒充授权。为控制延迟,Uber 使用本地小型专用模型,并行执行多项检查。
3. 上线后持续校准。 系统追踪动作、工具调用和防护判断,通过历史交互回放测试新规则,再结合红队测试调整策略。提示词和回复仅在必要时保存,并采取敏感信息处理、访问限制和到期删除措施。
难点不是检测,是取舍
规则过严会拦住正常工作,过松又会漏掉攻击。Uber 采用先观察、不拦截的影子模式,并按不同智能体逐个校准,而不是依赖统一阈值。
团队也承认:防护只能降低风险、提高攻击成本,对新型提示词注入的效果仍较难预测。全文没有公开拦截率、误拦率或延迟数据,因此应把它看作部署经验,不能当成有效性的完整证明。