谁在发出请求？Keycard 的 Kamil Potrec 讲智能体身份与授权

简要说明Brief Description

Keycard 的 Kamil 解释了为什么智能体需要独立身份、范围明确的授权和可审计的委派。这场演讲比较了 SDK 与网关，并介绍了将凭证置于智能体执行环境之外所涉及的权衡。Kamil from Keycard explains why agents need distinct identities, scoped authorization and auditable delegation. The talk compares SDKs and gateways and describes the trade-offs in keeping credentials outside agent execution environments.

目录Table of Contents

• 凭证与归因问题
  Credentials and the attribution problem
• 动态授权与代理身份
  Dynamic authorization and agent identity
• 大规模场景下的委派、联合与策略管理
  Delegation, federation and policy at scale
• SDK 与客户端控制的局限性
  SDKs and the limits of client-side controls
• 网关、密钥库和请求控制
  Gateways, vaults and request controls
• 网关的权衡取舍与 Keycard 控制平面
  Gateway trade-offs and the Keycard control plane

凭证与归因问题Credentials and the attribution problem

大家好，我叫 Kamil，在 Key Card 的产品团队工作。今天我将和大家聊聊智能体身份验证与授权要求。hi everybody. My name is Kamil. I work at Key Card in a product team. I'll be talking to you today about agent authentication authorization requirements.

我们大概有18分钟左右，远远不够把这个话题讲完。所以，我今天的目标是给大家大致介绍一下要完成这件事需要做些什么、如何解决这类问题，并提供一些背景信息，方便大家到楼下的展位来向我们提问。We have around 18 minutes ish. That's nowhere close to be able to cover this topic. So, my goal today is to give you kind of high-level overview of what's required to do this, how to kind of solve these problems, and give you context to come and ask us questions at the booth. We downstairs.

所以，有什么问题都可以在最后来找我，或者去找 Peter。他什么都知道。我们先从这张相当简单的图表开始。你们可能在关于智能体以及它们如何与 MCP 服务器和其他智能体通信的演讲中见过它。So, just whatever questions you have, feel free to grab me at the end or go find Peter. He has all the answers. We're going to start with this fairly simple diagram. You're probably familiar with this in any of the talks you have about agents and how they communicate with MCP servers and other agents around.

但是，人们通常不会谈到的是，这些智能体和用户如何彼此通信、如何进行授权和发出请求。我们经常遇到和看到的情况是，用户会获得某种访问凭证，可能称为个人访问令牌，或者简称令牌。它们可以说是一种不透明的凭证，用来标识这些用户，并让智能体决定是否执行相应操作。But, what usually people don't talk about is how are these agents and users communicate with each other, how do they authorize and make requests. So, what we come across and what we see often is that users obtain some sort of access credential. They might be called personal access tokens or just tokens. And they kind of represent opaque credential identifying these users and letting the agent decide if they're going to perform this action or not.

如果你的代理是在本地运行的，有时这一步会被跳过，之后也不会发生其他事情。当代理收到请求时，它们需要拥有自己的凭据才能执行操作，对吧？比如，它们通常需要一个 API 密钥，才能与模型提供商通信，从而进行推理。所以，每当 LLM 模型决定执行某些操作时，它们通常会调用工具。If your agent is running locally, sometimes this step is skipped and nothing else happens. When a request comes to the agents, they need to credentials of their own to even perform the actions, right? Like the common thing that they need is an API key to talk to the model provider that allows them to kind of do the reasoning. So, whenever the kind of LLM model decides to do some actions, they often call tools.

当我们需要进行这些工具调用时，通常会使用远程 MCP 服务器来执行。为了与它们通信，理想情况下，我们还需要另一套凭据。业界已经出现了几种做法。有时，代理会直接使用 Alice 的个人访问令牌（PAT），或者类似的用户令牌，并将其传递给远程服务器。When we need to do those tool calls, often we use remote MCP servers to perform them. And in order to communicate with them, hopefully, we need another credentials to do that. And we have couple of options that we've seen in the industry. Sometimes the agents will just use Alice's or like users PAT tokens and pass them through.

