The Non-Human Identity Crisis: Why Your Zero Trust Architecture Has a Blind Spot
← Chapter 15: When Insurers Become the Regulator | Chapter 17: SPIFFE and the SPIRE Runtime Environment →
Your organisation closed its first Minimum Cyber Security Standards Level 2 reporting window on 30 April 2026. You documented your digital assets. You demonstrated automated identity and access management governance. You evidenced configuration-as-code and continuous drift monitoring across your estate. Good. Now: did your report include your AI agents?
For most New Zealand organisations, it did not. Not because the MCSS requires exclusion. Not because the NCSC made a deliberate policy choice to leave agents out of scope. The gap is structural. The Minimum Cyber Security Standards were written when "digital assets" meant servers, databases, applications, and the human users who accessed them. Non-human agent identity was not a standard discipline when Level 2 was specified. So when your team built the IAM governance model that passed the 30 April assessment, it almost certainly described a human-centric architecture applied to a mixed environment. The agents remained ungoverned, and the audit passed anyway.
That gap is now architecturally visible. Three independent authorities, approaching the problem from different directions, all published in the same four-week window in April and May 2026. Understanding why they converge is the starting point for building the architecture that closes the gap.
The Scale Nobody Measured
Start with the numbers. In the typical enterprise today, non-human identities outnumber human identities by at least 50 to 1. That baseline figure, established across enterprise deployments, was already a governance problem when it was first quantified. By 2026, multi-vendor intelligence from Trend Micro and Astrix Security puts the ratio at 144 to 1 in complex enterprise environments. The gap between what your directory service knows about and what is actually operating in your environment has never been wider.
What counts as a non-human identity? Service accounts created for application integrations. API tokens issued to automation pipelines. OAuth credentials associated with CI/CD workflows. Robotic process automation agents. And now, AI agents. Each of these has credentials, scope, and the ability to act. Many were provisioned without lifecycle governance. Some were created by developers who have since left. A significant proportion carry no expiry date on their credentials. Most have never been through an access review. They accumulate silently, and each one represents a blast radius if compromised.
The economics of NHI compromise differ from human identity compromise in one specific way. When an attacker gains a human credential, they inherit that person's access. When they gain an agent credential, they inherit the agent's scope: the full set of everything the agent was authorised to do, across every system it could reach. If the agent can read production data, so can the attacker. If the agent can execute infrastructure changes, so can the attacker. The blast radius scales not with the attacker's sophistication, but with the agent's provisioned permissions.
According to the Layer3 NZ Threat Landscape 2026 report, unauthorised access represented the largest single share of direct financial loss in New Zealand during the second quarter of 2025, at NZ$3.7 million for that quarter alone. That figure was compiled when AI agent identity was an emerging, rather than an established, attack surface. The trend has one direction.
Why Traditional IAM Fails at Agent Scale
Human identity management works well because its design assumptions match the environment it governs. You know how many employees you have. Joiner-mover-leaver processes handle provisioning and deprovisioning with reasonable reliability. Multi-factor authentication protects privileged access. Annual certification reviews catch stale permissions. The governance cadence is manageable because the identity count is bounded.
Non-human identity management inherits none of those assumptions. The table below maps seven structural failures.
Table 1: Traditional IAM Limitations for Non-Human Identity Management
| IAM Assumption | Human Identity Model | NHI Reality |
|---|---|---|
| Identity creation | Governed by HR joiner process | Created at deployment time, often without governance or register entry |
| Credential lifecycle | Tied to employment tenure | Frequently indefinite; no expiry enforced by default |
| Authentication method | Human-verifiable: MFA, biometrics, passkeys | Machine-readable token or API key; cannot present a second factor |
| Access review cadence | Annual certification cycle | No review cycle specified; sprawl accumulates between cycles |
| Deprovisioning trigger | Employment end or role change | Agent retirement or pipeline decommission; easily missed |
| Scope precision | Least privilege applied at provisioning | Over-provisioned at creation; scope creep has no joiner-mover-leaver analogue |
| Behavioural baseline | Defined by user activity patterns; UEBA detects deviations | No baseline established; anomaly detection has no reference point |
The seventh failure is the most consequential. User and Entity Behaviour Analytics can detect a compromised human account because it has a prior pattern to deviate from. An AI agent acting outside its intended scope looks identical, from a telemetry perspective, to an AI agent operating normally, unless you have defined and instrumented what "normal" means for that agent's action sequence. Most organisations have not.
This is not an indictment of the NCSC. The MCSS Level 2 requirements were specified for the environment that existed in 2025. The NZISM v3.9 access controls in Chapter 16 of that document (Sections 16.1, 16.6, and 16.7) were written for human authentication mechanisms. The NCSC has the NZISM v3.9 Chapter 16 update on its published roadmap. That update, when it arrives, will need to address NHI as an extension of existing access control architecture. This chapter lands before that update. Consider it the practitioner's working hypothesis for what the update will need to say.
Three Convergent Events
The architectural gap was visible before April 2026. What changed in the final week of April was that three independent authorities each published material that pointed, from a different direction, at the same problem. The convergence is not coincidental. It is the point where an emerging discipline becomes an operational requirement.
Microsoft's Zero Trust for AI reference architecture (RSAC 2026, April 2026) is the most complete operational blueprint yet published for applying Zero Trust principles to agentic systems. Microsoft announced at RSAC that this architecture, along with the Microsoft Entra Agent ID capability and the Agent 365 control plane (generally available from 1 May 2026), represents their operational answer to the NHI governance problem. The architecture extends Zero Trust's three foundational principles to agents: verify explicitly by continuously evaluating the identity and behaviour of AI agents; apply least privilege by restricting access to models, prompts, plugins, and data sources to only what is needed; and assume breach by designing AI systems to be resilient to prompt injection, data poisoning, and lateral movement. The Entra Agent ID capability gives each agent a distinct identity in Microsoft Entra ID, enabling governance, conditional access, and lifecycle controls at the agent level rather than the session level.
This matters architecturally. An agent that authenticates using its owner's OAuth session operates with borrowed trust. An agent with its own Entra Agent ID operates with verified, scoped, revocable identity. The difference matters when the agent is compromised, because the revocation path is clear. It matters when the agent is audited, because the action log is attributable to a specific identity, not to a session in which a human user also participated.
The US joint guidance on Zero Trust for Operational Technology ("Adapting Zero Trust Principles to Operational Technology," published 29 April 2026) was produced jointly by CISA, the Department of War, the Department of Energy, the Federal Bureau of Investigation, and the Department of State. It is the first government-produced document to address the IT/OT convergence challenge through a Zero Trust lens, and it is directly relevant to New Zealand's critical infrastructure operators, whose obligations are under active consideration in the DPMC's consultation framework. The guidance states plainly that applying IT-focused Zero Trust capabilities to OT environments wholesale 'is neither reasonable nor feasible.' That is a candid acknowledgement of structural failure, not a technical limitation. The structural diagnosis is the part that transfers to NHI governance, and the section below addresses it directly.
The NCSC MCSS first reporting period (closed 30 April 2026) is the NZ-domestic anchor. Level 2 compliance now requires automated identity and access management governance, business-owner and risk-classification metadata on all digital assets, configuration-as-code, and continuous drift monitoring. These are the right requirements. The gap is that "digital assets" in the Level 2 framework was not specified to include AI agents as a governed asset class. An agency that completed its Level 2 report with full human-identity IAM governance but no agent registry, no agent-level permission enforcement, and no agent behavioural baseline has satisfied the letter of the current Level 2 requirement while leaving its agent population architecturally ungoverned.
The next reporting cycle is the opportunity to close that gap proactively, before NCSC publishes updated guidance that makes it mandatory.
The Seven-Component Architecture
The Microsoft Zero Trust for AI reference architecture, published at RSAC 2026, provides the most actionable operational blueprint currently available. The architecture synthesises Microsoft's published guidance across its Security Blog and Entra Blog into a coherent set of components. For NZ practitioners building the NHI layer of their Zero Trust architecture, these seven components are the starting point.
1. Unique agent identity. Each AI agent holds a distinct, non-shareable cryptographic identity. SPIFFE/SVID (addressed in Chapter 17) is the interoperable implementation for cross-environment workloads; Microsoft Entra Agent ID is the cloud-native path for Azure-based environments. The principle is consistent: no two agents share credentials, and no agent operates under a human user's identity.
2. Agentic asset register. A catalogued inventory of every deployed AI agent: its role, its permitted action scope, its current operational status, its data classification, and its business owner. Chapter 13 introduced the agentic asset register as the NHI governance foundation. This chapter extends that register with the identity fields the access control layer requires.
3. Cryptographic action signing. Every agent action carries a verifiable cryptographic provenance chain. The difference between an audit log that says "agent X was authenticated at 14:32" and one that says "agent X, identity verified against credential Y, executed action Z on resource W at 14:32:47, authorised under permission policy P" is the difference between a log and an audit trail. The chain is tamper-evident. Retrospective investigation becomes possible.
4. Centralised verbose logging. Agent actions are logged at the action level, not the session level. This is the Logic Logging discipline from Chapter 10 applied to the identity layer: the reasoning chain and the identity chain are both captured, and both are required for a complete audit trail.
5. Role-based permission enforcement at the action level. Permissions are enforced at the moment of action execution, not just at authentication time. An agent that is authenticated to access a database cannot take actions outside its defined role scope within that authenticated session. This is the shift from perimeter enforcement to continuous enforcement, applied to the agent-action layer.
6. Rapid revocation. A compromised or misbehaving agent can have its identity credential revoked within seconds, terminating all active sessions and blocking all future actions. An organisation without this capability has a governance gap that precedes every other identity control. If you cannot terminate a misbehaving agent in seconds, your remaining identity controls are incomplete.
7. Native human oversight gates. Specific action classes are designated as requiring human-in-the-loop approval before execution. These gates are enforced at the identity layer, not left to the agent's own judgement. The agent cannot override the gate by reasoning that the action is appropriate. The gate is structural.
These seven components map directly to the NCSC MCSS Level 2 requirements as applied to the non-human agent layer. Automated IAM governance maps to components 1, 2, and 5. Asset register and risk classification metadata maps to component 2. Configuration-as-code maps to components 3 and 5. Continuous drift monitoring maps to components 4 and 6. A Level 2-compliant organisation that has not deployed these seven components for its AI agents is Level 2-compliant for its human identity estate and structurally exposed in its agent estate.
The IT/OT Parallel: A Structural Diagnosis
The CISA ZT for OT guidance offers a precise structural diagnosis of what happens when systems connect to networks before the governance frameworks arrive. OT environments were designed for availability, not identity management. Adding network connectivity to a PLC or SCADA controller did not automatically add authentication, authorisation, or audit. Those capabilities had to be retrofitted, slowly, with compensating controls where full Zero Trust principles could not be applied without disrupting operational continuity.
AI agents are following the same trajectory. They are being deployed into enterprise environments that were not designed to govern them. The capabilities exist: Microsoft Entra Agent ID, SPIFFE/SPIRE, the Agent 365 control plane. The frameworks are arriving: the MCSS NHI extension, the NZISM Chapter 16 update on roadmap. The question for NZ practitioners is not whether to retrofit NHI governance. It is whether to retrofit it proactively, before the regulatory requirement lands, or reactively, after the compliance gap becomes a reported finding.
The OT experience is instructive here. Organisations that waited for mandatory OT security controls to retrofit governance into legacy SCADA environments found the process significantly more expensive and disruptive than organisations that started the retrofit when the guidance was advisory rather than mandatory. The same dynamic will apply to NHI governance. Agents that have been operating without identity controls accumulate operational dependencies that governance controls must work around. Starting early is cheaper.
New Zealand's DPMC critical infrastructure consultation, with submissions closed on 19 April 2026 and the analysis now under way, is building the policy framework that will eventually mandate cybersecurity obligations for critical infrastructure operators. Those operators run OT systems. They also run, or will run, AI agents. The CISA guidance is the most current government-produced reference architecture for the technical standards NZ's proposed regime will need to address. Practitioners who want to be ahead of the forthcoming framework, rather than responding to it, should treat the CISA guidance as directional.
If the identity governance posture raised in the board-level governance series on NHI risk prompted questions about your AI agent population, this chapter is the architectural answer to those questions.
WebMCP and the Collection Obligation
On the practical side of the 2026 agent deployment picture, WebMCP (Web Model Context Protocol) entered public origin trial in Chrome 149 as a proposed W3C standard, with early adopters including Shopify, Instacart, Target, and TurboTax. Note: origin trial status is subject to change; verify current deployment status at publication. WebMCP allows AI agents to act on web properties through a standardised protocol, making traditional human-centric browser interfaces accessible to autonomous agents.
The NHI governance problem this creates is specific. A WebMCP agent acting on a web property operates through the same browser session mechanisms designed for human users: cookies, session tokens, OAuth flows. If the agent is operating under a human user's credentials, it does not have a distinct identity. Its actions are logged as the human user's actions. Its permissions are the human user's permissions. Its revocation path is the human user's account. None of those controls are designed to govern an agent.
The architectural prescription is straightforward: any WebMCP agent acting on behalf of an enterprise should hold a distinct NHI credential scoped to its permitted actions. It should not operate as a proxy under a human user's session. That is not a WebMCP-specific requirement. It is the same NHI architecture principle that applies to every other agent in the estate.
Alongside the identity question, WebMCP raises a compliance question that has been live since 1 May 2026. Information Privacy Principle 3A, which commenced under the Privacy Amendment Act 2025 on 1 May 2026, requires agencies that collect personal information from indirect sources to take reasonable steps to notify the individuals concerned. An AI agent that collects personal information from a source other than the individual is an indirect collection. The notification obligation falls on the collecting agency, not on the agent.
The compliance question that collection notification obligation creates is, at root, an identity question. You cannot demonstrate that you have met the "reasonable steps" obligation unless you can identify, with specificity, which agents are collecting personal information, from which sources, on whose behalf, and for what purpose. If your agent inventory is incomplete, your compliance posture under that obligation is incomplete regardless of your policies.
The architectural extension required is a flag at the collection-action level. When an agent action constitutes indirect collection, the action log should capture: agent identity, collection source, data classification, purpose, and notification status. This is the identity-layer implementation of an information privacy obligation. It does not require new law. It requires the NHI identity architecture described in this chapter to be extended with a collection-action classification field, analogous to the cultural classification field established in the agentic asset register developed in Chapter 13.
Tuesday's piece on EU AI Act compliance addressed the transparency obligation at the model layer. This chapter addresses the identity governance obligation at the agent layer.
Five Questions Before the Next Reporting Window
Your next MCSS reporting cycle will require evidence of identity and access management governance across your digital estate. Before that window opens, five questions need answers.
Can you enumerate every AI agent in your environment? Not every agent you know you have deployed. Every agent operating, including agents deployed by teams that did not notify the architecture function, agents inherited through vendor integrations, and agents created by automation workflows that have since evolved. If your answer requires manual survey rather than a registry query, the agentic asset register is your first infrastructure project.
Does each agent have a distinct, non-shareable identity credential? If any agent is operating under a human user's OAuth session, a shared service account, or a long-lived API key with no expiry date and no owner, you have identity sprawl rather than identity governance.
Are permissions enforced at the action level, not just the session level? Authentication-time permission checks are necessary but not sufficient. An agent authenticated to access a database can still take actions outside its intended role scope if the permission check does not extend to the action execution layer.
Do you have a rapid-revocation capability for each agent? When an agent is compromised or begins behaving outside its authorised scope, how quickly can you terminate it? If the answer involves manual intervention, escalation, and change management, the revocation path is not rapid enough.
Can you demonstrate, at audit, which agents collected personal information, from which sources, and whether notification obligations were met? The collection notification obligation under the Privacy Amendment Act 2025 commenced on 1 May. It is live. If your audit trail does not extend to agent-level collection attribution, you have a privacy compliance gap alongside the identity governance gap.
These five questions are not an exhaustive NHI governance programme. They are the baseline diagnostic that tells you where to start. Most NZ organisations can complete the enumeration and identity-mapping exercises in the current quarter. The permission enforcement and revocation infrastructure takes longer, but it takes measurably less time when you are building it on top of a known inventory than when you are building it on top of a guess.
The three-capability insider threat architecture from Chapter 5 describes how agents simultaneously holding access to sensitive data, exposure to untrusted content, and external communication or execution capability constitute an insider threat by design. Identity governance is the first control that addresses all three simultaneously. An agent with no distinct identity, no revocation path, and no action-level logging is maximally exposed on all three dimensions. This chapter builds the identity layer that changes that exposure profile.
The orbital compute architectures discussed in Space AI Monday this week extend the NHI problem to environments where no enforcement mechanism currently exists. The identity architecture this chapter describes applies in any compute environment. When AI moves to orbit, the NHI problem does not disappear. It becomes harder.
Knowing which agents are operating is the prerequisite for verifying what they are reasoning. That is the work the following chapters on agent-level verification take forward.
The Architecture Ahead
This chapter opens Part Four of the book. The three chapters that follow build the technical implementation stack on top of the governance foundation established here.
Chapter 17 addresses SPIFFE and the SPIRE Runtime Environment: the open standard for issuing short-lived, cryptographically verifiable identities to agent workloads based on what they are running, not just where they are running. If the question this chapter asks is "what identity framework do agents need?", the next chapter answers the implementation question with deployable YAML and configuration examples.
Chapter 18 addresses FIDO2 and passkeys: the human-side of the identity architecture that runs alongside the NHI layer, and the bridge between human authentication and agent-on-behalf-of-user delegation.
Chapter 19 addresses OAuth 2.1 delegation: the protocol layer that governs when a human authorises an agent to act on their behalf, and how that delegation can be scoped, audited, and revoked.
The non-human identity crisis is not a product problem. Every component required to close it is available today: Microsoft Entra Agent ID, SPIFFE/SPIRE, the Agent 365 control plane, OPA policy-as-code enforcement. It is an architecture problem. Organisations that have not extended their Zero Trust governance to cover their agent population have not made a technology choice. They have made a governance omission. The remediation is architectural: define every agent, assign every agent a distinct identity, enforce every agent's permissions at the action level, and build the revocation path before you need it.
Your first MCSS Level 2 assessment is behind you. The next one is ahead. The agents will still be there when it arrives.
What was the last time your team audited the non-human identities in your environment, and what did you find that you were not expecting?
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] Microsoft Security Blog. "New Tools and Guidance: Announcing Zero Trust for AI." 19 March 2026. https://www.microsoft.com/en-us/security/blog/2026/03/19/new-tools-and-guidance-announcing-zero-trust-for-ai/
[2] Microsoft Security Blog. "Secure Agentic AI: End to End." 20 March 2026. https://www.microsoft.com/en-us/security/blog/2026/03/20/secure-agentic-ai-end-to-end/
[3] Microsoft Security Blog. "Secure Agentic AI for Your Frontier Transformation." 9 March 2026. https://www.microsoft.com/en-us/security/blog/2026/03/09/secure-agentic-ai-for-your-frontier-transformation/
[4] Microsoft Entra Blog. "Microsoft Entra Innovations Announced at RSAC 2026." April 2026. https://techcommunity.microsoft.com/blog/microsoft-entra-blog/microsoft-entra-innovations-announced-at-rsac-2026/4502146
[5] CISA, Department of War, Department of Energy, Federal Bureau of Investigation, Department of State. "Adapting Zero Trust Principles to Operational Technology." 29 April 2026. https://www.cisa.gov/news-events/news/cisa-and-us-government-partners-unveil-guide-accelerate-zero-trust-adoption-operational-technology
[6] National Cyber Security Centre NZ. "Minimum Cyber Security Standards." Published 30 October 2025. https://www.ncsc.govt.nz/
[7] National Cyber Security Centre NZ. "New Zealand Information Security Manual v3.9." Published 9 May 2025. https://www.nzism.gcsb.govt.nz/
[8] Layer3. "NZ Threat Landscape 2026." 2026. (Commercial publication; available via Layer3.)
[9] Trend Micro; Astrix Security. Multi-vendor NHI identity ratio intelligence, 2026. (Referenced in Chapter 9 research package.)
[10] Privacy Amendment Act 2025 (NZ). Information Privacy Principle 3A. Commenced 1 May 2026. https://www.legislation.govt.nz/
[11] Department of the Prime Minister and Cabinet. Critical Infrastructure Security Consultation. Submissions closed 19 April 2026. https://www.dpmc.govt.nz/