Agent 的致命三角：如何用任务级授权限制越权操作｜Kim Maida

简要描述Brief Description

你的智能体构成了致命三重组合（以及该如何应对）——Kim Maida，KeycardYour Agent Is a Lethal Trifecta (And What to Do About It) — Kim Maida， Keycard

目录Table of Contents

• 权限过大的值班代理
  An overprivileged on call agent
• 数据库删除、重启和扩缩容
  Database deletion, restart and scaling
• 致命三要素
  The lethal trifecta
• 访问控制与长期有效凭证
  Access control and standing credentials
• 缺失的身份标识与令牌交换
  Missing identities and token exchange
• 跟踪 agent 和 MCP 的执行路径
  Following the agent and MCP execution path
• 主体令牌与安全令牌服务
  Subject tokens and the security token service
• 基于意图的授权：一项提案
  Intent based authorization as a proposal
• 临时凭证与委托链路
  Ephemeral credentials and delegation chains
• 使用基于任务的策略重复演示
  Repeating the demo with task based policy
• 数据访问、续期与删除决策
  Data access, renewal and deletion decisions
• 受用户权限限制的审批
  Approval constrained by the user's authority

权限过大的值班代理An overprivileged on call agent

今天我想和大家谈谈，你的代理为何构成致命三要素，以及该如何应对。我们一开始就直接来看一个演示。先介绍一下这个演示的背景：我们要看一个值班分诊代理，它会读取并写入事件值班系统，处理或升级工单。这个代理可以完全访问云托管 API、客户数据仓库以及计费数据库。 这里就是我们的值班分诊代理，它有一个事件队列，里面有待处理的工单。它会读取这些工单；如果能够解决，就会调用它有权限访问的服务来处理。对于无法解决的工单，它会升级给早班团队处理。 我们先看看第一张工单，这是一个计费异常。工单上说，昨晚有一批客户被多收了费用。Today I'm going to talk to you about how your agent is a lethal trifecta and what to do about it. Now we're going to start out right off the bat with a demo. Some context on this demo. We're going to look at an on call triage agent that reads and writes to an incident pager and resolves or escalates tickets. This agent has full access to a cloud hosting API, a customer data warehouse as well as a billing database. So here we have our on call triage agent and it has an incident queue of tickets that it's going to read and then if it can resolve them it's going to call the available services that it has access to and it's going to do so things that it can't resolve it's going to escalate for the morning team. So if we take a look at this first ticket this is a billing anomaly. It says a batch of customers were overcharged last night.

因此，代理首先直接调用 Incidex API 来读取工单。你看这里可以看到，它使用 API 密钥授权访问该 API。然后，它使用 Snowflake 密钥查询客户数据仓库，并决定将工单升级，留待早间审核。接着，它为早班团队撰写报告。正如你所看到的，它正在共享客户数据，对吧？这些行数据是直接从客户数据仓库中提取的，而且它正在向早上值班的团队发送个人身份信息。现在，下一张工单报告的是服务器机房的备用电源故障。代理会再次读取工单。它使用 API 密钥调用工单 API，并判断这是一个物理问题。So the first thing the agent does is it directly calls the incidex API in order to read the ticket. And if you look here, you can see that it authorized access to this API using an API key. It then uses a snowflake key to query the customer data warehouse and it's going to decide to escalate the ticket for morning review. And it writes a report for the morning team. And as you can see, it's sharing customer data. Right? These are rows directly pulled from the customer data warehouse. and it is sending personally identifiable information to the team that is going to be on staff in the morning. Now this next ticket is a backup power supply failed in the server room. The agent is going to read the ticket again. It's using an API key to call the ticket API. It determines that this is a physical problem.

因此，它会升级处理，留待早晨审核，而不会调用任何额外服务。这个案例是网站的 TLS 证书即将过期。它会读取工单，判断警报信息明确。它可以访问云托管 API，并再次使用 API 密钥调用该 API 的证书续期端点。它通过续期证书解决问题，同时也会调用寻呼机事件 API，为早班团队留下报告。So it escalates for morning review without calling any additional services. This one is the TLS certificate is expiring soon for the website. It reads the ticket. It determines that the alert is clear. It has access to the cloud hosting API and it calls that API at the certificate renew endpoint using again an API key. It resolves this by renewing the certificate and it leaves a report for the morning crew by calling the pager uh incident API as well.

