主页
自主 Agent 打破了身份系统七十年来的一条隐含假设:每个请求背后站着一个人。当 Agent 在你下班后自己触发任务、在多人频道里替一屋子人干活时,「用谁的权限」这个问题第一次没有正确答案。这份文档讲清 Agent 身份(agent identity)是什么、怎么落地、什么时候该上。
Autonomous agents break an assumption that identity systems have quietly relied on for seventy years: that behind every request stands a person. When an agent fires its own task after you've logged off, or works on behalf of a room full of people in a shared channel, the question "whose permissions apply?" has no right answer for the first time. This guide covers what agent identity is, how to implement it, and when you actually need it.
如果你只读一段,读这段。
If you read only one paragraph, read this one.
Agent 身份(agent identity)指的是:让 AI Agent 在它要访问的每个系统里拥有自己的账号和凭据,而不是拿着某个人的令牌去代办事情。它把访问控制的问题从「这个用户能做什么」改写成「这个Agent在这个隔间里能做什么」。
Agent identity means giving an AI agent its own accounts and credentials in every system it touches, rather than having it carry a person's token around and act on their behalf. It rewrites access control from "what can this user do?" to "what can this agent do in this compartment?"
推动它的是两股力量。一是自主性:Anthropic 引用的数据显示,Agent 能可靠独立完成的任务长度大约每四个月翻一番,它现在会自己安排任务、在提问的人早已登出之后才动手。二是多人协作:当一个频道里三个工程师和一个 PM 一起找 bug,没有哪个人的权限是「永远正确」的那个。
Two forces drive it. First, autonomy: by the figure Anthropic cites, the length of task an agent can reliably complete on its own has been roughly doubling every four months. Agents now schedule their own work and act long after the person who asked has logged off. Second, multiplayer teams: when three engineers and a PM debug together in one channel, no single person's permissions are the right ones all of the time.
如果你的 Agent 只在一个人面前、只在那个人盯着的时候干活,「以用户身份行事」还够用。一旦它开始异步触发、服务多人、或调用别人也能间接受益的工具,你就需要 Agent 身份——否则一个共享入口就是通往某个人私有文档的侧门。
If your agent works for one person, only while that person is watching, "act as the user" is still fine. The moment it starts firing asynchronously, serving multiple people, or calling tools whose results others can see, you need agent identity — otherwise a shared entry point becomes a side door into someone's private documents.
图 1:三种让 Agent 拿到访问权的做法。①②是今天的主流,③是 Anthropic 在 Claude Tag 里采用的模型。「爆炸半径」指凭据一旦被滥用能波及的范围。数据来源见文末来源 [1][6]。
Figure 1: Three ways to give an agent access. ① and ② are today's defaults; ③ is the model Anthropic adopted for Claude Tag. "Blast radius" is how far a credential's misuse can reach. Data from sources [1] and [6] at the end.
先讲痛点。定义留到下一章。
Pain points first. Definitions come next.
身份与访问管理(IAM,Identity and Access Management,就是「谁能访问什么」那套系统)有一条从未写在文档里的假设:每一个到达服务器的请求,背后站着一个当时正在操作的人。会话超时、二次确认、审计日志里的「操作人」字段——全都建立在这条假设上。
Identity and Access Management (IAM — the machinery that decides who can reach what) rests on an assumption nobody ever wrote down: behind every request arriving at a server stands a person who is operating right now. Session timeouts, step-up confirmations, the "actor" field in your audit log — all of it is built on that premise.
自主 Agent 把这条假设的三根支柱同时打断了。
Autonomous agents snap all three legs of that assumption at once.
Anthropic 在介绍 Claude Tag 访问模型的文章里给出的判断是:Agent 能可靠独立完成的任务长度大约每四个月翻一番;Agent 现在会「自己为将来安排任务,并在提出请求的人早就登出之后响应事件」。用户设定的是「在什么情况下触发」的例行程序,真正干活的时候 Agent 基本是自主的。(来源 [1],Anthropic/Claude 博客)
In the post introducing Claude Tag's access model, Anthropic's framing is that the length of task an agent can reliably complete on its own has been doubling roughly every four months. Agents now "schedule their own tasks for later and respond to events long after the person who asked has logged off." Users set up routines that trigger the agent given certain conditions; the actual work happens largely autonomously. (Source [1], Anthropic/Claude blog)
Anthropic 举的例子很具体:一个频道里三个工程师和一个 PM 一起 debug。「当不止一个人在掌舵时,谁的权限算数?」他们的结论是:没有哪一个人的选择在所有时候都是对的。(来源 [1])
Anthropic's example is concrete: a channel where three engineers and a PM are debugging together. "When more than one person is steering, whose permissions apply?" Their conclusion: there's no single choice of person that would be right all of the time. (Source [1])
这一根断得最安静,后果却最贵。当 Agent 用你的令牌行动时,所有下游系统的日志里写的都是你。业界把这叫做归因鸿沟(attribution gap)。据 Kiteworks 的分析,三分之二的组织无法向监管方说清它们的 AI Agent 做了什么、为什么做;而「只记录大模型的回复、不记录底层的工具调用、scope 与下游授权决策」,产生的是一份看起来存在、取证时没用的审计轨迹。(来源 [7],厂商分析,属行业观点而非官方标准)
This one snaps most quietly and costs the most. When an agent acts on your token, every downstream log records you as the actor. The industry calls this the attribution gap. Per Kiteworks' analysis, two-thirds of organizations can't tell a regulator what their AI agents did or why; and logging only the model's response — without the underlying tool invocations, scopes, and downstream authorization decisions — produces an audit trail that looks present but is useless for forensics. (Source [7]; vendor analysis — an industry view, not an official standard.)
以上数字来自安全厂商与云安全联盟(CSA)的行业调查汇总(来源 [6][7][8])。这些是调查口径的统计而非官方普查,不同报告的定义与样本差异较大,请当作数量级参考而非精确值。
These figures come from security-vendor and Cloud Security Alliance (CSA) survey roundups (sources [6][7][8]). They are survey-based statistics, not an official census; definitions and samples vary considerably between reports, so treat them as order-of-magnitude signals rather than precise values.
「以用户身份行事」相当于:你把自己的员工门禁卡借给一个新来的实习生,让他去帮你取个快递。他确实能取到快递——顺便也能刷开财务室、机房和 CEO 办公室。而且门禁记录上,今晚三点进机房的人,写的是你。
"Act as the user" is like handing your employee badge to a new intern so they can pick up a package for you. They can get the package — and also open the finance room, the server room, and the CEO's office. And the badge log says you were the one who walked into the server room at 3am.
每个术语先给人话解释,再给严谨表述。
Plain-language first, precise formulation second.
主体(principal)与非人身份(NHI)
Principal and non-human identity (NHI)
人话:「主体」就是权限系统眼里「能干事的那个东西」。过去几乎只有两类:人,和跑在服务器上的程序(服务账号)。非人身份(Non-Human Identity, NHI)是给后者起的统称——API 密钥、服务账号、CI 流水线的令牌,现在还要加上 AI Agent。
In plain terms: a "principal" is whatever the permission system sees as capable of acting. Historically there were basically two kinds: people, and programs running on servers (service accounts). Non-human identity (NHI) is the umbrella term for the latter — API keys, service accounts, CI pipeline tokens, and now AI agents.
为什么 Agent 不能直接归进「服务账号」:服务账号的行为是写死在代码里的,你审一遍代码就知道它会做什么;Agent 的行为由运行时的自然语言输入决定,同一套凭据今天用来查订单、明天可能被一段藏在网页里的文字骗去发邮件。
Why an agent isn't just a service account: a service account's behaviour is fixed in code — read the code and you know what it does. An agent's behaviour is decided at runtime by natural-language input, so the same credential that queries orders today can tomorrow be talked into sending email by text hidden in a web page.
委派链(delegation chain)
Delegation chain
人话:一句能写进日志的话——「Agent X 依据策略 Y、受用户 Z 委派,执行了这个动作」。三个信息缺一个,事后就说不清责任。
In plain terms: one sentence you should be able to write into a log — "Agent X performed this action under Policy Y, delegated by User Z." Drop any of the three and accountability becomes unprovable after the fact.
技术上的常见承载方式:Agent 出示一个签名的 JWT(一种自带签名、可离线校验的令牌),里面装着它自己的身份(sub 声明)、被委派的用户身份(act 或 on-behalf-of 声明)、scope 和过期时间。这个「Agent 代表用户、在此 scope 内」的结构,恰恰是「人」和「服务账号」两个旧类别都表达不了的。(来源 [9],行业实践综述)
The common technical shape: the agent presents a signed JWT (a token that carries its own signature and can be validated offline) containing its own identity (the sub claim), the delegated user identity (an act or on-behalf-of claim), the scope, and an expiry. That "this agent, on behalf of this user, within this scope" structure is precisely what neither the "human" nor the "service account" category captures cleanly. (Source [9], industry practice roundup)
混淆代理人问题(confused deputy)
The confused deputy problem
人话:一个手里有权限的「代办人」被外人骗着,用自己的权限去干了外人没资格干的事。经典例子就是本周的 Copilot 事件:受害者点开一条链接,Copilot 用受害者自己的权限去翻收件箱、把找到的密码打包发给攻击者。Copilot 全程没有「越权」——它只是被说服了。
In plain terms: a deputy that holds authority gets talked by an outsider into using that authority for something the outsider isn't entitled to. This week's Copilot incident is the textbook case: the victim clicks a link, and Copilot uses the victim's own permissions to search their inbox and ship the passwords it finds to the attacker. Copilot never "exceeded" its privileges — it was simply persuaded.
学术侧正在把它形式化。arXiv 2606.28679《Capability Gates Are Not Authorization》指出:主流 Agent 框架里的「能力开关」(这个 Agent 能不能调这个工具)不等于授权(这次调用在这个上下文里该不该被允许),并提出 ScopeGate——一个覆盖 scope、授权、金额上限、幂等性、默认拒绝的五阶段策略决策/执行点。arXiv 2605.05440 则从多 Agent 系统角度讨论「授权不变式如何沿委派链传播」,指出这类攻击可以在没有人工逐步审核的情况下跨组织边界扩散。(来源 [4][5])
Academia is formalising it. arXiv 2606.28679, Capability Gates Are Not Authorization, argues that the "capability gates" in mainstream agent frameworks (can this agent call this tool?) are not authorization (should this particular call be allowed in this context?), and proposes ScopeGate — a five-stage policy decision/enforcement point covering scope, authorization, a money ceiling, idempotency, and default deny. arXiv 2605.05440 approaches it from the multi-agent side, examining how authorization invariants propagate along delegation chains and noting that such attacks can traverse organizational boundaries without human review at each step. (Sources [4][5])
零常驻权限(zero standing privilege)与即时授予(JIT)
Zero standing privilege and just-in-time (JIT) access
人话:平时什么权限都不给,要用的时候临时发一张有期限、只够干这一件事的通行证,用完自动失效。反面是「一次开通、长期挂着」——安全圈把后者的后果叫做持久爆炸半径(persistent blast radius):凭据活得比它的用途还久,并且无限期地可被利用。(来源 [6])
In plain terms: hold no privileges by default; when work needs doing, issue a time-boxed pass scoped to that one task that expires on its own. The opposite is "provision once, leave it hanging" — which the security community calls a persistent blast radius: credentials that outlive their operational context and stay exploitable indefinitely. (Source [6])
Agent 身份(agent identity)
Agent identity
人话:把上面几件事合起来的产品化答案——Agent 在每个系统里有自己的账号,权限按隔间(频道、项目、租户)而不是按人来划,吊销这个身份就等于在所有地方同时断权。
In plain terms: the productised answer that ties the above together — the agent holds its own account in each system, permissions are scoped per compartment (channel, project, tenant) rather than per person, and revoking the identity ends its access everywhere at once.
Anthropic 的原话是:agent identity 把「这个用户能做什么」替换成「这个 Agent 在这个隔间里能做什么」,并明确承认这是对传统按用户 ACL 的一次偏离——它意味着一个本身没有仓库权限的频道成员,可以让 Claude 去读那个仓库,只要频道的 profile 授予了 Claude 这项权限。(来源 [1])
In Anthropic's own words, agent identity replaces "what can this user do?" with "what can this agent do in this compartment?" — and they explicitly acknowledge this is a departure from per-user ACLs: it means a channel member without direct repo access can ask Claude to read that repo, provided the channel's profile grants Claude that permission. (Source [1])
Agent 是一类新的主体(既非人也非传统服务账号);它行动时应当携带完整的委派链(谁、依据什么、代表谁);因为它会被自然语言说服,所以必须假设混淆代理人攻击一定会发生;因此权限要零常驻、即时授予;把这一整套做成产品形态,就叫 Agent 身份。
An agent is a new class of principal (neither human nor traditional service account); when it acts it should carry a full delegation chain (who, under what policy, on whose behalf); because it can be persuaded by natural language, you must assume confused deputy attacks will happen; therefore privileges should be zero-standing and issued just in time; and packaging all of that into a product shape is what's called agent identity.
有对比才知道什么时候该选谁。
Comparison is how you know which one to pick.
| 维度 | ① 以用户身份行事 | ② 共享服务账号 | ③ Agent 身份 |
|---|---|---|---|
| 凭据来自 | 用户的 OAuth 令牌 | 管理员开的一个长期账号 | 每个隔间一套独立凭据 |
| 权限边界 | = 那个用户的全部权限 | = 「以后可能用到的一切」 | = 该隔间被显式授予的部分 |
| 异步执行 | ❌ 人不在时仍持有其全部权限 | ✅ 可以 | ✅ 可以 |
| 多人场景 | ❌ 无解 | ⚠️ 能跑,但谁触发的分不清 | ✅ 隔间即边界 |
| 日志里的动作人 | 那个用户(归因错误) | 一个共享账号(归因太粗) | Agent 自己的服务账号 |
| 吊销成本 | 要撤用户的令牌(误伤本人) | 撤了所有 Agent 一起停 | 吊销该身份即可 |
| 适合 | 单人、同步、盯着看的助手;私聊场景 | 行为固定、无自然语言输入的自动化 | 多人、异步、跨系统的团队 Agent |
| Dimension | ① Act as the user | ② Shared service account | ③ Agent identity |
| Credential source | The user's OAuth token | One long-lived admin-provisioned account | A separate credential set per compartment |
| Permission boundary | = everything that user can do | = "whatever it might eventually need" | = what this compartment explicitly granted |
| Async execution | ❌ Holds full user access while nobody's there | ✅ Works | ✅ Works |
| Multiplayer | ❌ No answer | ⚠️ Runs, but you can't tell who triggered it | ✅ The compartment is the boundary |
| Actor in the logs | That user (wrong attribution) | A shared account (attribution too coarse) | The agent's own service account |
| Cost to revoke | Revoke the user's token (collateral damage) | Revoking stops every agent at once | Revoke that one identity |
| Best for | Single-user, synchronous, supervised assistants; DMs | Fixed-behaviour automation with no natural-language input | Multiplayer, async, cross-system team agents |
Anthropic 自己的产品里两种模式共存:共享频道用 Agent 身份,而私聊(DM)仍然跑在用户自己的 claude.ai 账号上——用他们的连接器、凭据,结果署他们的名。原因很实际:草拟邮件、使用只有你有 license 的软件,这些工作本来就不该进频道。(来源 [1])
Both modes coexist in Anthropic's own product: shared channels use agent identity, while direct messages still run on the user's own claude.ai account — their connectors, their credentials, their name on the result. The reasoning is practical: drafting email, or using software only you hold a licence for, is work that shouldn't live in a channel in the first place. (Source [1])
图 2:混淆代理人攻击的完整链路,以及 Agent 身份体系里对应的四道防线。攻击路径依据 2026-08-18 Varonis 披露的 Copilot 案例(来源 [3]);防线 A/B/C 对应 Anthropic 描述的 Claude Tag 机制(来源 [1])。
Figure 2: The full confused-deputy chain, and the four defences agent identity puts against it. Attack path follows the Copilot case disclosed by Varonis on 2026-08-18 (source [3]); defences A/B/C map to the Claude Tag mechanisms Anthropic describes (source [1]).
别把这些标准当成互相替代的选项——它们回答的是不同的问题。
Don't treat these standards as competing options — they answer different questions.
调研中最容易造成混乱的一点是:SPIFFE 和 OAuth 经常被摆在一起问「选哪个」。但它们不在同一层。一句话区分:SPIFFE 回答「这真的是服务 X 吗」,OAuth 回答「服务 X 能不能访问资源 Y」;合起来才有端到端的保证——连接时的身份 + 访问时的策略。(来源 [10],厂商技术博客综述)
The most common confusion in this space is people asking whether to "pick SPIFFE or OAuth." They aren't at the same layer. The clean split: SPIFFE answers "is this really service X?", OAuth answers "can service X access resource Y?" Together they give end-to-end assurance — identity at connection time, policy at access time. (Source [10], vendor technical blog roundup)
图 3:四层各回答一个不同的问题,自上而下是「身份 → 委派 → 授权 → 审计」。第 1 层来源 [10],第 2 层来源 [9][11],第 3 层的五阶段划分来自 arXiv 2606.28679(来源 [4]),第 4 层来源 [7]。
Figure 3: Each layer answers a different question — identity → delegation → authorization → audit, top to bottom. Layer 1 from source [10]; layer 2 from [9][11]; the five-stage split in layer 3 comes from arXiv 2606.28679 (source [4]); layer 4 from [7].
SPIFFE(Secure Production Identity Framework For Everyone)是一套工作负载身份标准。它的核心动作叫证明(attestation):Agent 要先证明自己是「跑在哪个集群、哪个命名空间、由哪个部署产生的那个进程」,才能拿到一份 SVID(SPIFFE Verifiable Identity Document)。SVID 可以是 X.509 证书或 JWT,都绑在一个 spiffe://信任域/服务 形式的标识符上,并且生命周期很短、由 SPIRE agent 自动轮转。
SPIFFE (Secure Production Identity Framework For Everyone) is a workload identity standard. Its central move is attestation: an agent must first prove it is "the process running in this cluster, this namespace, produced by this deployment" before it receives an SVID (SPIFFE Verifiable Identity Document). An SVID can be an X.509 certificate or a JWT, each tied to a spiffe://trust-domain/service identifier, and both are short-lived and rotated automatically by the SPIRE agent.
关键差别在于:API 密钥和 OAuth client credentials 的身份就是那个秘密本身——秘密泄露 = 身份被冒用。SVID 的身份绑在被证明的工作负载属性上,不是一个可以复制走的字符串。(来源 [10])
The key difference: with an API key or OAuth client credentials, the identity is the secret — leak the secret and the identity is impersonated. An SVID's identity is bound to attested workload attributes, not to a string you can copy away. (Source [10])
SPIFFE 好归好,部署它要跑一个 SPIRE server(或等价物)、配置信任域、为每种工作负载类型接入 attestor、并把 SVID 铺进运行时。有厂商直言:对一个只有三个工程师、没有平台团队的团队,这是实打实的工作量;而且即使部署成功,仍有一类凭据根本无法表达成 SVID。(来源 [10],厂商观点,该厂商本身销售替代方案,请注意立场)
SPIFFE is good, but deploying it means running a SPIRE server (or equivalent), configuring trust domains, wiring up attestors per workload type, and rolling SVIDs through your runtime. One vendor puts it bluntly: for a team of three engineers with no platform team, this is real work — and even where it is deployed, a category of credentials simply cannot be expressed as SVIDs. (Source [10]; vendor viewpoint — note that the vendor sells an alternative.)
如果你的 Agent 通过 MCP(Model Context Protocol,一套让模型接工具的开放协议)调工具,这一条直接相关。2026-07-28 版 MCP 规范强化并澄清了授权模型,使 OAuth / OpenID Connect 的部署更贴近既有实践,并把 EMA 升格为正式扩展。
If your agent calls tools through MCP (Model Context Protocol, the open protocol that connects models to tools), this is directly relevant. The 2026-07-28 MCP specification strengthened and clarified the authorization model, aligning OAuth / OpenID Connect deployment more closely with established practice, and promoted EMA to an official extension.
EMA 的机制:企业身份提供方(IdP)用来自 Cross-App Access(XAA)的 Identity Assertion JWT Authorization Grant(ID-JAG) 断言,来管辖「哪个 MCP 客户端、代表哪个用户、可以访问哪个 MCP 服务器」。IdP 按管理员策略签发断言,MCP 服务器的授权服务器校验后自行签发受限令牌——整个过程不需要逐用户的同意屏。(来源 [2],MCP 官方博客 + Descope 技术解读)
How EMA works: the enterprise identity provider (IdP) governs which MCP client can reach which MCP server on behalf of which user, using the Identity Assertion JWT Authorization Grant (ID-JAG) from Cross-App Access (XAA). The IdP issues a signed assertion under admin policy; the MCP server's authorization server validates it and mints its own scoped tokens — with no per-user consent screens anywhere in the flow. (Source [2], MCP official blog plus Descope's technical write-up)
从「你现在大概率的状态」走到「可审计的 Agent 身份」。
From where you probably are today to an auditable agent identity setup.
「从宽起步」是 Anthropic 基于自家内部使用给出的建议,他们同时给出了配套条件:身份边界够硬、审计轨迹可读、可以逐条收缩。而安全侧的主流建议恰恰相反——零常驻权限、即时授予、最小权限。两边其实不矛盾:前者说的是「授予哪些系统」,后者说的是「在被授予的系统里能做到什么程度」。但如果你所在行业受强监管,建议按后者的默认立场起步。
"Start broad" is Anthropic's advice based on their own internal use, and they attach conditions: firm identity boundaries, a readable audit trail, and the ability to pare back one grant at a time. The mainstream security recommendation runs the other way — zero standing privilege, just-in-time, ruthless least privilege. The two aren't really in conflict: the first is about which systems to connect, the second about how far the agent can go inside a connected system. But if you work in a heavily regulated industry, start from the second posture by default.
这是目前公开细节最完整的生产级实现。要点已在前几节引用,这里补三个容易漏掉的设计决定:
This is currently the most fully documented production implementation. The main points appeared in earlier sections; here are three design decisions that are easy to miss:
来源 [1]。该文由 Claude Code 团队成员 Noah Zweben 撰写,发布于 2026-06-24;文中的产品状态可能已变化,以官方最新文档为准。
Source [1]. Written by Noah Zweben of the Claude Code team, published 2026-06-24; product state may have changed since — check the current official docs.
?autorun=1(2026-08-18 披露)?autorun=1 (disclosed 2026-08-18)安全公司 Varonis 通过反复追问 Copilot 自身的护栏逻辑,套出了一个未公开的参数 ?autorun=1。与已知的 ?q= 组合后,受害者点开一条链接的瞬间就会静默执行一段 prompt:Copilot 去搜索受害者的收件箱、找出密码等敏感数据、base64 编码、发往攻击者控制的服务器。研究者还演示了藏在网页里的提示注入污染 Copilot 的持久化记忆——这种攻击连改密码都清不掉。微软在收到报告三个月后(2026 年 2 月)发了部分修复,直到 2026-08-18 那周的周二才发出较完整的修复。(来源 [3],Ars Technica)
Security firm Varonis extracted an undocumented parameter, ?autorun=1, out of Copilot itself by repeatedly questioning it about its own guardrails. Combined with the known ?q= parameter, the string let an attacker-crafted link silently execute a prompt the moment a victim clicked it: Copilot searched the victim's inbox for passwords and other sensitive data, base64-encoded it, and sent it to an attacker-controlled server. The researchers separately demonstrated a prompt injection hidden in a web page that poisoned Copilot's persistent memory store — an attack that survives even a password change. Microsoft issued a partial fix three months after the report (February 2026) and only shipped a more comprehensive fix on the Tuesday of the week of 2026-08-18. (Source [3], Ars Technica)
一:向助手追问它自己的安全逻辑,本身就是一种攻击侦察——这条对任何做 Agent 产品的人都适用。二:攻击全程没有任何权限被突破,Copilot 用的自始至终是受害者自己的访问权;这正是「以用户身份行事」的结构性问题,而不是某个 bug。三:给助手加长期记忆,等于给攻击者加一块可持久化的攻击面。
One: interrogating an assistant about its own safety logic is itself a form of attack reconnaissance — relevant to anyone shipping an agent product. Two: no privilege was ever breached in this attack; Copilot used the victim's own access throughout. That is the structural problem with "act as the user," not a particular bug. Three: giving an assistant long-term memory hands attackers a persistent new surface to exploit.
区分「官方承认的限制」与「社区/厂商的反馈」。
Distinguishing acknowledged limits from community and vendor observations.
Anthropic 用了「unusual」这个词来形容:一个本身没有仓库权限的频道成员,可以让 Claude 去读那个仓库。这是从按用户 ACL 的一次有意偏离,不是 bug。所以隔间划得不对,后果就是「换个通道就绕过了原有的权限设计」。缓解办法就是前文第 2、7 步:把 profile 收缩到该隔间权限最低成员的水平,并读审计轨迹再扩。(来源 [1])
Anthropic uses the word "unusual" for it: a channel member without direct repo access can ask Claude to read that repo. That is a deliberate departure from per-user ACLs, not a bug. So if you draw compartments badly, the consequence is that a new channel becomes a way around your existing permission design. The mitigation is steps 2 and 7 above: scope each profile to the compartment's least-privileged member, and read the audit trail before extending. (Source [1])
这是学术侧点名批评的那条:能力开关 ≠ 授权。给 Agent 发一个 SVID、让它以自己的身份登录,解决的是「它是谁」;但「它这次要花 5000 块下单,该不该批」是另一层的问题。没有第 3 层的策略关卡,你只是把一个匿名的过度授权,换成了一个署名的过度授权。(来源 [4],arXiv 2606.28679)
This is the one academia calls out by name: capability gates are not authorization. Issuing an agent an SVID so it logs in as itself solves "who is this?"; whether this particular $5,000 order should go through is a different layer. Without a layer-3 policy gate, all you've done is turn an anonymous over-privileged actor into a named over-privileged actor. (Source [4], arXiv 2606.28679)
只记录大模型的回复,不记录底层的工具调用、scope 和下游授权决策——这份日志过不了取证。判断标准很简单:随便挑一条历史记录,你能不能填满「Agent X / 策略 Y / 委派人 Z」三个空?填不满就是有鸿沟。(来源 [7],厂商分析)
Logging only the model's response, without the underlying tool invocations, scopes and downstream authorization decisions, produces a trail that fails in forensics. The test is simple: pick any historical record and try to fill in "Agent X / Policy Y / Delegator Z." If you can't, you have the gap. (Source [7], vendor analysis)
一句被反复引用的话:一个人做出一次糟糕的访问决定,影响一起事件;一个 Agent 做出同样的决定,可能在有人发现之前影响成千上万条记录。这就是为什么「等出事了再收紧」在 Agent 场景下比在人的场景下贵得多。(来源 [7],厂商分析,属观点)
A line worth repeating: a human making one bad access decision affects one incident; an agent making the same decision can affect thousands of records before anyone notices. That's why "tighten it after something goes wrong" costs far more with agents than with people. (Source [7], vendor analysis — a viewpoint, not a measurement)
截至调研时,这个领域正在从四个方向同时补齐:面向 Agent 委派的 OAuth 2.1 扩展、SPIFFE/SVID 工作负载身份、商业平台,以及一批试图标准化 Agent 身份语义的 IETF 草案(如 WIMSE,把 AI 中介归为委派工作负载的一个特例,并要求自主动作与委派动作必须通过独立的工作负载身份或 token scope 明确区分)。草案不等于标准,建议把身份层做成可替换的适配层。(来源 [11],综述性技术博客;IETF 草案状态请以 IETF 官方为准)
As of this research date, the gap is being patched from four directions at once: OAuth 2.1 extensions for agentic delegation, SPIFFE/SVID workload identity, purpose-built commercial platforms, and a run of IETF drafts trying to standardise agent identity semantics (WIMSE, for instance, classifies AI intermediaries as a special case of delegated workloads and requires that autonomous actions be clearly distinguished from delegated ones through separate workload identities or token scopes). A draft is not a standard — keep your identity layer behind a replaceable adapter. (Source [11], survey-style technical blog; for IETF draft status consult the IETF directly.)
调研中未能核实的:多份厂商材料引用了一项 EY 调查,称「99% 的组织报告了 AI 相关风险造成的财务损失,64% 损失超过 100 万美元」。我们没能找到该调查的一手来源与方法学说明,此处仅作转述、不建议引用。
Not verified in this research: several vendor pieces cite an EY survey claiming "99% of organizations reported financial losses from AI-related risks, with 64% suffering losses over $1M." We could not locate the primary source or its methodology, so this is relayed here only, and we don't recommend citing it.
spiffe://信任域/服务。spiffe://trust-domain/service.标签说明:官方=一手厂商/标准来源;报道=新闻机构;论文=arXiv 预印本;厂商观点=安全厂商分析,有立场,已在正文标注。
Tag key: Official = first-party vendor or standards source; Press = news outlet; Paper = arXiv preprint; Vendor view = security-vendor analysis with a commercial stake, flagged as such in the text.