Over the past year I’ve reviewed enterprise agent architectures at roughly two dozen organizations, including banks, retailers, healthcare systems, and a couple of regulators. The architecture diagrams have been reliably impressive. There are boxes for the MCP gateway, the tool registry, the vector store, the orchestrator, the policy engine, and the observability stack. There are arrows showing how agents discover each other, share context, and call tools across the mesh. By 2026 standards, these are the table-stakes pictures for any serious agentic deployment. But what none of them show anywhere is who the agents are, whose authority they carry, or who answers when they’re wrong.在过去的一年里，我审查了大约二十多家组织的企业代理架构，包括银行、零售商、医疗系统以及一些监管机构。这些架构图始终令人印象深刻。图中有 MCP 网关、工具注册表、向量存储、编排器、策略引擎和可观测性栈的方框。还有箭头展示代理如何相互发现、共享上下文以及在网格中调用工具。按 2026 年的标准，这些已经是任何严肃的代理部署的基本配置。但它们从未显示代理到底是谁、代表谁的权威，或者出错时该由谁负责。
That omission has a name worth using: principal drift, the steady decoupling, in any sufficiently large agent system, between the human authority a recorded action is supposed to derive from and the actor that actually took it. What looks like a defensible identity posture on the day you ship your first agent quietly degrades as agents multiply, compose, and outlive their original initiatives. Principal drift isn’t three independent failure modes; it’s one cascade. Identity collapses first. Authority erodes next, because there is no longer a stable principal to bind policy to. Accountability dissolves third, because the cost of agent error lands on whichever team has the weakest negotiating position when the incident review starts. Stopping the cascade means intervening at the first link, but almost no enterprise agent platform does so right now.这种遗漏有一个值得使用的名称：主体漂移——在任何足够大的代理系统中，记录的行为应来源于的人类权威与实际执行者之间的持续脱钩。你在首次悄悄发布代理的那一天看似合理的身份姿态，随着代理数量的增加、组合以及超出最初计划的寿命而逐渐恶化。主体漂移不是三种独立的失效模式；它是一个连锁反应。身份首先崩塌。随后权威被侵蚀，因为已经没有稳定的主体可以绑定策略。最后问责制消失，因为当事故审查开始时，错误成本落在谈判地位最弱的团队上。要阻止这种连锁反应，需要在第一环节介入，但几乎没有企业代理平台现在能够做到这一点。
To see the cascade run, take the most boring possible enterprise agent, a refund agent, and watch.要看到连锁反应的运行，拿最无聊的企业代理——退款代理，观察它的表现。
A customer-service rep, fielding a chat, asks the agent to process a $48 refund for a damaged item. The agent checks eligibility, issues the refund, posts an update. The audit log records the action as taken by something like refund-agent-prod-03, running under a service principal owned by the customer-service platform team. That entry is true, but it’s also useless. The agent wasn’t acting as refund-agent-prod-03. It was acting as the rep, on behalf of the customer, under a delegation chain nobody recorded. In a well-built system, customer, rep, agent identity, and service principal are recorded together, queryable as a chain, and durable beyond the session. In most production systems today they aren’t. This is the first link in the cascade, where identity collapses to a generic service principal, and there’s no longer a who to attach anything else to.一名客服代表在聊天中让代理为一件损坏的商品处理 48 美元的退款。代理检查资格，执行退款并发布更新。审计日志记录的操作是由类似 refund-agent-prod-03 的实体在客户服务平台团队拥有的服务主体下执行的。该条目虽属实，却毫无价值。代理并不是以 refund-agent-prod-03 的身份在行动，而是以代表客户的客服代表身份，在一个无人记录的委托链下运行。在一个构建良好的系统中，客户、客服代表、代理身份和服务主体会一起记录，可作为链查询，并在会话结束后仍然持久存在。而在大多数生产系统中并非如此。这是连锁反应的第一环，身份坍塌为一个通用的服务主体，已不再有“谁”可以附加其他信息。
Authority erodes next. The refund agent has an issue_refund tool that can technically refund any order. Its authority is supposed to be narrower (refunds up to $200, orders under 90 days, customers in good standing, automatic escalation above $50), but that authority lives in a prompt or a YAML file or a Notion page the team last updated when the policy was different. The runtime enforces capability, but nobody really enforces authority. When a poisoned input or a confused chain of reasoning leads the agent to refund $1,800 to the wrong customer, there’s no clean answer to the postincident question “Who approved this policy?” because the policy was never an artifact. The same pattern is worse at higher stakes: Imagine a coding agent with merge access to a protected branch, instructed by a prompt embedded in a code comment to “log configuration values for debugging,” silently exfiltrating secrets to an external monitoring service.接下来是权威的侵蚀。退款代理拥有一个 issue_refund 工具，技术上可以退款任何订单。它的权威本应更窄（退款上限 200 美元，订单在 90 天内，客户信用良好，超过 50 美元自动升级），但这些权威信息存放在提示词、YAML 文件或团队上次更新政策时的 Notion 页面中。运行时会强制能力，但几乎没有人真正强制权威。当有毒输入或混乱的推理链导致代理错误地给错误的客户退款 1,800 美元时，事后根本无法回答“谁批准了这项政策？”因为政策从未以文档形式存在。更高风险的场景更糟：想象一个拥有受保护分支合并权限的代码代理，依据嵌入代码注释的提示词“记录配置值以调试”，悄悄将机密泄露给外部监控服务。
Accountability then dissolves. The team that built the agent says it followed policy. The team that wrote the policy says it didn’t anticipate the input. The team that operates the platform says the agent was running as a service principal whose behavior they don’t own. The audit log may show the action, but it doesn’t show the reasoning that produced the action, the retrieved context that shaped the reasoning, or the prompt history that framed the retrieval. Postincident review becomes archaeology, and the cost is absorbed, eventually, by whoever has the weakest negotiating position when the meeting ends.随后是问责的消解。构建代理的团队说他们遵循了政策。编写政策的团队说他们没有预见到该输入。运营平台的团队说代理是以他们不拥有的服务主体运行。审计日志可能显示了操作，但没有显示产生该操作的推理、形成推理的检索上下文或框定检索的提示历史。事后审查变成考古，最终成本由会议结束时谈判地位最弱的那方承担。
Is any of this new? We have IAM, identity governance, policy as code, audit trails, SIEMs, and 30 years of compliance practice. Why isn’t this just IAM done properly? Because IAM was built around assumptions agents violate. IAM and IGA assume a population of principals that changes on human timescales: People get hired, people leave, and service accounts rotate quarterly. Agents are spun up per session and compose into chains where one agent calls another, which calls a third, impersonating users through delegated tokens that traditional IGA cannot represent as a chain at all. Policy engines fire at the moment of action, at the API, the database, and the network. Agents make their most consequential decisions before they hit those enforcement points, in the reasoning step that selects which tool to call and with what arguments. Mature audit logs assume that replaying the inputs reproduces the output. But for agents, replaying the prompt and the retrieval can yield a different action, because the model itself contributes state the log doesn’t capture. The instruments fire, the dashboards turn green, and the agent that quietly exfiltrated secrets still does so. The audit log records the action as agent-service-01, which again is both true and useless.这些是新现象吗？我们已有 IAM、身份治理、代码化政策、审计追踪、SIEM 以及 30 年的合规实践。为什么这不是仅仅做好 IAM？因为 IAM 是围绕人类假设构建的，而代理正好违背这些假设。IAM 和 IGA 假设主体人口在人的时间尺度上变化：人被雇佣、离职，服务账号每季度轮换。代理则按会话启动，并组成链式调用——一个代理调用另一个，再调用第三个，通过委托令牌冒充用户，而传统 IGA 根本无法将其表示为链。策略引擎在动作发生的瞬间触发——API、数据库、网络。而代理在触发这些强制点之前，就在推理步骤中决定调用哪个工具以及使用何种参数，这往往是最关键的决定。成熟的审计日志假设重放输入即可重现输出。但对代理而言，重放提示和检索可能产生不同的动作，因为模型本身贡献了日志未捕获的状态。仪表盘显示绿色，代理仍在悄悄泄露机密。审计日志记录的动作是 agent-service-01，这既真实又无用。
This is also where the vendors selling a consolidated stack want you to skip ahead. Microsoft’s Entra Agent ID, currently in public preview, is the most polished solution to date, extending the conditional access, identity governance, and identity protection used for humans and workloads to cover AI agents as a new identity type, but Google and Salesforce are also building this layer. The marketing line is that agents receive the same identity-driven protections as the rest of the workforce. That’s a real step forward in addressing the first link of the cascade, but it isn’t governance. It’s a control plane with a governance plane’s marketing. Conditional access can tell you whether the agent’s access attempt was permitted. It can’t tell you whether the decision the agent made before that access attempt was within its authority, why the agent reached the decision, or which business unit owns the policy the decision was supposed to obey.这也是供应商们希望你跳过的地方。Microsoft 的 Entra Agent ID 目前处于公开预览阶段，是迄今为止最完善的解决方案，将对人类和工作负载使用的条件访问、身份治理和身份保护扩展到 AI 代理作为一种新身份类型，但 Google 和 Salesforce 也在构建这一层。营销口号是代理获得与其他员工相同的基于身份的保护。这在解决连锁反应的第一环上是一步真实的前进，但这并不是治理。它是一个带有治理营销的控制平面。条件访问可以告诉你代理的访问尝试是否被允许，却无法判断代理在发起该访问前的决策是否在其权威范围内，决策为何产生，或是哪一业务单元拥有该决策应遵循的政策。
The actual governance plane has to capture decisions, not just actions. A reasoning-grade audit record is the load-bearing primitive of the missing layer, and it looks something like this:真正的治理平面必须捕获决策，而不仅仅是动作。推理级审计记录是缺失层的承重原语，大致如下所示：
{
"event_id": "refund-2026-05-17-08431",
"triggered_by": {
"human_principal": "rep:olivia.chen@firm.com",
"delegated_via": "support-console-session-9c2a",
"customer_principal": "cust:7741289"
},
"agent": {
"identity": "refund-agent",
"version": "v4.7.2",
"policy_ref": "refund-policy/v3.1 (signed: r.patel, 2026-04-22)"
},
"task": "Process refund for order 88812204",
"retrieved_context": [
{"doc": "order:88812204", "fetched": "2026-05-17T08:43:11Z"},
{"doc": "policy:refund-eligibility", "chunk": 4, "fetched": "2026-05-17T08:43:12Z"}
],
"reasoning_trace": "...",
"tool_calls": [
{"tool": "check_eligibility", "input": "...", "output": "eligible"},
{"tool": "issue_refund", "input": {"amount": 48.00}, "output": "ok"}
],
"action": "refund:48.00",
"principal_chain_hash": "0x9e7b3f..."
}Not every agent needs this. A scheduling agent that proposes meeting times doesn’t. An agent that moves money, deploys code, or makes decisions that a regulator will eventually ask about does need it, and that’s the right bar to set because of the associated cost. Reasoning-grade audit is closer to a flight-data recorder than a syslog feed. The data is expensive to store and to query, with real privacy implications since those logs contain everything the agent saw, including data the agent was authorized to read but the audit system wasn’t supposed to keep. You afford it with proportional retention: full reasoning capture for high-blast-radius agents (regulator-facing, customer-funded, contractually material, production-modifying) and lighter capture for internal-only assistants.并非所有代理都需要此类记录。一个提出会议时间的调度代理不需要。搬钱、部署代码或做出监管机构最终会追问的决策的代理则需要，这也是设定门槛的正确理由，因为伴随而来的成本。推理级审计更像是飞行记录仪，而不是系统日志。数据存储和查询成本高，并且涉及隐私，因为这些日志包含代理看到的所有信息，包括代理有权读取但审计系统不应保存的数据。可以通过比例保留来平衡：对高风险代理（面向监管、客户出资、合同关键、生产修改）进行完整推理捕获，对内部助理进行轻量捕获。
Which raises the question the architecture diagram doesn’t ask: Who builds and runs this? Security can enforce policy but can’t author it. The people who know what a refund agent should be allowed to do own the refund business, not the firewall. IT can provision identities but can’t draft “good standing” or write the escalation rule. The MCP and A2A protocol communities are doing real work on wire-level identity and delegation. MCP gives you tool-invocation provenance and is the standard Entra Agent ID and most vendor frameworks build on. A2A is converging on cross-agent delegation primitives. Both matter, but neither drafts policy. Standards, not the institution, move the connectors.这就提出了架构图未问的问题：谁来构建和运行它？安全团队可以执行政策，但不能制定政策。了解退款代理应具备哪些权限的人是退款业务部门，而不是防火墙。IT 可以提供身份，但不能起草“信用良好”或编写升级规则。MCP 和 A2A 协议社区正致力于底层身份和委托的工作。MCP 为工具调用提供来源信息，是标准 Entra Agent ID 的基础，大多数供应商框架都基于此。A2A 正在收敛为跨代理委托原语。两者都重要，但都不负责起草政策。是标准在推动连接，而不是机构本身。
What enterprises need is a new function that sits between the business units owning the policies and the platform teams running the runtime. Call it agent operations: small group, often four to eight people in a Global 2000 enterprise, embedded rather than centralized, reporting into the CIO or CISO depending on house politics, with explicit charter to maintain a registry of every production agent, its named human owner, its versioned authority specification, its retention policy for reasoning-grade audit, and its lifecycle state. Each agent gets onboarded with a signed policy, reviewed on a real cadence, and actually retired when its initiative ends, rather than the current default of quietly outliving its sponsors. Designing against failure modes like review cadences that calcify into ceremony, policy artifacts that lag agent deployment velocity, or functions that become the place agents go to die in committee is itself part of the work. The function has to ship at the pace of the platform teams or it will be routed around within a quarter.企业需要的是一个新职能，位于拥有政策的业务单元和运行运行时的平台团队之间。称之为代理运营：在全球 2000 强企业中通常由四到八人组成的“小组”，嵌入而非集中，向 CIO 或 CISO 汇报，具体职责是维护每个生产代理的注册表、其指定的人类所有者、版本化的权威规范、推理级审计的保留策略以及生命周期状态。每个代理在上线时附带签署的政策，按真实节奏审查，并在其计划结束时真正退役，而不是像现在默认的悄然超期。针对审查节奏固化为仪式、政策文档滞后于代理部署速度、或职能沦为代理“死在委员会”的场所等失效模式进行设计，本身就是工作的一部分。该职能必须与平台团队的速度同步，否则将在一个季度内被绕过。
The work is hard. It’s also overdue, and the regulatory clock is running. The EU AI Act’s high-risk provisions are entering enforcement this year, and regulators will ask for explainability, traceability, lifecycle records, and named human accountability. These are exactly the artifacts an agent operations function produces. Tyler Akidau called this the missing HR layer in his April Radar piece; Artur Huk’s more recent “From Capabilities to Responsibilities” converges on similar ground from the runtime side. The label matters less than the work. This piece is about governance inside one organization. The harder problem is governance across organizations, with agents acting under different trust regimes. That’s strictly worse, and worth its own piece.这项工作很艰巨，也早该完成，监管时钟正在滴答。欧盟 AI 法案的高风险条款将在今年进入强制执行，监管机构将要求可解释性、可追溯性、生命周期记录以及指定的人类问责。这正是代理运营职能所产出的文档。Tyler Akidau 在四月的 Radar 文章中称其为缺失的 HR 层；Artur Huk 最近的《从能力到责任》从运行时角度也 converges 于相似的议题。标签不如工作本身重要。本文关注单一组织内部的治理。更难的问题是跨组织的治理，代理在不同信任体系下运行。这更为棘手，值得单独成文。
Within your own four walls, the diagnostic is doable in an afternoon. Pick one production agent. Try to answer, with evidence: Whose authority does it carry, traced from action back to a named human? Where is its authority specified, and who signed the current version? When it does something wrong tomorrow, who pays, how is that decided, and what reasoning-grade record supports the decision? Most architects who do this honestly come away with three blanks and a knot in their stomach. That’s principal drift, named and visible.在你自己的四面墙内，这项诊断可以在一个下午完成。挑选一个生产代理。尝试用证据回答：它携带的权威归属谁，从动作追溯到指定的人类？它的权威在哪里规定，谁签署了当前版本？如果它明天出错，谁负责，如何决定，以及哪份推理级记录支持该决定？大多数诚实尝试的架构师会得到三个空白和一阵胃痛。这就是已命名且可见的主体漂移。
The mesh you’ve built is real and necessary, but it isn’t sufficient. The rest of the architecture is the institution above it: the registry, the signed policies, the reasoning-grade audit, the named human at the end of every chain. In most enterprises it doesn’t yet exist, and it won’t arrive by buying another platform. You’ll have to draft it yourself.你构建的网格是真实且必要的，但并不充分。其余的架构是其之上的机构：注册表、签署的政策、推理级审计、每条链末端的指定人类。在大多数企业中，这些尚未存在，也不会通过再购买平台而出现。你必须自行起草。