数据库删除、重启与扩展Database deletion, restart and scaling

下一个案例是计费数据库出了故障，付款无法处理。记录在案的恢复方法是删除并恢复数据库。代理使用包含管理员密码的数据库连接字符串来执行此操作，然后建议早班团队确认快照恢复成功。它无法直接访问相关信息，因此实际上是在假设早班团队会核实操作确实成功、数据也已恢复。权限过大的代理删除生产数据库，简直是噩梦，已有好几家公司切实经历过这种情况。因此，我们必须对此格外谨慎。下一个案例是订单卡住了，主服务器冻结。代理又要去读取工单。This next one is the billing database is broken and payments are failing. So the documented recovery for this is to drop and restore the database. The agent does this using the database connection string that includes the admin password and then it advises the morning team to make sure that the snapshot recovery worked. Now this is not something that it has access to directly. So it is essentially assuming that the morning team is going to verify that this did in fact work and the information was restored. Now an overprivileged agent dropping a production database is basically a nightmare that several companies have actually lived. So this is something that we need to be very careful of. Now the next one is orders are stuck. The main server is frozen. So the agent is again is going to read the ticket.

阅读工单后，代理再次使用其静态 API 密钥调用云托管 API。它调用重启服务器的端点，导致生产环境下线。最后，三分之一的访客无法访问网站。代理读取工单后，判断自己应该调用云托管 API，将服务从 4 个 Pod 扩容到 40 个。这样做每小时会产生 420 美元的费用。随后，它还贴心地留下一条备注，告知早班团队发生了这件事。After reading the ticket, the agent calls the cloud hosting API using again its static API key. It calls the endpoint to restart the server which brings production offline. Finally, site is failing for one in three visitors. Agent reads the ticket. It determines that it should call the cloud hosting API and scale the service from four pods to 40. It then incurs a charge of $420 per hour for doing this. And then it kindly leaves a note for the morning team informing them that this has happened.

致命三要素The lethal trifecta

那么，什么样的智能体才有用呢？通常，我们希望智能体具备一组最低限度的能力，其中往往包括读取你拥有或有权访问的数据，比如电子邮件、文档，也可能是客户关系管理系统（CRM）。我们还希望智能体能够自行开展研究，比如搜索网络、阅读文档，或者从 GitHub 获取问题。通常，我们也希望它能够使用外部工具，例如 MCP 服务器、API，也可能是 SAS 平台。有用的智能体可以在人类参与的情况下完成这些工作，也可以在后台自主执行。但恰恰是这些让智能体变得有用的能力，也会让它们变得危险。事实上，这三种能力结合在一起，构成了西蒙·威利森所称的“致命三要素”。Now, what makes an agent useful? Well, typically we want agents to have a minimum set of capabilities and often this includes things like the ability to read data that you own or have access to. This might be like your email, your documents, maybe a customer CRM. We want the agent to be able to do its own research. So this might include searching the web, maybe reading documentation or pulling issues from GitHub. And we usually want it to be able to use external tools, for example, MCP servers or APIs, maybe SAS platforms. And useful agents might do these things with a human in the loop or they might be doing it autonomously in the background. But the thing that makes the things that make agents useful also make them dangerous. In fact, together these three capabilities make what Simon Willis coined as a lethal trifecta.

这包括访问私有数据的能力，例如值班代理查询客户数据仓库并与计费数据库交互；接触不可信内容的能力，例如阅读用户提交的工单、其他代理的报告或外部记录的流程；以及与外部通信的能力，例如通过第三方 API 或 SAS 服务进行读写。这些能力结合起来，就为攻击者大开方便之门。代理的设计初衷是完成任务，因此它们会动用自己拥有的一切权限来达成目标，有时会造成非常严重的后果。但问题在于，这些事件之所以会发生，是因为人类给了代理远超其所需的访问权限。权限过大的代理可以不受约束地执行自己做出的决定，即使有人监督也一样。This is a combination of access to private data like the on call agents ability to query the customer data warehouse and interact with the billing database. exposure to untrusted content like reading user submitted tickets or reports from other agents or externally documented processes and the ability to communicate externally like reading and writing with third party APIs or SAS services. Now together these capabilities throw the doors wide open for attackers. Now agents are designed to get the job done and they'll use all the powers that they have to do it sometimes with very serious consequences. But here's the thing. These incidents happen because humans give agents way more access than they need. Overprivileged agents can act freely on decisions that they make, even if they do have supervision.

