Enterprise Architecture Has Identity Governance. It Doesn't Have Delegation Governance.

Delegation governance is the layer identity management doesn't cover: identity governs identities and entitlements, but it doesn't, by itself, represent the full relationship created when authority is transferred from one principal to another. Enterprise architecture has built real depth on the first. It has built far less on the second. Rack2Cloud's own authority-architecture work has already established that identity and authority are different governance problems. Framework #141 defined the authority boundary a delegated agentic system operates inside; subsequent work extended that boundary into platform authority, into a shipped MCP gateway, into the evidence a delegated action leaves behind. The remaining question is what happens when authority itself is delegated between principals - a question that predates agents by decades and gets harder to ignore the moment the delegate stops being human. The Authority Thread Already Exists Identity governance and authority governance are not new distinctions on this site. Framework #141, Agentic Authority Boundary (https://www.rack2cloud.com/mcp-security-architecture/), named the formal boundary within which an agentic system may delegate execution authority - constrained by explicit scope, identity, ownership, and revocability - and named four ways that boundary collapses: scope creep, implicit trust inheritance, non-revocable grants, and authority chain opacity. Every AI Platform Is Becoming An Authority Platform (https://www.rack2cloud.com/ai-platform-authority-layer/) showed three architecturally distinct vendors converging on the same requirement, independently, in the same year. Nutanix Put MCP Behind a Gateway. The Real Problem Is Authority. (https://www.rack2cloud.com/nutanix-mcp-gateway-authority/) tested a shipped gateway against that boundary directly and drew the line explicitly: identity governance and authority governance are different problems, and a gateway that answers the first doesn't automatically answer the second. This piece isn't rediscovering that split. It's asking the delegation governance question the thread hasn't answered yet - not whether authority is different from identity, but what happens when authority itself is a relationship, transferred from one principal to another, rather than a property one principal simply holds. Enterprise AI infrastructure architecture (https://www.rack2cloud.com/ai-infrastructure-strategy-guide/) has built real depth on what happens after that transfer breaks down. It has spent far less time making the transfer itself an explicit governance object - before anything breaks. That question predates agents entirely. Organizations have always delegated authority - through assistants, administrators, service accounts, approval chains, workflow systems. What changed with autonomous systems isn't the existence of delegation. It's the frequency, duration, depth, and observability of it. Delegation Predates Agents In April 2015, NeighborWorks America's Internal Audit Department published a review of the organization's delegation of authority policy - a formal chain running from the Board, to the CEO by resolution, to individual officers through signed "Redelegation of Obligation and Disbursement Authority" memos filed with the Office of General Counsel as the system of record. It is about as far from an AI governance story as an audit report gets, which is exactly what makes it useful. Auditors sampled twenty-five disbursements and found one where a Senior Vice President had approved a program disbursement without a required additional layer of sign-off. Nothing about the SVP's identity was in question - she held a properly filed, board-traceable delegation of authority, the same delegation that authorized dozens of other actions that audit sampled cleanly. The initial grant behind the disbursement had been correctly approved through the normal chain; the specific disbursement was contractually tied to deliverables being met, and the policy treated that as a distinct approval boundary from the grant approval itself. Internal Audit's own language is precise about what kind of failure this was: not a compliance violation, but "a lack of concise articulation of the delegated authority scope." A separate finding in the same review illustrates a related but different problem. A revised, broader delegation for that SVP had in fact been drafted and signed by the prior CEO - but during a 2014 leadership transition, it was never filed with the record-keeper, so the official Obligation of Funds Chart never reflected it. That's not the same finding as the scope-articulation gap above. It's a record-state divergence: evidence that even a delegation's own paper trail can drift out of sync with what was actually granted. Nothing about this case involves a model, an agent, or a line of code. It's a human governance system - identities, roles, an approval matrix, a filing process - in which twenty-four of twenty-five sampled disbursements did not present this particular issue, while the remaining sample exposed the boundary between an officer's general standing authority and the narrower authority a particular action required. That's the architectural takeaway this case earns: identity established who could act. Standing authority established what they were generally entitled to do. Somewhere between that standing authority and the specific action taken, the boundary wasn't clearly enough articulated for the process built to catch it. That was a human governance problem, running through a formal organizational process, caught by an audit sample large enough to find it. Autonomous systems don't introduce that problem. They change the economics of delegation governance entirely. What Changed When the Delegate Became Autonomous The human delegation model had organizational processes, records, approvals, and people capable of interpreting them. Autonomous systems change the execution model: authority can be exercised continuously, programmatically, and across downstream systems without a human evaluating every individual action. An autonomous agent receives delegated authority, executes continuously, invokes other systems, and can create further downstream delegations of its own - without a human necessarily present for any single step. The volume changes. The speed changes. The visibility into any one delegation event changes, because there are suddenly far more of them, happening far faster, than any human review process was built to sample. Reuters' investigation into Meta's "Project OT" restructuring, published August 26, 2026, is a documented instance of that shift. Meta had explored shifting much of the day-to-day work of some teams - as much as 60% of headcount in certain areas - onto autonomous AI agents, with small human teams supervising. According to internal posts reviewed by Reuters, AI-generated code changes to internal platforms and infrastructure rose 220% year-over-year, while changes that reached users rose only 36%. Major technical and security incidents - service disruptions and possible data leaks among them - rose 40% over the same period, and the time staff spent firefighting them rose 70%. One internal post described unchecked agents performing "large-scale, disruptive actions." Those are the documented facts. The Meta evidence demonstrates the scaling problem, not a delegation-governance diagnosis. It shows what happens when autonomous systems take on substantially more operational work while the human organization responsible for supervising them has to absorb a much larger volume of machine-generated activity. The delegation governance question is what representation and controls are required when that activity occurs under transferred authority. The Existing Authority Model Already Covers Most of the Object Before naming what's missing, it's worth being explicit about how much of a delegation governance object Rack2Cloud's existing authority work has already assembled - because the honest framing of this piece is synthesis, not discovery. | Governance element | Where it comes from | Role in this article | |---|---|---| | Authority | Framework #141, Agentic Authority Boundary | Inherited | | Purpose | AI Platform Is Becoming An Authority Platform - intent and mission binding | Inherited | | Scope | Framework #141's Scope Creep Delegation failure state | Inherited | | Revocation | AI Authorization Trail - the missing third step of grant, use, revoke | Inherited | | Lineage | AI Authorization Trail - authority provenance | Inherited | | Evidence | AI Authorization Trail - artifact portability, execution records | Inherited | | Principal | This article | New distinction | | Delegate | This article | New distinction | | Duration | This article | New governance field | Six of nine fields already exist somewhere in Rack2Cloud's Governance & Runtime Control (https://www.rack2cloud.com/ai-architecture-learning-path/governance-runtime-control/) territory, named and argued in enough detail that this piece doesn't need to redefine any of them - only cite them, and extend the model backward into the organizational delegation that predates agentic systems entirely. What's left is the delegation relationship itself. The Remaining Delegation Fields | Field | What it represents | Status | |---|---|---| | Principal | Who originated the authority | Explicit distinction introduced here | | Delegate | Who received and currently exercises that authority | Explicit distinction introduced here | | Duration | How long the transfer remains valid | Explicit lifecycle field introduced here | Principal and Delegate are not two new governance frameworks. They are the two roles required to represent one delegation relationship. Duration adds the missing lifecycle dimension. The reason Principal and Delegate can't simply collapse into "identity" is the important architectural point: an identity can be a principal in one delegation and a