有时它们会有自己的静态密钥。幸运的是，我们看到越来越多地方开始采用各种动态凭证机制。但每当 MCP 服务器收到这个令牌时，它们通常只会把用户视为使用该令牌的身份。所以，MCP 服务器并不真正知道运行它的是某个智能体、Alice 的 CLI，还是其他工具。MCP 服务器通常用于封装现有基础设施。Sometimes they will have their own static keys and luckily enough we see more and more use of all of kind of dynamic credentialing that happens there. But whenever MCP server receives that token they usually just kind of see the user as the identity that acts with it. So MCP server doesn't really know if it's like an agent running it, is it like Alice's CLI or is it like any other tool that does it? MCP servers are often used to kind of enclose existing infrastructure.

因此，如果你有内部 API、数据库，甚至一些不太适合智能体使用的外部系统，我们可以用 MCP 服务器来封装这些通信，并优化交互方式。但要做到这一点，这些 MCP 服务器通常需要访问这些后端服务，并代表多个用户行事。因此，它们不能只使用某个用户的机器人令牌，因为该令牌的权限范围有限。它们通常会使用服务账户，而这些服务账户会成为权限的聚合点，让这些服务器能够进行通信。So if you have like internal APIs, databases, even external systems that are not kind of agent friendly, we can use MCP servers to represent that communication and optimize that interaction. But in order to do that these MCP servers often need to have access to these back-end services and act kind of act for multiple users. So they cannot just use one user's bot token because that will be limited to that scope. They often use service accounts and those service accounts kind of become aggregator of permissions so that these servers can communicate.

而这并不是什么新鲜事。过去，我们在传统 SaaS 软件中服务与服务之间的通信里，也见过类似的模式。不过，智能体有什么不同之处呢？它们并不是确定性软件，对吧？And this is nothing new. We've seen this pattern in the past in kind of service-to-service communication in your traditional SaaS software. However, what's different about agents? They're not deterministic software, right?

因此，每当请求返回给智能体，并且它收到一些数据时，它就会把数据发回模型，由模型决定接下来要如何处理。在这个例子中，我们使用的是一个抽象的发票服务。假设智能体收到一个请求，要求查看最近的发票。它取回一张发票，上面显示“待处理”，于是应将其发送给用户。So whenever the request comes back to the agent and it sees them some data, it will send it back to the model and it will decide to do what it wants to do with it next. In this case we're using an abstract example of invoicing service. So imagine the agent receives a request to go and look at the recent invoice. It gets it back an invoice says I'm pending, it should be sent to the user.

一个智能体要么出于恶意，要么只是过于热心，决定把这张发票发送给某个用户。现在问题变成：是谁提出了这个请求？是 Alice，还是智能体？我们不知道。An agent either maliciously or is just too helpful decides to go and send this invoice to a user. Now the question becomes who is making this request? Was this Alice or was this the agent? We don't know.

实际上没有什么需要确定的。那么这幅图景还有什么问题？这些凭证到处散落，会带来很多问题。用户使用这些访问令牌时，令牌实际上并没有关联到任何具体对象。因此，Alice 可以很轻易地把这个令牌拿到她自己的个人设备上使用，这样一来，你就失去了可能保护它免遭滥用的企业基础设施。也没有简便的方法来撤销这些凭证，所以它们就一直放在那里，可能被滥用。随着智能体想要执行更多操作，我们会给它们更多凭证，而它们也开始把这些凭证汇集起来。There's nothing to determine that in reality. So what else is wrong with this picture? there's a lot of issues with having all of these credentials laying around. So whenever users use these access tokens, they're not really attributed to anything. So Alice can quite easily take this token and put it on her own personal machine and then you kind of lose all of that corporate infrastructure that might protect it from abuse. there is no easy way to revoke these credentials, so they kind of lay there and can be abused. agents as they want to do more things, we give them more credentials and they start aggregating them.