现在，强制要求人在环路中审批，只不过是把访问控制责任转交给一个已经对各种同意请求感到疲惫的用户。几十年来，我们一直在为人类解决访问管理问题。因此，把责任推给用户，只不过是把安全问题沿着链条往上游转移。Now, forcing a human in the loop approval just kind of passes the access control on to a consent fatigued user. Now, we've spent decades solving access management for humans. So shifting responsibility to the user just sort of moves the security problem up the chain.

访问控制与长期有效的凭证Access control and standing credentials

那么，我们该如何应对这个致命三要素？如何在不损害智能体实用性的前提下解决它？要知道，只要移除其中一项或多项能力，智能体的实用性就会大幅降低。那么，怎样才能保留这三项能力，同时确保安全呢？与其通过移除能力来打破这个三要素，我们真正需要做的是控制智能体的访问权限。这样既能缩小攻击面、限制影响范围，又能保留智能体的能力和自主性。那么，该怎么做呢？控制访问权限的方法有很多，比如使用 OOTH、使用供应商提供的 MCP 网关，或将执行限制在沙箱中。OOTH 会将访问权限绑定到授权。用户在授权时，会同意智能体可能使用的所有权限。So what should we do about the lethal trifecta? How do we address it without compromising the agents usefulness? Well, just removing one or more of these capabilities is going to cause the agent to be significantly less useful. So how can we keep all three but still be safe about it? Well, instead of breaking the trifecta by removing capabilities, we really need to control the agents access. So, the attack surface is minimized and the blast radius is contained, but the agent still has capability and autonomy. So, how do we do that? Well, some options for controlling access among others are things like using OOTH, maybe using a vendor MCP gateway or containing execution in sandboxes. Now, OOTH binds access to a grant. At grant time, the user consents to all of the permissions that the agent could possibly use.

现在，任务尚未存在时就已授予同意。因此，如果你授予范围很广的权限，最终就会形成长期有效的访问权限。对于任何单一的具体任务，你的代理所拥有的权限都会过多。如果你缩小授权范围，不授予太多权限，那么代理的能力就会下降。无论哪种情况，单靠 OOTH 都无法提供任务范围内的访问控制。即使你只希望代理在当前任务中读取数据，一个积极主动的代理也可能在同一次运行中既读又写。MCP 网关则会将策略执行绑定到某条路由。你可以获得可观测性、速率限制等功能，也可以在 MCP 层设置一个策略决策点。策略会针对每个请求运行，访问权限也按用户授予；但代理获得的访问权限会超出任何单一任务的期限，因为网关仍然持有长期有效的凭据。Now, consent is granted before any task exists. So, if you give a broad grant, then you end up withstanding access. Your agent is over permissioned for any single specific task. If you narrow the grant and you don't give it very many permissions, then the agent just becomes less capable. Either way, OOTH alone doesn't provide task scoped access control. An enthusiastic agent can both read and write in the same run, even if you only want it to read on this specific task. Now, an MCP gateway binds enforcement to a route. You get things like observability and rate limits, and you also get one policy decision point at the MCP layer. Now policy runs per request and access is granted per user but the agents granted access outlives any single task because the gateway still holds standing credentials.

