当AI代理走向现实世界，安全边界该如何重建？

这场来自 AI Engineer 的分享，直面一个正在失控的问题：当 AI Agent 不再只是聊天，而是代表用户调用 API、操作系统、执行交易，安全体系还能沿用老一套吗？Bobby 和 Cam 用真实架构、失败隐患和现场 Demo，给出了基于开放标准的答案。

从“会聊天”到“真干活”，AI Agent 正在撕裂旧安全模型

为什么 AI Agent 的安全问题突然变得如此紧迫？Bobby 一开场就点破关键转折：Agent 已经不再停留在对话框里，而是“moving beyond chat and actually doing things in the real world”。一旦 Agent 开始调用 API、触发工作流、修改真实系统，传统的身份与访问控制立刻显得力不从心。

他们总结了当前团队最常踩的几个坑：密钥被直接塞进 prompt、Token scope 过大、出了问题却“没有足够的数据回溯发生了什么”。在表面一切正常的情况下，风险往往是“直到安全事故发生那一刻才暴露出来”。Bobby 用一句话概括这种失控感：“Things might look fine on the surface， right up until there’s a security incident.”

更深层的风险来自 OWASP 所称的“Excessive Agency”（过度代理）。本质并不复杂——只是“给了 Agent 太多权限，却没有护栏”。这里的权限不是抽象概念，而是非常具体的能力：调用哪些 API、读取哪些数据、使用哪些 Token、是否能触达真实凭证。一旦这些能力没有被清晰限定、监控、且绑定到具体用户，Agent 就会变成一个无法追责的高危自动化程序。

这也是为什么他们反复强调一个变化：Agent 不是在“代表你的应用”行动，而是在“代表具体的用户、具体的个人”行动。安全模型如果不能反映这一点，问题只是迟早会爆发。

一个共享密钥的反面教材：为什么“能跑”远远不够

为了让问题更直观，Bobby 给出了一个几乎所有团队都用过的模式：Agent 从环境变量里读一个共享 API Key，然后直接调用下游服务。这种方式“works， but it’s fragile”。

脆弱在哪里？首先，你根本不知道“是谁做了什么”。一个 Key 被多个用户、多个环境、甚至多个服务复用，日志失去了身份语义；其次，密钥轮换变成高风险的人工操作；更致命的是，权限范围往往大到离谱，一旦泄露，后果不可控。

对比之下，他们给出的改进方案并不复杂，但意义重大：Agent 不再直接持有长期密钥，而是向后端请求“只属于某一个用户、某一个 API、且短生命周期”的访问 Token。后端通过 Token Exchange（令牌交换）来签发这个 Token，用完即失效。

这一小小的流程变化，带来了三个质变：第一，你终于有了“谁在什么时候、以谁的身份做了什么”的审计记录；第二，Token 可以轻松轮换，不再牵一发动全身；第三，这种模型可以自然扩展到“几十甚至上百个 Agent”。正如 Bobby 所说：“It’s a small tweak in your flow， but a big step up in how you handle risk.”

真正缺失的不是 Token，而是“Agent 的身份”

在演讲的中段，Bobby 抛出了一个更根本的问题：如果 Agent 本身没有清晰的身份，那么无论 Token 管理得多好，控制依然是假的。

身份的价值不在于认证本身，而在于“把一次动作连接回一个真实用户”。只有这样，你才能理解发生了什么、追踪责任、并决定下一步该如何处理。如果回答不了“这个 Agent 到底在为谁工作？”，那它几乎一定只是一个 service account——而这正是“Confused Deputy（混淆代理）问题”的温床。

他们给出的解决路径并不是自创体系，而是坚定地回到开放标准：OAuth 2.1、RAR（Rich Authorization Requests）以及 Token Exchange。核心思想是：Agent 不保存密钥，只在需要行动时向后端求助；后端从安全存储中取出凭证，为“特定用户 + 特定资源”铸造短期 Token；Token 用完即弃，从不长期停留在 Agent 手里。

Bobby 的态度非常明确，也带着一点工程师式的固执：“You should never invent the wheel with identity.” 身份与授权是少数几乎没有试错空间的领域，能用标准，就不要自作聪明。

从 RAG 到交易 Agent：一次真实的用户确认流程

理论之外，这场分享最有价值的部分来自 Cam 的现场 Demo。为了让问题足够“真实”，他们构建了一个本地 AI 交易助理：Agent 可以调用券商服务买股票，但前提是——用户必须明确同意。

这里引入了一个听起来有些拗口的机制：Client Initiated Backchannel Authentication（CIBA，演讲中也口误成 SIBA）。它解决的是一个现实问题：当 Agent 在后台运行、没有界面时，如何获取用户授权？答案不是弹窗，而是由授权服务器向用户的可信设备（比如手机）发送通知。

在 Demo 中，Agent 发起交易请求后，用户会收到一条包含上下文信息的通知：发生了什么、将要执行什么操作。用户可以选择批准、拒绝，或者要求更多信息。Cam 特别强调，这种异步确认“is a very key component”，因为它让 Agent 的能力始终被人类兜底。

同样的思路也被用在 RAG 系统中：访问控制不应该发生在 LLM 内部，而应该在检索层就被严格执行。Agent 不负责决定“能不能看”，它只负责在被允许的前提下“如何用”。这条边界，决定了数据是否会悄无声息地泄露。

总结

这场演讲并没有给出一个“银弹式”的 Agent 安全方案，反而不断提醒我们回到基本原则：身份先于权限，标准重于巧思，人类必须保留最终控制权。当 Agent 越来越像一个“数字员工”，安全体系也必须升级为“以用户为中心”的委托模型。对所有正在构建 AI Agent 的团队来说，现在补上这一课，远比事后补救要便宜得多。

关键词： AI Agent， AI安全， OAuth 2.1， Token Exchange， CIBA

事实核查备注： 演讲者：Bobby Tiernay、Cam Sween；关键概念：Excessive Agency（OWASP）、OAuth 2.1、RAR、Token Exchange、CIBA；案例：共享 API Key vs 短期 Token、AI 交易助理 Demo、RAG 检索层授权；原话引用需核对英文转写准确性。