再说一遍，由于它们有些不可预测，我们其实不知道它们会如何使用这些访问密钥。最后，我们又回到了服务账户这个老问题。说到底，它们只是一堆权限过大的权限集合。现实是，在智能体出现之前，我们一直对行业现状安之若素，因为我们多少依赖于软件以安全的方式发布。我们认为这是开发人员会负责处理的事情。And again, because they kind of non-deterministic, we don't really know what they're going to do with those access keys. And finally, we arrive at the old problem of service accounts. Again, they're just over-privileged bucket of permissions and re- reality is like we've been okay with the status quo in the industry before agents because we kind of relied on the software being released in a secure way. We thought about it as something that developers take care of.

所以，我们算是接受了这种风险。智能体改变了这一切，因为如今我们生活在这样一个世界里：有另一个角色可以代替你行事。我经常打这样的比方：我待过的几乎每家公司都有这么个做法——我们会四处走走，看看有没有同事忘了锁电脑，然后就打开 Slack，发一句：“今天我请大家吃甜甜圈。”那时候我们知道这样做不是什么好事，所以我们才玩这个游戏。So, we kind of accepted the risk. Agent changed all of that because now we live in a world where there is this other actor that can behave on behalf of you. I always use this analogy like in almost every company I worked at, we have this thing when we would walk around and see if one of your colleagues left the laptop unlocked and we would go to the Slack and be like, "I'm buying donuts for everybody today." And back then we knew that is not a good thing. So, that we played this game.

我们会把机器锁定，然后再也不会这么做。但智能体基本上一直在做这种事。我们就这样放任它们拿着我们的凭据到处乱来，而且一直如此。所以，我们需要一个更好的解决方案来解决这个问题。We would lock the machine down and then we would never do it again. But agents are basically doing this all the time. We just let them run rampant with our credentials and do this all the time. So, we need a better solution to do this.

动态授权与代理身份Dynamic authorization and agent identity

有趣的是，解决其中一些问题的技术其实已经存在很多很多年了。只是我们一直没有动力花时间把它妥善地实现出来。所以，我们不必让 Alice 自己去弄清楚该如何获取访问令牌——这本身也是糟糕的用户体验。你可以想一想：“我为什么要去获取这些凭证？”为什么不能让代理公布如何获取访问权限，然后将这一能力嵌入客户端，让它能够向某个外部系统请求授权？这样我们就可以签发这种动态凭证，将其限定在特定交互范围内，并且只允许用于调用它的工具。等操作完成后，凭证也就失效了。And funnily enough, technology to solve some of these problems existed for many, many years. We just didn't have incentive to kind of spend time how to implement this properly. so, instead of Alice going trying to figure out where to get access tokens, which is also terrible user experience. You can kind of think like, "Why why do I need to go and fetch these credentials?" why wouldn't we have agents that basically can advertise how to get access to them and then embed into the client's ability to go and request that authorization from some external system. And then we can issue this kind of dynamic credentials that are scoped to that specific interactions, that limited to the tool that was using it. and whenever it's done, it's finished.

OAuth 这项技术可以让我们做到这一点。仔细想想，我们早就解决了用户身份验证的问题，但对于软件，我们却认为这并不是真正的必要条件。现在我们需要改变这种想法，也需要利用现有技术，让智能体先完成身份验证，然后再向它们发放任何凭证。比如，我们可以使用工作负载身份联合。还有其他机制，比如私钥身份验证、证书或基于 URL 的授权。具体采用哪种机制其实并不重要，只要使用某种机制，让智能体向系统进行身份验证即可。And OAuth as a technology allows us to do this. and when you think about this, we kind of solved authentication for users a long time ago, but then for software, we decided that's not really a requirement. but we need to change this and we need to also use technologies that we have available to us to make agents authenticate before we issue them any credentials. So, we can use things like workload identity federation. There's other mechanism, you can use private key authentication, you can use certificates, you can use URL based authorization. The mechanism doesn't really matter as long as you use it and make agents authenticate to the systems.