现在，沙箱会将执行绑定到某个进程。这可以控制影响范围，但有用的工作必须触及沙箱之外，而一旦这样做，你就又会得到长期有效的访问权限。我们也听说过不少智能体突破沙箱隔离的案例。沙箱限制了进程能做什么，但无法控制哪些操作获准在沙箱之外执行。即使把这三种解决方案结合起来，智能体获得的运行时凭证仍未被缩减权限范围，以致仅能用于单一任务。Now a sandbox binds execution to a process. This controls the blast radius but useful work has to reach outside the sandbox and when it does so you end up with standing access again. Now we've also seen plenty of stories about agents breaking sandbox containment. Sandboxes bound what the processes can do, but they don't control what is authorized to act outside the sandbox itself. Now, even if you combine all three of the solutions, the agent still doesn't receive a runtime credential that's downscoped to only one task.

身份缺失与令牌交换Missing identities and token exchange

那么，我们来回顾一下这些问题，尤其是演示中看到的那些问题。如果你还记得审计日志，我们无法判断是谁在使用这些 API 密钥。因此，第一个问题是，凭据没有关联到用户或代理的身份。代理可以不受限制地访问 API 密钥所授予的所有权限。最后，我们不能在所有地方都简单地加入人工审核，因为人也会犯错。此外，许多代理是自主运行的，甚至没有人在回路中。为了解决这些问题，我们可以从使用一种叫作令牌交换的机制入手。这是一项现有标准，于 2020 年发布，是对 OAuth 2 的扩展。首先，我们需要知道用户是谁。授权服务器会验证身份并颁发令牌。Google、Okta、Auth0 等身份提供商都提供授权服务器。So, let's recap the problems, especially the ones that we saw in the demo. If you remember the audit log, we couldn't tell who was using the API keys. So the first problem is that credentials weren't attributed to a user or an agent's identity. The agent had unrestricted access to any and all permissions that were granted by the API keys. And finally, we can't just slap human in the loop everywhere because humans make mistakes, too. Plus, many agents run autonomously and they don't even have a human in the loop. So to solve these problems, we can start by using something called token exchange. Now this is an existing standard that was published in 2020 and it extends OOTH 2. Now first we need to know who the user is. Now an authorization server verifies identities and issues tokens. Identity providers like Google, Octa, Ozero etc provide authorization servers.

因此，如果我们希望在智能体执行路径中建立身份链，用户就必须先登录。授权服务器会提示用户同意委派访问资源的权限，并且只授予其部分权限。这些权限称为作用域（scopes）。这是第一次缩小访问范围：我们只将用户全部作用域中的一部分委派给智能体。授权服务器会签发令牌，用于标识用户及其访问级别。到这一步，我们已经比演示版本做得更好了，因为我们确实知道用户是谁，也确实知道他们可以访问哪些资源。接下来，我们进入智能体执行路径。So if we want an identity chain in our agent execution path then the user has got to log in first. The authorization server is going to prompt the user for consent to delegate access to resources with some subset of their permissions. Now, these permissions are called scopes. This is the first narrowing of access. We're only delegating some of the user's total scopes to the agent. The authorization server issues tokens identifying the user and their level of access. And at this point, we're already doing better than the demo because we actually know who the user is and we actually know what they can access. So this brings us into the agentic execution path.

跟踪智能体和 MCP 的执行路径Following the agent and MCP execution path

现在我们已经有了经过身份验证的用户，也就是说，已知某个人的身份，他希望使用 LLM 与某个资源交互。在演示中，这些资源包括事件寻呼系统、生产数据库、Snowflake 和云托管服务。智能体是一个会调用 LM 的控制循环。通常，我们会在智能体与其资源之间部署一台 MCP 服务器，提供用于连接下游服务的已定义工具。MCP 客户端会将智能体提出的工具调用分派到其 MCP 服务器。在演示中，值班分诊智能体使用长期有效的静态凭证（例如 API 密钥或数据库连接字符串）直接调用资源。接下来，我们要为值班智能体配备一台 MCP 服务器。它将提供各种工具，同时也会充当资源访问的中介。Now we have our authenticated user. So we have a known identity of a person who wants to use an LLM to interact with a resource. Now in the demo the resources are the incident pager, the production database, snowflake and the cloud hosting service. An agent is a control loop that calls an LM. Often we have an MCP server that sits between the agent and its resources, providing defined tools that connect to those downstream services. An MCP client dispatches the agent's proposed tool calls to its MCP server. Now, in the demo, the on call triage agent called resources directly with long live static credentials like API keys or database connection strings. So what we're going to do is we're going to give the on call agent an MCP server. This is going to provide tools and is also going to serve to broker access to resources.

