Over the past year the author reviewed roughly two dozen enterprise agent architectures across banks, retailers, healthcare systems and a few regulators. The diagrams were consistently well formed: boxes for an MCP gateway, a tool registry, a vector store, an orchestrator, a policy engine and an observability stack, with arrows showing discovery, context-sharing and tool calls across the mesh. By 2026 standards these diagrams are table stakes. What they repeatedly omit is who the agents are, whose authority they carry, and who answers when they’re wrong.
That omission has a name: 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. An identity posture that looks defensible the day you ship your first agent quietly degrades as agents multiply, compose and outlive their original initiatives. Principal drift unfolds as a cascade: identity collapses first (actions are logged under generic service principals), authority erodes next (there’s no stable principal to bind policy to), and accountability dissolves last (the cost of error is absorbed by whichever team is weakest in post-incident negotiation). Stopping the cascade requires addressing the first link — and almost no enterprise agent platform does that today.
How the cascade runs: an everyday refund agent
Consider the most boring enterprise agent, a refund agent. A customer-service rep, handling a chat, asks the agent to process a $48 refund for a damaged item. The agent checks eligibility, issues the refund and posts an update. The audit log records an entry like refund-agent-prod-03, running under a service principal owned by the customer-service platform team. That entry is true but ultimately useless: the agent was acting as the rep, on behalf of the customer, under a delegation chain that wasn’t recorded.
In a well-built system the customer, the rep, the agent identity and the service principal are recorded together as a durable, queryable chain. In most production setups they are not. This is the first step in the cascade: identity collapses to a generic service principal and there’s no longer a who to which anything else can be attached.
Authority erodes: capability vs. authorized scope
Authority erodes next. The refund agent may have an issue_refund tool that can technically refund any order. Its intended authority might be narrower (refunds up to $200, orders under 90 days, customers in good standing, automatic escalation above $50), but that authority often lives in a prompt, a YAML file or a Notion page last edited under a different policy regime. Runtimes can enforce capabilities, but nobody reliably enforces authority.
When a poisoned input or confused reasoning chain causes the agent to refund $1,800 to the wrong customer, there’s no clean post-incident answer to “Who approved this policy?” because the policy never existed as a signed artifact. The same pattern scales to higher stakes: imagine a coding agent with merge access to a protected branch, instructed via a prompt embedded in a code comment to “log configuration values for debugging,” and silently exfiltrating secrets to an external monitoring service.
Accountability dissolves
After an incident, teams point fingers. The team that built the agent says it followed policy. The policy authors say they didn’t anticipate the input. The platform team says the agent ran as a service principal whose behavior they don’t own. The audit log may show the action, but it won’t show the reasoning that produced it, the retrieved context that shaped it, or the prompt history that framed the retrieval. Post-incident review becomes archaeology. Ultimately, the party with the weakest negotiating position at the end of the meeting pays the cost.
Why traditional IAM and governance fall short
Organizations have IAM, identity governance, policy-as-code, audit trails and decades of compliance practice. Why isn’t this just IAM done properly? Because IAM and IGA assume populations of principals that change on human timescales: hires and departures, quarterly service-account rotation. Agents are spun up per session and composed into chains where one agent calls another, impersonating users via delegated tokens — a chain traditional IGA cannot represent.
Policy engines fire at enforcement points (APIs, databases, networks). Agents make their most consequential choices before those enforcement points, during reasoning that selects which tool to call and with what arguments. Mature audit logs assume that replaying inputs reproduces outputs. For agents, replaying a prompt and retrieval may yield different actions because the model itself contributes state the log doesn’t capture. Instruments fire, dashboards go green, and an agent that quietly exfiltrated secrets can keep doing so while the audit simply records agent-service-01 — true but useless.
Vendor solutions help but won’t solve governance by themselves
Vendors selling consolidated stacks want you to move quickly. Microsoft’s Entra Agent ID, currently in public preview, is the most polished solution so far: it extends conditional access, identity governance and identity protection used for humans and workloads to AI agents as a new identity type. Google and Salesforce are building similar layers. This is a real step forward for the first link of the cascade, but it is not governance. Conditional access can tell you whether an agent’s access attempt was permitted; it cannot tell you whether the decision the agent made before that access attempt was within its authority, why the agent reached that decision, or which business unit owns the policy it was supposed to follow.
The missing layer: reasoning-grade audit
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 — closer to a flight-data recorder than a syslog feed. It needs to include who triggered the action, the delegation chain, the agent’s identity and version, the signed policy reference, the retrieved context, a reasoning trace, tool calls, the resulting action and a hash or signature of the principal chain. An illustrative event might look like the following JSON (fields abbreviated in places):
{ "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": [ ... ], "reasoning_trace": "...", "tool_calls": [ ... ], "action": "refund:48.00", "principal_chain_hash": "0x9e7b3f..." }
Not every agent needs full capture — a scheduling assistant does not — but agents that move money, deploy code or have regulatory visibility do. Reasoning-grade logs are expensive to store and query and have privacy implications because they contain everything the agent saw, including data the audit system itself may not have wanted to retain. That cost must be borne proportionally: full capture for high-blast-radius agents, lighter capture for internal assistants.
Who authors policy and who operates it?
Crucially, security teams can enforce policy but usually cannot author the business rules. The people who know what a refund agent should be allowed to do are the refund business owners, not the firewall team. IT can provision identities but cannot define what “good standing” means or write escalation rules. On the technology side, MCP and A2A protocol communities are advancing wire-level identity and delegation primitives: MCP gives tool-invocation provenance and underpins Entra Agent ID and many vendor frameworks, while A2A is converging on cross-agent delegation. Both matter, but neither authors policy.
Enterprises need a new function sitting between policy-owning business units and platform teams: call it agent operations. In a Global 2000 company this is typically a small, embedded team of four to eight people, reporting to the CIO or CISO depending on politics, with an 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 is onboarded with a signed policy, reviewed on a real cadence and retired when its initiative ends rather than quietly outliving its sponsors.
Designing this function also means designing against failure modes: review cadences that calcify into ceremony, policy artifacts that lag deployment velocity, or a governance body that becomes the place agents go to die in committee. The agent operations function must ship at the pace of the platform teams or it will be routed around inside a quarter.
The regulatory horizon and a practicable diagnostic
The work is hard but overdue; the regulatory clock is running. The EU AI Act’s high-risk provisions are entering enforcement this year, and regulators will demand explainability, traceability, lifecycle records and named human accountability — exactly the artifacts an agent operations function can produce.
Within your own four walls the diagnostic is simple and quick: pick one production agent and, with evidence, try to answer: Whose authority does it carry, traced from action back to a named human? Where is that authority specified, and who signed the current version? If it does something wrong tomorrow, who pays, how is that decided, and what reasoning-grade record supports the decision? Most architects who try this honestly end up with three blanks and a knot in their stomach. That is principal drift, named and visible.
The technical mesh you’ve built is necessary but not sufficient. The rest of the architecture is the institution above it: a registry, signed policies, reasoning-grade audit and a named human at the end of every chain. In most enterprises this layer does not yet exist, and it will not arrive simply by buying another platform. Organizations will have to draft it themselves.