有趣的是，一旦你这么做了，就可以大致重复同样的模式。与其给这些智能体配置服务账户，并给服务账户添加持久权限，不如让它们每次想要与某个远程服务器通信时，都先确定需要什么授权，再访问这项远程服务获取令牌，然后继续操作。我提到过，智能体与我们现有传统软件之间唯一的区别就是那个推理循环。把它从等式中去掉，传统软件和智能体都只是软件。And funnily enough, once you do that, then you can just kind of repeat the same pattern. Instead of giving these agents kind of service accounts and adding like persistent permissions to the service accounts, why don't they just every single time they want to talk to some remote server kind of determine what authorization is required, go to this remote service, obtain the token, and go forth. And the only difference between agents and traditional software that we have that I mentioned is that reasoning loop. If you take that out of equation, both the legacy software and agent is just software.

所以，再说一次，你现在编写应用时可以直接复用同样的模式，一切都不会改变，也可以用这种方式重新实现整个技术栈。So, again, you can just reuse the same pattern for the application that you're writing now, and nothing changes, and you can kind of go and re-implement the entire stack this way.

大规模场景下的委派、联邦与策略Delegation, federation and policy at scale

听起来很简单。那么，我们之前为什么没这么做呢？嗯，一旦我们考虑如何大规模解决这个问题，事情就会变得棘手得多。我们拥有的并不是一个 API，而是数百个 API，而且它们使用不同的方式对用户进行身份验证。So, that sounds easy. So, why we didn't do this before? Well, all of this kind of becomes way tricky to do when we think about this problem at scale. There isn't like one API that we have, there's like hundreds of APIs that we have, and they use different ways to authenticate users.

在这些 API 的背后，总有某种授权服务器需要对用户进行身份验证。所以，在前一张图里，我们只有一个需要进行授权的模块。而现在，客户端需要在数百种这样的服务中完成这件事，而且并不存在一种统一的代理类型。Behind those APIs, there's always some sort of authorization server that needs to authenticate the user. So, in a previous picture we had like one block that we would have to authorize against. Now you have clients who need to do this across like hundreds of these services. And there isn't like one agent type.

我们会有一些可以购买的智能体，比如你的云端代码智能体，以及你自己构建的智能体。有时候你可能无法更改这些软件，所以我们需要找到一种方法来处理这件事。而且这并不是单跳流程。因此，我们现在需要处理这种委派流程，并验证这些智能体将如何彼此通信，以及这个循环中最多会有多少跳。We're going to have like agents that you buy, so your cloud code, agent that you build. Sometimes you won't be able to like change that software, so we need to find a way to how we're going to do this. And there isn't like one hop. So, now we need to process this kind of delegation flow and verify how all these agents going to talk to other agents and how many hops there can be in that loop.

最后，我们面临的最大问题是，如何追溯是谁决定采取了这些操作。现在，有成千上万的用户需要同意代理执行的这些任意操作。到了大规模应用时，我们必须同时解决所有这些问题，才能做出对我们有用的东西。总而言之，如果我们想要建立一套完善的代理身份验证系统，需要实现什么？And finally, like the biggest problem that we have is the attribution of like who decided to make this action. So, we now have like thousands of users who need to consent to these arbitrary actions that agents are doing. So, at scale, now we have to solve all of these problems all together in order to make something useful for us. So, in summary, if we want to have a proper agent authentication system, what do we need to deliver?

所以，首先，我们需要 agent 身份。我们需要一个系统来为每个 agent 签发身份标识；甚至可以按会话来签发。但这些身份必须与启动 agent 的人分开。然后，我们需要能够表达这种委派语义。也就是说，我们需要能够说明哪些用户有权通过这些 agent 执行操作，以及哪些 agent 可以代表其他用户行事。So, first of all, we need agent identities. We need a system that's going to issue these identities per agent. then that might be even be per session. but that must be separate from whoever launched it. Then we need to be able to express this delegation semantics. So, we need to be able to say which users are authorized to perform actions with these agents, which agents can act on behalf of other users.

