The Delegation Problem
[No cross-series navigation links for this chapter; placeholder retained per S23]
By 2027, non-human identities will outnumber human identities in enterprise environments by 25 to 50 times. That figure, from the European Identity Conference 2026, is not a projection. It describes the environment many organisations already operate in today.
Every one of those non-human identities holds permissions. Many hold permissions that were set at deployment and have not been reviewed since. A significant proportion hold permissions that extend well beyond what the agent's declared operational purpose requires. When Gartner analyst Shiva Varma warned in May 2026 that 40 per cent of enterprises will demote or decommission autonomous AI agents by 2027 due to governance gaps discovered only after production incidents, the underlying cause of that reckoning is already built into the identity layer. It lives in the scope field of the OAuth token.
This chapter addresses the protocol layer where that problem lives: OAuth 2.1, the authorisation framework that governs what an authenticated agent is permitted to do after it has proven who it is. Chapter 18 established that every agent needs a cryptographically sound identity at the human-to-agent boundary. This chapter asks the question that comes immediately after authentication: what does that identity authorise, and how far can that authorisation be delegated down a chain of agents?
The answer matters because OAuth 2.1, for all its elegance, was not designed for the problem you are now using it to solve.
How OAuth 2.1 Delegation Is Supposed to Work
OAuth 2.1 is the current version of the Open Authorisation framework. It governs how a resource owner, typically a human user, grants a client application access to a protected resource without sharing credentials. The authorisation server issues a token; the token carries a scope; the resource server honours requests within that scope.
The on-behalf-of (OBO) flow extends this model. When a human authorises an agent to act on their behalf, the agent receives a delegated access token. The token carries the scope the human granted: the agent can read these files, send these types of messages, call these APIs. In theory, the human's intent is encoded in the token. In theory, the agent acts within the scope the human approved.
In theory.
Three design assumptions baked into OAuth 2.1 hold for applications and break for agents.
First: the human is present at the authorisation moment. OAuth was designed around a human being who reads an authorisation screen, understands what they are granting, and clicks approve. That moment of informed consent anchors the entire delegation chain. An agentic deployment reverses this. The human often authorises a broad operational scope at deployment time, before the specific actions the agent will take are known. The agent then makes delegation decisions within that broad scope, autonomously, in contexts the human never reviewed.
Second: the scope is meaningful and bounded. OAuth scopes work when they are granular and specific: read:documents, write:calendar, send:messages on behalf of this user. In practice, enterprise integrations accumulate scope over time. An agent granted broad access to a collaboration platform may hold scopes covering hundreds of actions the developer assumed would never be relevant to the agent's declared purpose. The scope is technically valid. The delegation it enables is far wider than anyone intended.
Third: the client is not also a server delegating to other clients. OAuth 2.1 was not designed for the agent-to-agent case. When an orchestrator agent delegates a subtask to a worker agent, the worker needs its own scoped authorisation. The current tooling responses to this problem, OAuth 2.1 combined with emerging standards like Model Context Protocol (MCP) and the agent-to-agent (A2A) protocol, provide building blocks. None was designed natively for the autonomous delegation chains that frontier AI now executes. All are being adapted.
Binary Versus Proportional: The Governance Choice Gartner Is Watching
The Gartner finding identifies two patterns in enterprise responses to the delegation problem. Organisations that discover a governance gap after a production incident typically respond with a binary decision: lock the agent down or leave it operating as before. The architectural cause of the incident goes unaddressed because it was never identified.
Gartner's recommendation is proportional governance: classify agents across autonomy levels, tie reasoning capability to trust boundaries, and design governance calibrated to the specific risk profile of each agent class. Not a single blanket policy applied uniformly to every agent in the environment.
This distinction matters for architects. A binary policy is operationally convenient. You decide: this agent is trusted, or it is not. You do not need to build a classification framework, define autonomy levels, or design tiered trust boundaries. The operational cost is low. The risk is that the binary decision, made at deployment time with incomplete information, is the governance decision that finds you in the incident report.
Proportional governance costs more to design. It requires that every agent in your environment has a declared autonomy level, a defined trust boundary tied to that level, and a delegation scope calibrated to both. The return is an architecture that does not produce the 40 per cent post-incident reckoning.
New Zealand architects should read the Gartner figure alongside what they know about their own environment. The first Mandatory Cyber Security Standards (MCSS) reporting period closed 30 April 2026. Mandated agencies have just completed their initial self-assessment against those standards. What those assessments are likely revealing, consistent with the Gartner finding at the international commercial level, is that agent deployment has outpaced agent governance. The self-assessment confirms the gap exists. Proportional governance architecture is how you close it.
The On-Behalf-Of Problem: Where Human Intent Gets Lost
The technical version of the delegation problem is the OBO flow. In OAuth 2.1, a middle-tier service can request a new token on behalf of the user, delegating the user's authority to a downstream service. The mechanism exists for legitimate multi-tier service architectures. It breaks for agentic deployments in one specific way: the original human's constraints do not propagate through the chain.
When a human authorises an agent to act on their behalf, that authorisation reflects the human's current understanding of what they are approving. The agent then interprets that authorisation within its own reasoning. If the agent delegates to a sub-agent, the sub-agent receives a token derived from the orchestrator's authorisation, not from the human's original intent. By the second delegation hop, the human's specific constraints, the implicit ones that never made it into the token scope because they were assumed rather than stated, are gone.
A concrete example. A user authorises a document management agent to "help with my files." The agent, interpreting this broadly, grants a sub-agent access to read, summarise, and reorganise. The sub-agent, encountering a file that references an external system, initiates an API call to retrieve additional context. Each step is within scope as the agent interprets it. None was what the user had in mind when they said "help with my files."
This is not a failure of OAuth 2.1. It is a failure of the governance architecture surrounding OAuth 2.1. The token was valid. The scope was technically correct. The problem is that no one designed the scope to reflect the human's actual intent boundary, and no one built runtime authorisation checking to catch the drift between initial authorisation and downstream execution.
The Oasis Security and Zscaler integration announced 10 June 2026 represents the commercial product instantiation of the solution to this problem. The combined architecture delivers lifecycle governance for AI agents and machine identities, with inline enforcement across Zscaler's Zero Trust Exchange. Runtime authorisation checking at every action, not only at registration. A single control plane for non-human and agentic identities from discovery to decommissioning. The building blocks remain OAuth 2.1, MCP, and A2A. The design goal is closing the gap between initial authorisation and downstream execution by enforcing authorisation at action time, not session time.
Token Scope Inflation: The Architecture That Creates the Problem
Token scope inflation is the gradual accumulation of permission beyond what the agent's declared purpose requires. It happens for understandable reasons. Developers grant broad scope at deployment to avoid authorisation failures. Integrations accumulate access over time as functionality expands. Long-lived tokens outlast the contexts that justified them.
At enterprise scale, the effect becomes structural. Non-human identities already outnumber human identities by 25 to 50 times in enterprise environments, per European Identity Conference 2026 data. The 82:1 agent-to-human ratio that Chapter 4 documented as a 2027 projection from Deloitte and Salesforce is, for some environments, already the current state. At that scale, scope inflation is not an edge case. Each of those non-human identities holds permissions. Many hold permissions that have never been reviewed since initial deployment.
NZISM v3.9 Section 16.7 governs access review and audit. The requirement exists: authenticated identities must be reviewed, access audited. The gap is that Section 16.7 was written for human access review cycles. An agent pipeline executing thousands of API calls per day is not a candidate for the access review process designed for quarterly human role review. The review cadence, tooling, and scope definition must all be rethought for the non-human identity population.
The NCSC-NZ frontier-AI advisory requires explicit executive accountability for frontier-AI cyber risk. Executive accountability for an agent's actions requires, at minimum, that someone can answer: what is this agent authorised to do? That question cannot be answered reliably if scope has inflated beyond the original intent, if long-lived tokens carry permissions granted for a context that no longer applies, or if delegation chains have extended the original authorisation into territory the human approver never reviewed.
Implementation Pattern: Constrained Delegation for Agent OAuth Clients
The following configuration implements constrained delegation for an agent OAuth client. It enforces scope boundaries at token issuance, requires runtime authorisation checking, and produces the audit trail that Section 16.7 of NZISM v3.9 requires.
# Constrained Agent OAuth 2.1 Configuration# Reference: NZISM v3.9 Sections 16.1 (authentication) and 16.7 (access review)# Deployment: Entra ID / Okta Workforce Identity or equivalent OIDC-compliant IDP# Compatible with SPIFFE SVID integration (see Chapter 17)agent_oauth_client:client_id: "agent-docmgmt-prod-001"client_type: "confidential"grant_types:- "client_credentials" # Agent acting on its own behalf- "urn:ietf:params:oauth:grant-type:jwt-bearer" # On-behalf-of (OBO) flow# Scope constraints: explicit allowlist; no wildcard scopesallowed_scopes:- "documents.read"- "documents.summarise"# NOT granted: documents.write, documents.share, documents.delete# NOT granted: communications.send, calendar.modify, access.manage# Token lifetime constraintstoken_lifetime:standard_operations:access_token_ttl_seconds: 900 # 15 minutes; short-lived by designrefresh_token_enabled: false # Agents must re-authorise; no silent refreshhigh_consequence_operations:access_token_ttl_seconds: 0 # Zero: fresh authorisation required per actionre_authorisation_required: true # Human re-authentication gate per Chapter 18# Delegation constraints: what this agent may delegate to sub-agentsdelegation:sub_agent_delegation_permitted: truemax_delegation_depth: 1 # One-hop only; Chapter 20 addresses multi-hopdelegatable_scopes:- "documents.read" # Sub-agents may inherit read scope only# NOT delegatable: documents.summarise (agent capability, not re-grantable)scope_reduction_required: true # Sub-agent token must have FEWER scopes, not sameparent_agent_id_propagation: true # Sub-agent token carries parent SPIFFE SVID# Runtime authorisation checking (action-level, not session-level)runtime_enforcement:policy_engine: "open_policy_agent"check_on_every_action: true # Not only at session startpolicy_bundle: "agent-docmgmt-policy-v2"# Audit requirements: NZISM v3.9 Section 16.7audit:log_token_issuance: truelog_scope_at_issuance: truelog_delegation_depth: truelog_parent_authorisation_id: true # Links to FIDO2 session ID from Chapter 18log_runtime_check_outcome: true # Every allow/deny at action leveltamper_evident: trueretention_days: 2555 # Seven years: standard NZ records retention# Scope restriction policy (OPA bundle excerpt)# Enforced at runtime; not at token issuance aloneagent_scope_policy:version: "2"rules:- id: "no_external_communication"description: "Document management agent must not initiate external API calls"condition:action.target_domain_external: trueeffect: "deny"log_level: "alert"- id: "no_write_on_read_token"description: "Read-scoped token may not be used for write operations"condition:token.scopes_includes: "documents.read"action.type: "write"effect: "deny"log_level: "alert"- id: "delegation_depth_enforcement"description: "Enforce maximum one-hop delegation"condition:token.delegation_depth_gte: 2effect: "deny"log_level: "alert"Several design decisions in this configuration warrant explanation.
Scope reduction is mandatory on delegation. The rule that a sub-agent token must carry fewer scopes than the parent is not optional. If the sub-agent token could carry identical scope, there would be no meaningful constraint on the delegation. Every hop would recreate the original authorisation, and the chain would have no boundary.
Runtime checking operates on every action, not on session establishment. A session-level authorisation check confirms that the agent had legitimate access when the session started. It does not confirm that the specific action the agent is about to take, in its current execution context, is within the bounds of what was originally authorised. Action-level checking is more expensive. It is also the only check that catches the on-behalf-of drift described above.
The delegation depth ceiling of one hop is deliberate. This configuration is designed for a single-tier agent deployment. The multi-hop chain is the subject of Chapter 20. The single-hop ceiling keeps this pattern clean and auditable.
The parent authorisation ID link to Chapter 18. The audit trail for this configuration carries the FIDO2 session ID from the human's original authentication event, per the session correlation pattern established in Chapter 18. Any action in the chain can be linked back to the authenticated human who initiated it.
What NZISM v3.9 Requires and Where the Gap Is
NZISM v3.9 Section 16.1 governs authentication controls. Section 16.7 governs access review and audit. Both sections apply to agent deployments; neither was written with agentic delegation chains as the primary use case.
Section 16.7's access review requirement is the most directly applicable. Review of what authenticated identities are authorised to access must occur. For a human identity, this is a role review: does this person still need access to this system? For an agent identity, the analogous review must include: does this agent still need the scope it was granted? Has that scope drifted through token reuse or implicit inheritance? Does the delegation depth its tokens permit still reflect the agent's current operational context?
None of these questions are outside what Section 16.7 intends. They are, however, outside what any access review tooling built for human identity will answer automatically. NZ architects deploying agents in NZISM-compliant environments need to extend the access review process to cover the agent identity population, using the audit trail the configuration above generates.
The NZ Government Digital Identity Standards, referenced in NZISM v3.9's Chapter 16 updates, provide the framework for identity governance in government settings. The delegation question is an extension of that framework to the non-human identity population. Architects in government settings should apply the standards as the baseline and extend upward to cover the agent delegation layer.
The Five Country Council's "Careful Adoption of Agentic AI Services" guidance, published 1 May 2026 with NCSC-NZ as a named co-author, identifies accountability as a primary governance concern for agentic deployments. The delegation problem sits at the technical layer under that accountability requirement.
The Vendor-Decides Pattern: What Happens When You Do Not Make a Decision
The Gartner binary-versus-proportional observation points to a pattern that deserves a name. When an organisation deploys agents without making an explicit delegation governance decision, a governance decision is still made. The vendor makes it.
The agent deployment package has defaults. Default token lifetimes. Default scope configurations. Default delegation permissions. An organisation that accepts those defaults without review has not avoided making a governance decision. It has made the governance decision the vendor's engineers made, in a context that was not your environment, for a user they were not thinking about.
This is the Vendor-Decides Pattern: the enterprise governance framework that emerges from accumulated vendor defaults rather than deliberate architectural choice. It is not malicious. It is a structural consequence of deploying before governing.
Gravitee's 2026 research found that roughly 47 per cent of deployed AI agents are not actively monitored. The inverse of that figure, slightly more than half of all deployed agents, are operating under governance defaults the deploying organisation has not reviewed. In that environment, the Gartner post-incident reckoning is not a future risk. It is the current operating state for a significant portion of the agent population.
The architectural response is not to audit every vendor default and replace every decision with a custom configuration. That is not achievable at scale. The response is to identify the delegation decisions that carry material risk, make those decisions explicitly, and design the governance architecture, including the Open Policy Agent (OPA) policy bundle above, to enforce those explicit decisions. Let the vendor decide the defaults where the risk is low. Override the vendor where the risk is material.
Connecting the Identity Architecture Stack
Part Four of this book builds the identity architecture stack for the agentic enterprise layer by layer.
Chapter 16 diagnosed the non-human identity crisis: 82:1 ratio, ungoverned credentials, no systematic inventory.
Chapter 17 provided the workload identity infrastructure: SPIFFE (Secure Production Identity Framework for Everyone) and SPIRE (the SPIFFE Runtime Environment), short-lived cryptographically verifiable SVIDs (SPIFFE Verifiable Identity Documents), automated rotation.
Chapter 18 addressed the human-side anchor: FIDO2 (Fast Identity Online 2) at the human-to-agent boundary, phishing-resistant authentication, session correlation identifiers that propagate through the audit trail.
This chapter addresses the authorisation layer: what the authenticated identity with its verified workload credential is permitted to do, with what scope, for how long, and how far it can delegate that authority.
Chapter 20, next in this series, addresses the multi-hop chain: when authenticated, scoped agents delegate to other authenticated, scoped agents, how does the governance architecture maintain coherence across the full execution arc? The single-hop ceiling in the configuration above is a deliberate boundary; Chapter 20 removes it for environments that require multi-tier delegation, and specifies the additional governance controls that removal requires.
The stack is not complete until Chapter 20. Do not treat the configuration above as the finished architecture for a multi-agent deployment. Treat it as the single-hop baseline that Chapter 20 extends.
Zero trust architecture originated in defence intelligence networks: the Kindervag synthesis at Forrester drew directly from NSA and Department of Defense (DoD) network segmentation practice, where assuming any interior traffic could be trusted had already proven catastrophic. The delegation problem, in that lineage, is not new. What is new is that OAuth 2.1 and agentic AI have brought the same challenge into civilian enterprise at a scale civilian governance frameworks were not designed to absorb. For deployments that touch International Traffic in Arms Regulations (ITAR) or Export Administration Regulations (EAR) territory, the scope-boundary question becomes a compliance requirement: the delegation chain must not carry classification-controlled material beyond the authorised boundary, and the explicit allowlist, scope reduction at delegation, and action-level OPA enforcement this chapter describes are the technical apparatus for enforcing that boundary.
Four Actions for NZ Architects This Month
The MCSS first reporting period has closed. The frontier-AI advisory has issued. The Gartner finding is in the public record. The gap between agentic deployment and agentic governance is no longer a theoretical concern. It is a measured condition with a named consequence.
Four actions are within reach for NZ architects this month.
Enumerate your agent OAuth clients. Every agent operating in your environment under an OAuth client credential has a client ID, a scope, and a token lifetime. Many of those clients have not been reviewed since initial deployment. Start with the list. Without the inventory, every subsequent governance action operates on incomplete information.
Review scope against declared purpose. For each agent client ID in your inventory, compare the scopes held against the agent's declared operational purpose. Any scope the agent holds that is not required for its declared purpose is a candidate for removal. Prioritise agents with write access, external communication permissions, and access to personal information.
Set a delegation depth ceiling. If your agent deployment uses any form of OBO delegation, define the maximum depth explicitly. One hop is a defensible starting point for most production deployments. Document the decision. The documentation is the governance artefact that demonstrates the delegation decision was made actively, not by default.
Add action-level runtime checking to your highest-risk agent pipelines. Session-level authorisation is necessary. It is not sufficient. For agents with write access, financial transaction authority, or access to personal information under Information Privacy Principle 3A (effective 1 May 2026), action-level OPA policy enforcement is the control that prevents the drift the YAML above is designed to catch.
None of these actions requires purchasing a new product. All of them require architectural decision-making that the Vendor-Decides Pattern has been making by default.
What Are the Hardest Delegation Decisions in Your Environment?
When you think about the AI agents operating in your organisation right now: do you know what each one is authorised to do? Not what you intended when you deployed it. What the token actually permits.
The views expressed in this article are entirely my own, informed by more than 30 years of professional experience in architecture, security, and technology leadership in New Zealand. They do not represent the views of my employer, any government agency, or the New Zealand government. My commentary on legislation and policy is analytical, drawing on publicly available sources and my professional expertise in architecture, security, and AI governance. I follow the Public Service Commissioner's Code of Conduct for the Public Sector and social media guidance.
Andreas Hamberger is a New Zealand leader in Architecture and Security and Associate Member of the Institute of Directors. Zero Trust Architecture for the Agentic Enterprise is the first book in The Hamberger Report series, providing practitioners with deployable patterns and configurations for securing AI-driven systems.
I use AI tools, including Sudowrite, Claude, Perplexity AI, DeepSeek AI, ChatGPT, Grok, Copilot, Openart and Gemini, as deliberate production tools, not ghostwriters. This is consistent with my position: AI amplifies human judgement; it does not replace it. The frameworks, arguments, and editorial decisions in this series are original work. AI accelerated the process. The thinking is mine.
[1] Gartner. "Gartner Says Applying Uniform Governance Across AI Agents Will Lead to Enterprise AI Agent Failure." Shiva Varma, Senior Director Analyst. 26 May 2026. https://www.gartner.com/en/newsroom/press-releases/2026-05-26-gartner-says-applying-uniform-governance-across-ai-agents-will-lead-to-enterprise-ai-agent-failure
[2] Oasis Security. "Oasis Security Announces Integration with Zscaler to Extend Zero Trust to Non-Human and Agentic Identities." 10 June 2026. https://www.prnewswire.com/news-releases/oasis-security-announces-integration-with-zscaler-to-extend-zero-trust-to-non-human-and-agentic-identities-302796207.html
[3] European Identity Conference (EIC) 2026. Non-human-to-human identity ratio in enterprise environments. 2026. (Conference proceedings; specific session data referenced via researcher package Entry 137.)
[4] Deloitte / Salesforce. "Agentic AI Survey 2025." 82:1 agent-to-human ratio projection by 2027. 2025. deloitte.com. (Established reference; introduced Chapter 4.)
[5] NCSC-NZ. "The Implications of Frontier AI Models for Cyber Defence." National Cyber Security Centre, New Zealand. 2026. https://www.ncsc.govt.nz/protect-your-organisation/the-implications-of-frontier-ai-models-for-cyber-defence/
[6] NCSC-NZ. "New Zealand Information Security Manual (NZISM) v3.9." Sections 16.1 and 16.7. National Cyber Security Centre, New Zealand. nzism.gcsb.govt.nz
[7] CISA, NCSC-UK, NCSC-NZ, ASD, CSE. "Careful Adoption of Agentic AI Services." 1 May 2026. cisa.gov. (Five Country Council joint advisory; NCSC-NZ named co-author.)
[8] Department of Internal Affairs. "NZ Government Digital Identity Standards." dia.govt.nz. Referenced in NZISM v3.9 Chapter 16 updates.
[9] Gravitee. "State of AI Agent Security 2026." 47% of deployed AI agents not actively monitored. 2026. (Supporting data; introduced as supporting stat in Chapter 4.)
[10] IETF / OAuth Working Group. "The OAuth 2.1 Authorization Framework." oauth.net. (Protocol specification; widely documented standard.)
[11] Privacy Act 2020 (as amended by Privacy Amendment Act 2025). Information Privacy Principle 3A. Effective 1 May 2026. legislation.govt.nz