现在，智能体运行时是运行智能体循环并执行调用的进程。运行时可能是像 Claude Code 这样的 CLI，也可能是智能体 SDK；后者可以在自定义应用中实现，例如值班智能体。接下来，我们沿着这条执行路径跟踪一个提示。用户将提示提交给运行时，运行时调用模型并将提示发送给 LLM。随后，模型提出工具调用，由 MCP 客户端将其分发到 MCP 服务器；服务器执行工具，然后调用资源 API。API 将响应返回给 MCP 服务器。MCP 客户端将响应传递给运行时，运行时再调用模型。这个循环会不断重复，直到模型得到满意的结果并向用户返回响应。现在，经过身份验证的用户令牌】【。Now an agent runtime is a process that runs the agent loop and executes calls. The runtime might be a CLI like clouded code or an agent SDK which might be implemented in a custom application like the on call agent. So let's follow a prompt through this execution path. The user submits the prompt to the runtime which calls the model and sends the prompt to the LLM. The model then proposes tool calls which are dispatched by the MCP client to its MCP server which executes tools and then calls the resource API. The API returns the response to the MCP server. The MCP client delivers the response to the runtime which calls the model again. And this loop repeats until the model is satisfied and returns a response to the user. Now the authenticated user's token

主体令牌与安全令牌服务Subject tokens and the security token service

这就成为我们所说的主体令牌。它用于标识代理代表谁行事、为谁服务。现在，令牌交换需要一个能够执行代码的 OAuth 客户端。这可以是一个位于 MCP 客户端与第三方 MCP 服务器之间的网关，也可以是你的自定义应用。自定义 MCP 服务器也可以为下游资源交换令牌。值班代理的 MCP 服务器应提供一组明确的生产基础设施工具。提示词和主体令牌会发送到运行时。代理循环开始运行，模型提出一次工具调用。运行时通过一个名为安全令牌服务的专用授权服务器进行身份验证。它使用应用客户端凭据或工作负载身份来完成此操作，同时还会发送包含用户身份和访问权限的主体令牌。becomes what we call a subject token. This identifies who the agent is acting on behalf of, who it acts for. Now token exchange needs an ooth client that can execute code. So this might be a gateway that sits between the MCP client and the third party MCP server or it might be your custom app. Now a custom MCP server can also exchange tokens for downstream resources. The on call agents MCP server should provide a defined set of production infrastructure tools. The prompt and the subject token are sent to the runtime. The agent loop runs and the model proposes a tool call. The runtime authenticates with a special authorization server called a security token service. It does this using its app client credentials or workload identity. It also sends the subject token that contains the user's identity and access.

它会创建一个令牌交换请求，申请获得访问 MCP 服务器的权限，而且仅限于该次工具调用。这样一来，我们就得到了演示中缺失的三项信息：我们知道请求访问的智能体的身份，知道它代表其行事的用户的身份，也知道用户授予该智能体的访问级别。现在，我们需要决定是否应该颁发所请求的令牌。我们可以通过治理策略来做出判断，该策略会根据请求访问的资源及其访问级别、智能体的身份和用户的身份进行评估。但策略只是上限。即使总体策略允许，智能体仍可能执行你原本无意允许的操作。It creates a token exchange request asking for permission to access the MCP server for that tool call and only that tool call. So now we have three pieces of info that we're missing from the demo. We know the identity of the agent that's requesting access. We know the identity of the user it's acting on behalf of. And we know the level of access that the user granted to the agent. Now we need to decide if the requested token should be issued. And we can do this with governance policy which is evaluated against what access is requested from what resource, the identity of the agent and the identity of the user. But policies are ceilings. Agents can do things you didn't intend even when policy overall allows them.

作为提案的基于意图的授权Intent based authorization as a proposal