我们需要一套系统，能够为我们所做的一切签发范围受限、短期有效的凭证，而且不能有任何能让我们做到这一点的主密钥。其次，正如我提到的，我们已经有大约 100 个不同的系统。我们不能指望能神奇地把它们全部重写。大语言模型速度很快，但也没那么快。因此，我们需要能够在这些系统之间建立身份联邦信任，并让它们在相互交换信息时彼此信任。We need to have a system that can issue scoped and short-lived credentials for everything that we do. and there cannot be like any master key that allows us to do this. Second, as I mentioned, there's like 100 different systems that we already have. We cannot magically hope we can rewrite them all. LM are fast, but not that fast. so, we need to be able to build a federated trust of identities across them and allow to trust each other when they exchange these systems.

而且，遗留软件将永远存在。你不能指望它们很快就会支持 OAuth。因此，我们需要一个自适应层，也就是一个代理，能够让我们在恰当的时机安全地交换这些遗留凭据。最后，我们需要能够通过策略来明确规定这些要求：哪些操作需要人工审批，哪些代理可以自动运行。事情总会出错。因此，为了从中吸取经验并改进，我们需要审计机制。我们需要能够查明是谁批准了这项请求，以及是谁促成了这件事。And again, we're going to have legacy software forever. you won't be able to kind of go and hope that they will be supporting OAuth anytime soon. So, we need to be able to kind of have an adaptive layer, a broker, that allows us to securely exchange those legacy credentials just in time. and finally, you need to be able to express this with policies. someone needs to be able to write which actions need human approval, which agents can run automatically. and things will go wrong. So, in order for us to learn how to improve things, we need audit. we need to be able to say who authorized this request and who made this possible.

所以，要真正把这件事做好，需要经过很多步骤。这里我想展示的是，要让它正常运行，只看代理与 MCP 服务器之间的一次交互：你需要有一个客户端和一个服务器。服务器需要发布这些信息，客户端需要能够发现这些信息，然后代理需要能够获取这些凭据。So, there's a lot of steps to actually get this right. So, what I want to show you here is just like if you take one interaction between agent and MCP server just to get this working, you will have a client and a server. server needs to be to publish this information. Cli- clients need to be able to discover it. Then the agents need to be able to obtain these credentials.

他们需要能够向这台远程服务器验证自己的身份。之后，MCP 服务器必须能够验证这些凭据是否经过正确签名。他们需要检查签发方是否可信，并验证这些令牌。然后，需要执行相应的策略，确保采用的是最新规则。完成这些后，当他们与外部系统通信时，可能还需要获取额外的凭据才能与其交互。最后，我们必须确保所有这些操作都记录在审计日志中。They need to be able to authenticate themselves to this remote server. then when that happens, the MCP server has to be able to validate if those credentials been correctly signed. They need to check if the issue is trusted. They need to verify those tokens. then there is some policy that needs to come into action. They need to enforce if the latest rules are in play. once that happens, and they communicate to external system, they might need to obtain additional credentials to talk to it. and finally, we need to make sure that every single one of these actions is captured in the audit log.

举手示意，谁认为大语言模型每次都能完美做到这一点？好，我想我们都达成共识了。Raise of hands, who thinks LLMs can do this every single time perfectly? All right. I think we're all in agreement.

SDK 与客户端控制的局限性SDKs and the limits of client-side controls

