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

Rack2Cloud's authority-architecture work argues that delegation governance is a distinct layer that identity management does not cover, since identity governs entitlements but not the full relationship created when authority transfers between principals. Building on Framework #141's agentic authority boundary and a shipped MCP gateway test, the project contends that autonomous systems change the frequency, duration, depth, and observability of delegation rather than its existence. A 2015 NeighborWorks America audit of a board-to-officer delegation chain is cited to show the problem predates AI agents.

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. Identity governance and authority governance are not new distinctions on this site. Framework 141, Agentic Authority Boundary https://www.rack2cloud.com/mcp-security-architecture/ 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/ 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/ 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/ 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. 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. 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. 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/ 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. | 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 delegate in another, sometimes in the same afternoon. The NeighborWorks SVP was a delegate of the CEO for one class of action and, within her own division, a principal delegating narrower authority downstream. A model-context server is a delegate of the orchestrator that invoked it and, the moment it calls a second tool, becomes a principal delegating further. Identity governance asks whether the identity is valid. It has no native way to ask which role that identity is playing in this specific transfer, right now. This isn't a claim that technical systems can't represent delegation. RFC 8693, OAuth 2.0 Token Exchange https://datatracker.ietf.org/doc/html/rfc8693 https://datatracker.ietf.org/doc/html/rfc8693 , explicitly defines an act claim for identifying an actor to whom authority has been delegated — the protocol layer already has a way to carry that information. The gap is one layer up: representing the delegation relationship consistently enough to govern its origin, scope, lifecycle, revocation, and evidence across the systems that consume it, not merely encode it in a token. That gives this thread three distinct layers, not two — an identity/entitlement layer asking who the actor is and what it can access; a protocol layer asking how a system technically represents delegated authority once it's granted; and a governance layer asking who originated the authority, who received it, what was transferred, under what purpose and scope, for how long, and whether the organization can reconstruct and revoke it. RFC 8693 answers the middle layer. This article is about the third. Duration is the newer claim among the three fields, and it needs careful framing, because Framework 169, Authority Persistence Boundary https://www.rack2cloud.com/third-party-cloud-access/ https://www.rack2cloud.com/third-party-cloud-access/ , has already documented its consequence extensively — across at least seven live posts on this site, from a vendor's authority surviving its own breach to a former employee's access outliving their departure. 169 shows what happens when authority survives beyond the relationship that originally justified it: it keeps working, because nothing about the relationship ending automatically revoked it. What 169 has not previously elevated is explicit validity duration as a first-class design field. This article does: an explicit, bounded validity period, specified as a property of the delegation itself at the moment it is created — not inferred after the fact from whatever else happened to change. 169 is the downstream failure mode. Duration is the upstream field this thread has repeatedly shown the consequences of leaving implicit. An entitlement says: Principal X has permission Y. That's the sentence identity governance is built to evaluate, and it evaluates it well — RBAC, access reviews, and entitlement inventories all exist to keep that sentence accurate over time. A delegation says something structurally richer: Principal X transferred authority Y to Delegate Z, for purpose P, within scope S, under constraints C, for duration D. A conventional entitlement view does not, by itself, provide a complete representation of those six relationships — not because the underlying technology can't carry that information, but because an entitlement view collapses several of them into the actor's role by default. | Question | Entitlement view | Delegation view | |---|---|---| | Who may act? | Primary | Primary | | What may they access? | Primary | Primary | | Who originated the authority? | Often implicit | Explicit | | Who received it? | Often collapses into the actor | Explicit | | What purpose governs the transfer? | May be contextual | Explicit | | How long does the transfer remain valid? | May be inherited or implicit | Explicit | This is not a claim that enterprises have never governed delegation, or that authorization technology can't represent it. NeighborWorks governed it — through a signed memo, a filed record, and a chart that got checked against twenty-five sampled disbursements. OAuth Token Exchange can carry an act claim naming the delegate. What's been missing isn't the capability to represent delegation. It's treating delegation as an explicit, reconstructable governance object with its own fields by default, rather than something inferred from role membership, approval-chain custom, and institutional memory that happens to work until an audit sample, or an agent running at machine speed, finds the case it doesn't cover. Assessment: AI Governance Assessment — Running agentic workloads against production infrastructure? Rack2Cloud's AI Governance Assessment maps delegation, scope, and revocability gaps before they show up as an incident. https://www.rack2cloud.com/audits/ai-governance-assessment/ https://www.rack2cloud.com/audits/ai-governance-assessment/ The governance problem an entitlement model misses doesn't scale with the number of identities in the organization. It scales with the number of authority relationships between principals, delegates, services, and downstream delegations — not simply with the number of identities. A human organization absorbed this informally because the number of active delegations at any moment was small enough for institutional memory, a filed memo, and an occasional audit sample to catch the cases that slipped. That absorption mechanism doesn't scale to an environment where a single orchestrator can spawn delegations to a dozen tools in the time it takes a human approver to open an email. As autonomous actors create more downstream interactions, the number of relationships an organization must be able to reconstruct can increase independently of its identity inventory. That gap is where scope creep, opaque chains, and unbounded grants stop being edge cases and start being the default outcome of treating delegation governance as implicit instead of tracking Principal, Delegate, and Duration as explicit fields. Delegation governance does not replace identity governance, and it doesn't compete with the authority controls this site has already built. It makes explicit the relationship those controls increasingly have to represent: who originated authority, who received it, what was transferred, and how long that transfer remains valid. The NeighborWorks case shows that gap existed before any of this was agentic — a formal human delegation system still exposed a boundary between standing authority and the specific action it covered, and needed a twenty-five-sample audit to catch it. Meta's numbers show what happens to the same category of governance problem once the volume and speed of delegated action outrun what a human supervisory process can absorb. Neither case is about AI risk specifically. Both are about representing a delegation relationship that identity governance was never built to carry. The next governance problem infrastructure architecture has to solve isn't determining whether an actor has a valid identity. It's reconstructing the authority relationship that let that actor act in the first place — and building the governance model that represents it before the next incident does that reconstruction for you. Originally published at rack2cloud.com https://www.rack2cloud.com/delegation-governance/