这就引出了一个叫作基于意图的授权（IBA）的概念。IBA 会在代理采取行动之前检查你的意图。目前它还不是一项最终定稿的标准，提案仍在征集中。下面介绍的是 Keycard 实现基于意图的授权的方式。 IBA 可以将网关用作策略执行点。你向代理发送提示后，代理会提出一项任务。任务中包含目标，也可能包括允许执行的操作，以及代理可以执行操作的限制。例如，“对事件 2294 进行分诊”这一目标意味着读取该工单并进行摘要或升级处理，但不得读取其他工单，也不得使用其他服务。 安全令牌服务会收到这项任务。在本例中，像评估工单这样低风险的活动，可以根据管理员策略自动批准。另一方面，如果我们已经读取了工单，接着又要求处理用量激增的问题，那么任务会增加一项权限：将服务扩容一次，但不得使用其他工具或 API。This brings us to something called intentbased authorization or IBA. Now, IBA checks what you mean before the agent acts. Now, it's not a finalized standard. They're still accepting proposals. So, this is Keycard's approach to implementing intentbased authorization. Now, IBA can use a gateway as a policy enforcement point. When you send the prompt to the agent, it proposes a mission. Now, this mission includes a goal, maybe allowed actions as well as limits to what the agent is allowed to do. So, a goal of triage incident 2294 means read that ticket, summarize or escalate, but don't read other tickets and don't use other services. So, the security token service receives this mission. In this case, a low-risk activity like just assessing a ticket might be auto approved under admin policy. On the other hand, if we've already read the ticket and then we ask to remediate a usage spike, then the mission adds the permission to scale the service once but not use other tools or APIs.

现在，在这种情况下，任务会呈现给用户审查和批准。批准后，安全令牌服务会为该任务分配一个 ID，并将其发送给代理。工具调用中会包含此任务 ID，并由网关代理转发；网关使用该 ID 向安全令牌服务询问，此工具调用是否符合该任务。如果符合，网关就会请求进行令牌交换，以便此次特定的工具调用能够访问 MCP 服务器。STS 会评估策略，检查委托链，并查看所请求的访问权限。如果一切看起来都没问题，它就会签发一个】【。Now, in this case, the mission is presented for the user to review and approve. Once approved, the security token service gives the mission an ID which is sent to the agent. The tool calls include this mission ID and are proxied by the gateway which uses the ID to ask the security token service if this tool call fits the mission. If it does, then the gateway requests a token exchange for access to the MCP server for that specific tool call. The STS evaluates policy. It evaluates the delegation chain and it looks at the requested access. Now, if everything looks good, it issues an

临时凭证与委托链路Ephemeral credentials and delegation chains

用于 MCP 服务器的访问令牌会保留用户主体，同时添加执行令牌交换的应用——在本例中就是我们的值班代理。这个令牌应在几分钟内过期，而且绝不能存储它。它是临时的。安全令牌服务（STS）会将其发送给网关，由网关调用 MCP 服务器。随后，服务器会验证令牌并授权工具调用。 有些工具需要访问外部资源。因此，MCP 服务器会请求安全令牌服务，将刚收到的令牌交换为下游资源的令牌。接着，STS 会根据策略评估该请求；如果请求符合策略，就会签发一个作用范围再次限定于该工具调用的资源令牌。它会保留用户主体，从而延续委托链，并使我们能够追踪所有活动。access token for the MCP server and it keeps the user subject as well as adds the app that performed the exchange, which is in this case our on call agent. Now, this token should expire within minutes and we should never store it. It's ephemeral. The STS sends it to the gateway, which calls the MCP server. The server then validates the token and authorizes the tool call. Now, some tools need external resources. So, the MCP server then asks the security token service to exchange the token that it just received for a token for the downstream resource. Now, the STS evaluates the request against policy and if it passes, then it mints a resource token that's scoped again to that tool call. It keeps the user subject which extends the delegation chain and allows us to be able to track all of the activity.