所以，这并不简单，但我们以前解决过类似的问题，对吧？比如，我们编写过共享库、中间件和 SDK，这样就能把这些东西一次写好，再让更多人一起验证它们是否运行正常，然后反复复用。这听起来正是我们在这里想要采用的解决方案。不过，SDK 有什么问题呢？如今编写 SDK 很容易，但你得让所有人都采用它们，对吧？如果采用情况不全面，那 SDK 又有什么用呢？而且，你还得为你使用的每一种语言都编写相应的 SDK。so, this is not simple, but we have solved similar problems before, right? Like we've written shared libraries, we've written middleware, we've written SDKs in order to kind of write these things once, verify with a larger group of people if those performing appropriately, and kind of reuse them all the time. which sounds like a solution to what we want to do here. but what are the problems with SDKs? So, it's easy to write them these days, but you need to get them adopted by everybody, right? Like if you have gaps in your adoption, then well, what's good are your SDKs? then you need to write them for every single language that you have.

而且，LLM 可能擅长编写其中一些语言，但可能不擅长你系统中那些较老的语言。那你的云端代码怎么办？还有那些你无法修改的代码 X，对吧？SDK 在这方面也帮不了你太多。接下来，如果 LLM 会引入 bug（它们确实会），而我们也会写出 bug，那么要修复这些问题，你不仅得修复 SDK，还得追踪这个 SDK 被用在了哪里，以及哪些系统使用了它。最后，前面提到的这四个问题以前就存在，所以并不是什么新问题。And LLMs are probably good at writing some of these languages, but probably not the older ones that you have in your system. and then what do you do about your cloud codes, your code X that you cannot go and modify, right? Like SDKs won't help you there too much. then if you're going to have bugs because a LLMs make bugs, we write bugs. in order to fix that, you not only have to fix the SDK, but then you need to track where is this SDK used, and which one of the systems consumed it. And then finally, so all of these previous four problems existed before, so that's nothing new.

但智能体还有一个额外的问题。正如我所说，它们会采取行动，而且往往过于乐观；也可能被操纵去做某些事，并且事实证明，它们会非常执着地试图绕过我们的控制。因此，我们真的能相信仅靠客户端代码就能安全地管理这些凭证吗？当然，它们可以缓存凭证，也可以妥善存储，但如果它们发现了自己可以使用的凭证，只要是在它们自己的执行环境中使用，我们就会遇到问题。But agents have additional problem. As I said, they kind of act and trying to be too optimistic, or they can be kind of manipulated do things, and they proved to be very persistent in trying to bypass our controls. So, do we really trust with using just kind of client-side code to be able to manage these credentials securely? Of course, they can cache them, they can store them properly, but if they figured out that there is credential that they can use, as long as it's within their own kind of execution environment, we have a problem.

因此，显然，出于诸多原因，SDK 并不能解决这个问题；此外，它们也无法解决向代理隐藏凭据的问题。So, SDKs clearly are not going to solve this problem for many reasons, and additionally, they don't solve the problem of hiding credentials from agents.

网关、保险库和请求控制Gateways, vaults and request controls

那么，如果我们看这张图，我们面临的挑战是如何让智能体无法接触到所有这些令牌。那我们能怎么做呢？我们可以尝试将所有这些凭证移出这个执行环境，放到某种安全飞地中。这样，我们就可以拥有某种运行时授权系统或凭证保管服务，用来存储并代理这些凭证。So, if we take this picture, the challenge that we want to do is to get all of these tokens out of the reach of the agent. So, what can we do? Well, let's try to move all of these credentials out of this execution environment and put them in some sort of secure enclave. So, we can have our kind of runtime authorization system, vaulting service, that can store and kind of broker all these credentials.

然后另一个问题是，我们现在要如何利用它们？我们过去用过网关，它们可以帮我们解决这个问题。代理可以与网关通信，请求一个特定目标（例如与 GitHub 通信）；网关可以验证调用方的身份，与我们的运行时授权服务通信，确认相关策略已就绪，并获取相应的凭证。然后，网关只需将凭证注入请求路径，并将请求转发给 GitHub。And then the other problem is now how are we going to make use of them? So, gateways are something we've used in the past, and they can solve this problem for us. So, agents can communicate to the gateway, can request specific target to talk to GitHub, for example, and a gateway can authenticate who's calling it, talk to our runtime authorization service, validate that policies are in place, and fetch the specific credential. And then they can simply inject them into the request path and send it forward to GitHub.

