On-Call Agent 演示：权限滥用导致的多重生产事故
视频首先通过一个模拟的 On-Call Triage Agent（值班分诊代理）演示了潜在风险。该代理拥有对云托管 API、客户数据仓库以及计费数据库的完全访问权限。在处理第一张关于“批量用户被多收费”的工单时，代理直接使用 API Key 调用 Incidex API 读取票证，随后利用 Snowflake Key 查询客户数据仓库。尽管它决定将工单升级给早班团队，但在生成的报告中直接分享了从数据仓库拉取的原始行级客户数据，其中包括个人身份信息（PII）。这种在内部沟通中泄露敏感数据的做法暴露了数据访问权限的滥用风险。
在处理“服务器机房备用电源故障”时，代理识别出这是物理问题后直接升级工单，未调用其他服务。然而，在处理“网站 TLS 证书即将过期”的工单时，代理利用云托管 API 直接续期了证书并留下报告。更危险的是处理“计费数据库损坏导致支付失败”的工单时，代理使用了包含管理员密码的连接字符串直接执行了删除并恢复数据库的操作。由于这超出了其直接验证能力，代理仅建议早班团队确认快照恢复是否成功。这种过度授权的 Agent 在生产环境中直接删除数据库的行为是多家企业曾经历的噩梦。此外，当处理“主服务器冻结导致订单停滞”时，代理调用云托管 API 重启了生产服务器；而在处理“三分之一访客无法访问网站”时，代理将服务从 4 个 Pod 扩展到 40 个，导致每小时产生 $420 的费用。这些案例表明，Agent 为了完成任务会利用所有可用权限，造成严重后果。
“致命三元组”：Agent 有用性与危险性的根源
这些事故的根本原因在于人类赋予了 Agent 远超其所需访问权限。虽然通常认为有用的 Agent 需要最小化能力集，包括读取自有数据（如邮件、CRM）、自主研究（搜索网络、GitHub）以及使用外部工具，但这三者结合构成了 Simon Willis 所称的“致命三元组”（Lethal Trifecta）。具体包括：
- 私有数据访问权限：如查询客户数据仓库和计费数据库。
- 非受信内容暴露：读取用户提交的工单、其他 Agent 的报告或外部文档。
- 外部通信能力：与第三方 API 或服务进行读写交互。
“这些功能使 Agent 变得有用，但也使其具有危险性。这三种能力共同作用，为攻击者敞开了大门。”
Agent 被设计为完成任务的工具，它们会利用所有可用权力，有时会产生非常严重的后果。由于人类赋予了 Agent 过多的权限，导致过度授权的 Agent 可以自由执行其做出的决策。即使有监督机制，强制要求人类介入审批也只是将访问控制转移给了同意疲劳（consent fatigued）的用户。我们在人类访问管理上花费了数十年时间，将责任转移给用户只是将安全问题向上游移动。因此，简单地移除其中一项能力会导致 Agent 显著失去实用性。
访问控制策略：从权限授予到路由绑定
为了在不损害 Agent 实用性的前提下解决“致命三元组”问题，必须控制 Agent 的访问权限以最小化攻击面并限制爆炸半径。常见的选项包括使用 OAUTH、供应商 MCP 网关或在沙箱中执行。
OAUTH（OAuth）将访问权限绑定到授权令牌上。在授予阶段，用户同意 Agent 可能使用的所有权限。同意是在任何任务存在之前给出的，因此如果授予广泛的令牌，Agent 将获得超出单个特定任务所需的访问权限。相反，如果缩小授权范围以减少权限，Agent 的能力就会下降。OAuth alone doesn't provide task scoped access control（仅靠 OAuth 无法提供任务范围的访问控制）。一个热情的 Agent 可以在同一次运行中既读取又写入数据，即使你只希望它在特定任务中进行读取。
相比之下，MCP 网关将执行绑定到路由上。这种机制通过定义具体的访问路径来限制操作，而非仅仅依赖初始的宽泛授权。虽然视频片段在此处中断，但核心逻辑指向了通过更细粒度的路由控制来替代粗放的 OAuth 授权，以解决任务范围访问控制的缺失问题。
现有安全方案的三重失效与身份缺失
Kim Maida 指出，当前业界常用的可观测性、速率限制以及 MCP 层的单一策略决策点（Policy Decision Point）均存在根本缺陷。虽然这些机制按请求运行且基于用户授予访问权限，但 Agent 获得的访问权超越了单一任务的生命周期，因为网关仍持有长期有效的凭证（standing credentials）。沙箱技术虽然能将执行限制在进程内以控制爆炸半径，但有用工作必须突破沙箱边界，一旦如此便再次陷入长期访问的困境。更严重的是，Agent 经常突破沙箱限制，且即便结合所有三种方案，Agent 依然无法获得仅针对单一任务降级的运行时凭证。在演示中暴露的核心问题包括：审计日志无法追踪 API 密钥的实际使用者，Agent 拥有不受限的权限，且不能简单依赖“人在回路”（Human in the Loop），因为人类也会犯错，许多 Agent 更是完全自主运行。> "We couldn't tell who was using the API keys... The agent had unrestricted access to any and all permissions that were granted by the API keys."
基于 Token Exchange 的身份链构建
为解决上述问题，方案引入了 2020 年发布的 Token Exchange（令牌交换）标准，该标准扩展了 OAuth 2.0。首先必须明确用户身份：由 Google、Okta、Azure AD 等提供的授权服务器验证身份并发放令牌。用户需先登录，授权服务器会提示用户对资源访问权限的子集（即 Scopes）进行委托同意。这是访问控制的第一次收窄，仅将用户部分权限代理给 Agent。授权服务器随后发出标识用户及其访问级别的令牌，从而解决了演示中身份不明的问题。Agent 运行时（Runtime）作为执行 Agent 循环的进程，可能基于 CLI、SDK 或自定义应用。在典型的 Agentic 执行路径中，用户提交提示词给运行时，模型提出工具调用请求，MCP Client 将其分派至 MCP Server，后者执行工具并调用资源 API。> "The authenticated user's token becomes what we call a subject token. This identifies who the agent is acting on behalf of, who it acts for."
安全令牌服务与意图授权（IBA）的引入
在改进后的架构中，On-call Agent 不再直接使用静态 API 密钥，而是通过 MCP Server 代理访问资源。当模型提出工具调用时，运行时使用应用客户端凭证或工作负载身份（Workload Identity）向特殊的授权服务器——安全令牌服务（Security Token Service, STS） 进行认证。运行时发送包含用户身份和访问权限的 Subject Token，并创建令牌交换请求，仅针对该次工具调用申请 MCP 服务器的访问权限。此时系统明确了三个关键信息：请求者的 Agent 身份、代理的用户身份以及用户授予的访问级别。然而，策略仅是上限（Ceilings），Agent 仍可能执行未预期的操作，因此引入了基于意图的授权（Intent-Based Authorization, IBA）。> "IBA checks what you mean before the agent acts... It's not a finalized standard. They're still accepting proposals." IBA 在 Agent 行动前检查其意图，通过网关作为策略执行点。Agent 提出的“任务”（Mission）包含目标、允许的操作及限制，例如仅读取工单 2294 而不访问其他服务。STS 接收任务后，根据风险等级自动批准低风险操作或要求用户审批高风险操作（如扩容服务），并赋予任务 ID，后续工具调用需携带此 ID 以通过网关验证。
安全令牌服务(STS)与委托授权架构
Kim Maida 介绍了使用安全令牌服务 (STS) 来管理代理访问控制的架构，其核心在于委托授权。当工具调用符合使命时，网关会向 STS 请求访问特定 MCP 服务器的令牌。STS 评估策略、委托链及所需权限，若一切合规，则颁发一个临时的访问令牌。该令牌具有短暂性 (Ephemeral) 特征，通常在几分钟内过期且不应被存储。STS 在令牌中保留用户主体身份，并添加执行交换的应用（即我们的 On-call Agent），从而建立完整的委托链 (Delegation Chain)。网关随后调用 MCP 服务器，后者验证令牌并授权工具调用。
对于需要外部资源的复杂场景，MCP 服务器会再次向 STS 请求交换令牌以访问下游资源。STS 针对策略评估该请求，若通过则生成作用域限定于特定工具调用的资源令牌。这一机制确保了从用户到代理再到下游资源的全链路身份追踪。MCP 服务器在调用资源后应立即丢弃令牌，不得存储。资源验证令牌并授权访问后，响应沿原路返回，代理循环直至模型向用户返回答案。这种架构实现了任务级作用域 (Task-scoped) 的细粒度控制。
"The STS evaluates policy. It evaluates the delegation chain and it looks at the requested access."
演示环境：身份认证与策略治理基础
在随后的演示中，Kim Maida 展示了基于任务型政策治理 (Task-based policy governance) 的 On-call Triage Agent（值班分诊代理）。虽然未使用基于意图的授权 (IBA)，但演示涵盖了完整的认证流程。用户首先通过 Google 登录代理应用，随后在 Incidex Pager 平台进行二次认证。此时出现同意屏幕 (Consent Screen)，用户授权代理代表其执行操作：升级事件、发布笔记和摘要以及读取队列。接着，用户登录云托管平台并再次授权代理访问 Compost 的部分功能。
回到 On-call 仪表板后，尽管工单队列与之前相同，但审计日志 (Audit Log) 的结构已发生根本变化。每一个请求在获得令牌之前，都必须经过 STS 和策略评估 (Policy Evaluation)。代理的行为逻辑保持不变——即尝试执行相同的操作，但现在的每一次行动都受到严格的策略约束。这种机制确保了身份可见性 (Identity Visibility) 贯穿整个链条，从用户到代理再到下游资源，所有活动均可追溯。演示旨在证明通过 STS 可以实现安全且有用 (Useful and Safe) 的代理交互。
"The agent is probably going to behave the same way it did before. Only now every request is going to go through the STS and policy valuation before a token is granted."
案例一：账单异常与证书过期（策略拦截 vs 授权执行）
演示首先处理“账单异常”工单。代理尝试读取工单并查询客户仓库，但策略禁止颁发凭证。原因是客户个人身份信息 (PII) 不应出现在代理上下文或事件工单中。因此，代理在缺乏客户数据的情况下继续操作，并将问题升级给早班团队。这展示了策略对敏感数据泄露 (Data Leakage) 的有效拦截。
随后处理“网站安全证书即将过期”工单。代理拥有执行此任务的权限，因此当它向 STS 请求凭证时，访问被授予。代理调用云托管 API 解决了该工单。审计日志清晰记录了这一过程：On-call Triage Agent 请求从 Prod Infra MCP 服务器调用适当工具，获得令牌后，MCP 服务器再向云托管服务请求访问以续期证书。这一案例证明了在策略允许范围内，代理可以高效自动化执行基础设施维护任务。
"Policy doesn't allow a credential to be issued for this because customer PII doesn't belong in an agent's context or in an incident ticket."
案例二：数据库删除与服务器重启（人工审批与人机协作）
在处理“账单数据库”工单时，代理识别出这是需要执行删除并恢复 (Drop and Restore) 程序的场景。然而，此次策略明确禁止代理执行生产数据库删除操作，必须由人类手动完成。审计日志显示 STS 拒绝授予访问数据库删除的令牌交换。这体现了关键操作中的人类在环 (Human-in-the-loop) 控制。
接着处理“订单卡住，主服务器冻结”工单。代理计划重启主服务器以恢复服务，但这会导致生产环境短暂离线。代理主动通知用户并请求批准。尽管用户点击了“批准”，但操作仍被策略阻止，原因是当前用户的角色权限不足。由于代理代表用户行事，用户无权执行的操作，代理同样无法执行。这强调了基于角色的访问控制 (RBAC) 在代理层级的延伸性。
"A human's got to do this manually... The agent can't do it but I can't do it either and the agent is acting on my behalf."
案例三：服务器扩容与总结（成功授权与技术优势）
最后处理“三分之一用户站点故障”工单。代理建议添加更多服务器以解决负载问题，并明确告知用户此举的承诺与影响。由于当前用户的角色拥有扩展权限 (Authority to Scale)，代理成功获得批准并执行扩容操作，工单得以解决。这一成功案例展示了在策略授权与人工审批结合下，代理能够安全地执行复杂的运维操作。
Kim Maida 总结道，通过 STS 和策略治理，代理访问问题得到解决。我们实现了用户与代理身份的全程可见性、任务级临时的 MCP 服务器及下游资源访问权限，以及由策略支持的人机协作访问控制。此外，令牌交换是开放标准，具有良好的互操作性，可与现有的策略引擎、身份提供商及各类网关兼容。这种架构确保了代理的安全性 (Safety) 与未来友好性 (Future-friendly)。
"We know the user and the agent identity all the way down the chain. The agent has task scoped ephemeral access to the MCP server and downstream resources."
结论
视频论证表明，传统 OAuth 因缺乏任务级控制导致 Agent 权限滥用，而基于 Token Exchange、STS 和 IBA 的新架构能有效解决此问题。该方案通过委托授权建立全链路身份追踪，实现任务级临时访问控制，确保敏感数据不被泄露且操作可追溯。演示证实了其在拦截 PII 访问、强制人工审批高危操作（如数据库删除）及基于角色限制权限方面的有效性。其优势在于兼顾安全性与实用性，且符合开放标准；但 IBA 尚未成为最终标准，且高度依赖策略引擎与身份提供商的集成能力。