STS 将令牌发送给网关，网关再将请求代理到 MCP 服务器，随后 MCP 服务器调用资源。资源会验证令牌并授权访问。现在，MCP 服务器绝不应存储令牌，而应在调用后立即丢弃它。然后，资源的响应会沿原路返回，智能体循环会不断重复，直到模型向用户返回答案。接下来，我们将来看同一个彩票计划The STS sends the token to the gateway which proxies the request to the MCP server which then calls the resource. The resource validates the token and authorizes access. Now the MCP server should never store the token. It should discard it immediately after the call. The resource response then flows back up and the agentic loop repeats until the model returns the answer to the user. So now we're going to look at the same

使用基于任务的策略重复演示Repeating the demo with task based policy

这是一个演示，不过我们将使用安全令牌服务，通过委托授权来管理代理的访问控制。该演示采用基于任务的策略治理，而非基于意图的授权；不过，如果你本月晚些时候参加 Agent Con，我们会在那里展示 IBA 演示。现在，我们还有一个 MCP 服务器，用于建立工具并提供对资源的代理访问。现在，我们再次回到值班分诊代理，只不过这次加入了身份验证。接下来，我要登录值班代理分诊应用。我会使用 Google 登录。然后我会看到另一个登录界面，这里我要登录 Incidex 寻呼平台。我会看到提示，询问是否授权值班代理访问我的 Incidex 账户。我会允许它代表我升级事件、发布备注和摘要，并读取队列。demo except we are going to use a security token service to manage agent access control with delegated authorization. The demo uses task based policy governance, not intentbased authorization, but if you're going to Agent Con later this month, we'll have IBA demos there. Now, we also now have an MCP server that establishes tools and it provides brokering access to the resources. So, now we're back to our on call triage agent again, only this time we have authentication. Now I'm going to go ahead and sign into the on call agent triage app. I'm going to log in with Google to do so. And then I get another login screen. Now this is where I'm going to sign into the Incidex pager platform. So, I get a prompt to grant the on call agent access to my Incidex account. I'm going to let it escalate incidents on my behalf, post notes and summaries, and read the queue.

现在，系统提示我登录云托管平台，所以我准备登录。随后又出现了一个同意授权页面，允许我授权代理代表我访问 Compost 的某些功能。现在我终于回到了值班仪表板。工单队列还是原来的队列，只是现在审计日志看起来不一样了。代理可能会像之前一样尝试执行操作。只是现在，每个请求都会先经过 STS 和策略评估，获批令牌后，代理才能获得操作权限。工单队列还是原来的队列，只是现在审计日志看起来不一样了；代理可能会像之前一样执行操作，只是现在每个请求都会经过 STS 和策略评估。Now, I'm being prompted to log into the cloud hosting platform. So, I am going to do that. And I get another consent screen now which allows me to authorize the agent to access some capabilities of compost on my behalf. Now finally I am back on the on call dashboard. Now we have the same queue of tickets only now the audit log looks different. The agent is probably going to try 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 and the agent will be authorized to act. So we have the same queue of tickets only now the audit log looks different and the agent is probably going to behave the same way that it did before only now every request is going to go through the STS and policy evaluation

数据访问、续订和删除决策Data access, renewal and deletion decisions

在授予令牌、授权代理执行操作之前。因此，第一张工单是那起计费异常。代理再次尝试读取工单，我们可以看到它正试图重复之前的操作。它尝试查询客户数据仓库，但策略不允许为此签发凭证，因为客户个人身份信息不应出现在代理的上下文中，也不应出现在事件工单里。因此，代理在不获取客户数据的情况下继续处理，并将问题升级给早班团队。现在我们来看网站安全证书即将过期的问题。这是代理有权限处理的事项。因此，当它向 STS 请求凭证时，访问权限获批，它便可以调用云托管 API 并解决这张工单。现在，你可以看到它发出的所有调用，以及是谁发起的。before a token will be granted and the agent can be authorized to act. So the first ticket is that billing anomaly. Again the agent tries to read the so the agent is reading the ticket and we can see that it is trying to do the same thing that it did before. It tries to query the customer warehouse but 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. So the agent proceeds without the customer data and it escalated it to the morning team. Now we have the website security certificate expiring. Now this is something that the agent has permission to do. So when it requests credentials to do this from the STS access is granted and it can call the cloud hosting API and resolve this ticket. Now you can see all of the calls that it's making and who is making them.