这样我们就有了一个物理控制层：除非这个代理以非常确定的方式尝试攻击我们的网关，甚至更糟的是攻击我们的授权服务，否则它根本无法获取该凭证。更重要的是，这还能带来另外几个特性。即使使用短期凭证，它们也会有某种过期时间，对吧？而且我们仍然没有找到在分布式系统中可靠地实现撤销的方法。And what that gives us is now we have like a physical control layer where there's simply no way for this agent to obtain this credential unless it's going to be very deterministic and go try to hack our gateway, or even worse, our authorization service. But what most importantly, we get couple more properties out of this. Even if you use short-lived credentials, they will have some sort of expiry time, right? And we still haven't figured out how to do revocation probably across distributed systems.

但如果你使用网关，并强制所有通信都经过这个节点，就可以即时撤销权限，因为网关能够实时检查每一个请求。此外，智能体会做得太多。很多这类遗留服务无法妥善限定访问权限。它们的令牌只允许你拥有管理员、读取或写入权限，但这些权限粒度还不够，对吧？But if you use gateways and you force all of your communication through that point, you can have instantaneous revocation because gateway can check every single request on the fly. Additionally, agents will do too much. A lot of these legacy services won't be able to scope access properly. They will have tokens that allow you either admin, read, or write permissions, but they're not good enough, right?

比如，我们希望能够这样说：“嘿，你可以读取我的电子邮件，但不能发送邮件。”借助网关，由于我们可以拦截所有请求，更重要的是还能对其进行检查，因此可以收紧请求的权限。我们可以这样说：“对于这个特定请求，可以，我们会使用安全凭证；但如果你试图发送请求，我们就会直接拦截。”此外，由于网关位于网络路径上，我们还能获得更强的可观测性，准确了解所有请求的处理情况，而且无需对下游服务做任何改动。Like we want to be able to say, "Hey, you can read my email, but you cannot send my email." With the gateways, because we can intercept and more importantly introspect all of the requests, we can attenuate that request. We can say, "For this specific request, yes, there is a secure credential we're going to use, but if you're trying to send request, we're just going to block it." We also get more observability because the gateway is on a network path, we can see exactly what happens for all the requests, and we don't need to change anything in our downstream services.

网关的权衡取舍与 Keycard 控制平面Gateway trade-offs and the Keycard control plane

不过，世上没有免费的午餐。网关也会带来一些挑战。在调用链路中增加一跳，会增加一些延迟；如果你特别关注延迟，这一点就需要考虑。你还得让所有代理都通过网关通信。But, there's nothing for free in life. So, gateways also come with some challenges. While you're adding another hop to your call, so if you're really careful about your latencies, that's going to add some to it. Well, you need to force all your agents to talk to your gateway.

如果它们能够绕过网关，而你又没有强有力的网络控制措施，那网关就帮不了你。此外，有些智能体希望在本地执行工具，因此你实际上并没有对此进行防护。网关无法解决你的身份验证问题。是的，智能体仍然需要获取某种身份验证凭据，并将其提供给网关，才能发出经过正确身份验证的请求。If they can go bypass it if you don't have strong network controls, then that's not going to help you. Additionally, some agents want to have kind of local tool execution, so you're not really guarding against that. There's nothing gateway does about your identity problem. Yes, agents still need to get some sort of authentication credentials and present it to the gateway in order to have a correct authenticated requests.

你也让你正在构建的这个东西成了一个很大的攻击目标，因为我们现在的说法是，每一项凭证都会经过它。所以，嗯，有些人会试着攻击它。构建网关涉及很多技术上的复杂问题。有些人也把它们称为代理。You're also putting a big target on this one thing that you're creating because now what we're saying is like every single credential will go through it. So, well, some people will go try to hack it for you. There's a lot of technical complexities with building gateways. Some people call them proxies as well.

