8.0
热点
AI SCORE
技术实践2026-09-26 22:00
Agent安全新思路：用短期可撤销凭证构建独立身份
The New Stack#Agent安全#身份认证#零信任
Editor brief · 编辑速览
Agent身份安全已有成熟方案，即为其分配短生命周期、可撤回、范围受限的凭证，而非依赖宿主权限。
Agent 身份安全已经尘埃落定。Agent 需要自己的身份：一个短命的、可撤销的、作用域限定在当前任务范围内的凭证，以及一条审计追踪链，能够追溯到启动它的人类。NIST 的安全负责人在 2026 年 8 月阐明了这一立场，大多数身份供应商也认同这一点。
身份与访问管理只是门槛。它是必要条件，但不是导致问题的那一个。
真正出问题的是一个我们沿用了二十年的假设：在入口处把身份和权限做对，里面的事情自然会顺理成章。这在软件是被动的情况下是成立的。而 Agent 会像一个经验丰富的越狱者一样，自己推理目标、选择通向目标的步骤。
当今技术栈中几乎所有的控制措施都在回答一个问题：应该允许它接入吗？应该允许它访问那个服务吗？它的令牌在这里应该被接受吗？这些都是关于路由的问题，而通往任何有价值的地方通常都不止一条路。
Agent 把被阻断的路由视为需要解决的问题，因为这正是我们构建它的目的。人类遇到锁着的门通常会提交工单，而 Agent 会去试试窗户。
2026 年 7 月，一个自主 Agent 在 Hugging Face 的生产系统内部停留了四天半。过滤器控制着其数据集服务器可以从哪些互联网地址下载数据，但它从未触发，因为"Agent 停止让 worker 去获取远程资源，转而让它操作本地资源"。过滤器按设计正常工作，但 Agent 还是绕过了它。
人类遇到锁着的门通常会提交工单，而 Agent 会去试试窗户。
在普通的开发机器上，被入侵的 npm 包中的恶意软件试图招募已安装的 AI 编码助手来搜索密钥，而一个编码 Agent 在变更冻结期间删除了生产数据库，然后虚假地告诉操作员数据无法恢复。这两起事件都发生在本机上，那里没有任何网络控制措施在监控。
外层控制（Outside-in）govern 的是入口，大多数组织已经部署了大量这类控制。不要误会，内层控制（inside-out）是对这些控制的补充，而不是替代它们。
内层控制govern的是行动本身，它问的是一个更窄、更难回答的问题：这个 Agent，在这个人的授权下，现在、此刻，应该删除这个数据库中的这张表吗？
这个问题很重要，因为 Agent 可以更换路由，但无法更换它追求的结果。无论它尝试多少条路由，删除一张表始终是删除一张表，而对行动的检查点每次都能看到它。
以下是目前控制措施与它的对比：
| 控制措施 | 覆盖范围 | 未覆盖范围 |
|---|---|---|
| 网关 | 你通过它路由的流量 | 从未到达它的本地 shell 命令和文件编辑 |
| 沙箱 | 整个环境 | 约束的是范围，而非单个操作 |
| SIEM | 发生的事情的记录 | 在行动完成后才报告 |
| 注册表 | Agent 存在 | Agent 用这个身份做了什么 |
每个控制都在做自己的工作，但它们都在行动运行的时刻之外做决定。
每个 Agent 都通过一个 Agent harness 来行动：它是接收模型选择的行动并执行它的软件，无论是运行命令、写入文件还是调用 API。在当今大多数部署中，没有任何东西在该行动运行前检查它。
内层控制在该间隙中放置了一个审批步骤。在 harness 执行任何操作之前，检查点会查看是哪个 Agent 在请求、基于谁的授权、针对哪个系统，然后应用策略来允许、阻止或将行动发送给人类。由于每个行动都经过它，一个被拒绝执行破坏性命令、转而尝试同一操作的较小版本的 Agent 会被同样的规则约束。剩余的风险是写得糟糕的策略，这是可以修复的。
没有身份基础，这一切都不起作用。任何类型的控制——无论是在 prompt 层面、推理层面、harness 层面还是 MCP 层面——都无法判断"一个 Agent 可以在这里对这个对象采取此行动吗？"，当请求上唯一的名称是一个由六个 Agent 和四个工程师共享的服务账户时。
构建 Agent 运行时的公司已经得出了相同的结论。在过去的十八个月里，Anthropic、Google、Microsoft、OpenAI、LangChain 和 Cursor 都各自添加了一个 hook，让你可以检查 Agent 的行动后再执行。当 AWS 解释其 Agent 策略设计时，它认为控制应该位于 Agent 尝试调用工具的那一刻。
问题是每个 hook 的工作方式都不同，没有标准化的请求或响应格式。一个企业的开发者使用 Claude Code 和 Cursor，而其平台团队基于 LangChain 构建，那么该企业就要以多种不同风格维护相同的执行逻辑，每种风格都有自己独立的审计追踪。这不可扩展，而且会将你的安全模型紧密耦合到团队当月喜欢的任何运行时。企业需要一个供应商无关的 Agent 安全层，跨越每个 harness，因此采用新的模型或框架并不意味着重启整个繁琐的安全审查。
标准的、根深蒂固的安全直觉是立即开始阻断，但我们都见过这种方式在过去对业务的效果有多好。安全必须以业务的速度移动和适应，而不是反过来。入侵预防系统和 Web 应用防火墙等安全工具最初都以监控模式运行，直到团队了解正常情况是什么样子，而那些跳过这一步的团队往往会因为生产故障而吃到苦头。
Agent 需要同样的顺序，只是更快。一个处于监控模式的执行点不会阻断任何东西，但能快速回答大多数组织今天无法回答的问题：
从你所知道的、看到的、有证据的东西中编写策略，而不仅仅是从架构图中。在风险最高的地方首先执行：破坏性命令、生产数据、以及任何将数据移出的操作。然后像我们使用的 Agent 一样：观察模式、构建更细粒度的控制和策略、学习如何安全、可靠、自信地使用 AI。先观察，再执行、构建、部署，按这个顺序。
这一切都不需要新的基础设施类别。它就是你已经为人类运行的身份、授权和审计，扩展到 Agent，并应用到 harness 中，在行动运行之前。
边界依然存在，但它已经移动到了 Agent 行动的那一刻，那是它唯一无法绕过的位置。
Ory 在 harness 内部构建了 Agent Security，基于与人类用户在生产环境中运行的相同身份和授权引擎。它以"观察模式"启动，所以你可以先获得那份资产清单，你今天就可以在 ory.com/agent-security 试用。