因此，我们有一个值班分诊代理正在请求续期证书。它请求获准调用生产基础设施 MCP 服务器中的相应工具，因此获得了一个令牌。之后，MCP 服务器会请求访问该云托管服务，以便通过 API 续期证书。接下来，如果我们转到计费数据库，它会通过事件 API 读取工单，并得出与之前相同的结论。代理知道这是一项删除并恢复流程，但这次策略禁止代理删除生产数据库。这必须由人工手动完成。我们可以在审计日志中看到这一点：STS 拒绝授予令牌。So we have the on call triage agent that is requesting to renew the certificate. It's asking for permission to call the appropriate tool from the prod infra MCP server. So it gets a token for that. After that, the MCP server is going to request access to that cloud hosting service in order to renew the certificate using the API. So, if we move on to the billing database, it's going to read the ticket through the incident API. It's going to come to the same conclusion that it did before. The agent knows that this is a drop and restore procedure, but this time policy forbids an agent to drop a production database. A human's got to do this manually. And we can see this in the audit log where the STS refused to grant the token

批准权限受用户权限限制Approval constrained by the user's authority

以换取对数据库执行删除操作的访问权限。现在我们的订单卡住了。主服务器冻结了。代理接下来会读取工单。它想重启主服务器，这会导致生产环境短暂离线。它把这件事告知了我，这次实际上是在征求我的批准。我会点击“批准”。不过，这项操作也被策略拦截了，原因是我的用户没有执行此操作所需的角色。对吧？所以代理做不了，我也做不了，而代理是代表我行事的。如果我们再次遇到网站每三名用户中就有一名无法访问的情况，代理想要添加更多服务器，并会请求许可。它会说明我们这样做将承诺承担什么。我会批准这项操作。exchange for access to the database delete. So now we have our orders are stuck. The main server is frozen. The agent's going to go ahead and read the ticket. It wants to restart the main server. This takes production briefly offline. It informs me about this and this time it's actually asking for my approval to do this. So I'm going to click approve. However, this was also blocked by policy and the reason for this is because my user does not have the role necessary to take this action. Right? So the agent can't do it but I can't do it either and the agent is acting on my behalf. If we move to the site failing for one in three users again, the agent wants to add more servers and it's going to ask for permission. It's going to say what we're committing to when we do this. I'm going to go ahead and approve this.

这件事也在我的职责权限范围内。因此，升级流程顺利完成，工单也得到了解决。我们可以看到，代理的访问问题已经解决。我们能够追溯整条链路上的用户身份和代理身份。代理可以获得任务范围内、临时性的 MCP 服务器及下游资源访问权限。我们还实现了人在环中的访问控制，并且这种控制由策略提供实际保障。现在，访问权限由安全令牌服务和策略在任务级别进行控制，同时我们保留了所有关键能力。 令牌交换是一项开放标准，经过了充分研究，而且是公开的，因此任何人都可以实现。它还可以与现有的策略引擎、符合标准的身份提供商，以及各种网关、沙箱、现成工具和自定义代理、CLI、MCP 服务器、软件工厂、代理间访问、跨应用访问等互操作，也能兼容下周出现的新事物。因此，希望大家考虑采用它，让代理既实用又安全，也能适应未来的发展。 我叫 Kim Maida。And this is something that my role does have the authority to do. So the scale goes through and this ticket is resolved. So we can see that the agent access problems are solved. 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. And we have human in the loop with access control that's actually backed by policy. Now access is controlled at the task level by the security token service and policy and we retain all key capabilities. Now token exchange is an open standard. It's well researched and it's public so anyone can implement it and it interoperates with existing policy engines and standards compliant identity providers as well as things like gateways sandboxes ooth offtheshelf and custom agents CLIs MCP servers software factories agent to agent crossapp access plus whatever comes out next week so I hope you'll consider it to make your agents useful safe and future friendly now my name is Kim Maida.

我是 Keycard 的创始 GTM 工程师，也是 Devril 的负责人。非常感谢你今天抽出时间。真的非常感谢。I'm the founding GTM engineer and head of Devril at Keycard. And I really appreciate your time today. So, thank you very much.