TLS 就是其中之一。如果你试图拦截 TLS 并与所有这些系统协同工作，可能会遇到一些问题。最后，如果你运行的是分布式系统，所有这些开发者都在构建代理，他们就得弄清楚如何在所有这些网关中配置路由、策略和连接器，对吧？仍然需要有人决定代理 A 是否可以通过网关与代理 B 通信。TLS is one of those things. If you try to intercept that and try to work with all of these systems, you might run into some problems. And finally, if you're running distributed system, you have all of these developers building agents, they need to figure it out how they're going to configure the routes, the policies, the connectors in all of those gateways, right? That still someone has to say if agent A can talk to agent B via the gateway.

第二，还必须有人来运行它。这些就是我们在网关方面遇到的所有问题。我们在 Keycard 会一直思考这些问题。因此，我们认为让每个人都重复实现所有这些功能并不明智。于是，我们构建了一个统一的控制平面，既能为你的代理提供身份，也能签发令牌，并与你现有的所有系统联合。我们为你的所有请求提供策略管理和审计功能。你还可以从我们这里获取所有客户端 SDK，以实现注入和发现。And two, someone has to run it. so these are all the problems we have with gateways. so what we do at Keycard, we think about all of these problems all the time. so we don't think it's sensible for everybody to replicate all of these functionalities. So, we've built a single control plane that allows you to both give your agents identities. We issue tokens in and federate with everything that you have going on. we provide you policies and audit to all of your requests. you can get from us all of the client SDKs that allow you to do injection and discovery.

我们为你提供服务 SDK，你不必操心它们如何进行身份验证。我们也提供网关，如果你确实想要这些控制能力的话。不过，归根结底，你可以把所有这些组件交给我们，并根据构建系统的需要，自行挑选所需的能力，因为你可能在构建聊天应用，也可能在构建完整的编排平台。对于你想用智能体解决什么问题，我们并没有太多预设。我们只是想帮助你以安全的方式解决这些问题。所以，如果你从这次演讲中只记住一点，并想来和我们聊聊，那就是：智能体身份验证不再是可选项了。是的，过去几十年里，我们多少设法在没有它的情况下维持了下来，但智能体最近已经证明，它们并不值得信任。现实很复杂。We provide you with service SDKs that you don't have to worry about how they're being authenticated. we also give you gateway if you really want to have those controls, but fundamentally you can bring all of these components to us and kind of pick and choose which one of these capabilities you need to build your system because you might be building a chat application. You might be building a complete orchestration platform. we are fairly unopinionated on the problem you're trying to solve with agents. We're just trying to help you solve these in a secure fashion. so if you take anything out of this talk and want to come talk to us, agent off isn't an option optional anymore. yes, we kind of managed to survive without this for decades, but agents proved themselves recently that they cannot be trusted. reality is messy.

所以，即使你打算尝试构建其中一些组件，也要确保使用开放标准，并能与其他系统互操作，因为单打独斗赢不了这场较量。还有，千万别抱着 YOLO 的心态去做，因为 LLM 无法替你实现这些东西。无论你做什么，都要检查用于实现这些功能的代码是否安全。谢谢。想了解我们的话，欢迎来展位找我们。我们是 Keycard AI。也可以看看 agentbaseline.org。我们最近发布了一个软件工厂参考实现，涵盖了你们刚才看到的所有功能。So, even if you go on a mission of trying to build some of these components, make sure that you use open standards and to be interoperable with other systems because we're not going to win this game by playing alone. and then really don't yellow it because LLMs won't be able to implement this for you. and make sure that whatever you do, check if the code written to implement these capabilities is secure. thank you. if you want to find out about us, come to the booth. We're Keycard AI. also check out agent baseline.org. We have recently kind of released a software factory reference implementation of all of the capabilities that you've seen here.

所以，你可以先学一学，然后来和我们一起研究如何解决这些问题。就这样。So, you can kind of learn and come and work with us on the how to solve this problems. That's it.