The Sixth Pillar: Agent Identity and the New Perimeter
Readability (Flesch-Kincaid): estimated Grade 12 / 10-13 targetAvg sentence length: estimated 18 words / 15-22 targetPassive voice ratio: estimated 10% / below 15% targetNTP claim scan: 16 e-type sourced / 6 n-type / 2 flagged (OWASP existence noted in source notes not article body; Bandara et al. arXiv preprint framed with peer-review qualifier)
Return to Part 0: Table of ContentsPrevious Chapter: Chapter 11 - PSR and Cloud Risk: Navigating Data Sovereignty for Agentic AI
Yesterday, New Zealand's National Cyber Security Centre published guidance on frontier AI models. It describes the threat accurately: autonomous AI agents can discover vulnerabilities and act on them at a speed and scale that changes the threat landscape. The recommended response includes patching frequently, segmenting networks, and reviewing vulnerability management programmes.
Not once does the document mention Zero Trust architecture. Not once does it mention agent identity. And there is a third dimension it does not address at all, one that matters specifically for Aotearoa: what happens when the agents being patched are processing taonga?
The NCSC guidance describes the right security floor. What this chapter provides is the architecture above it.
When Five Pillars Are Not Enough
The Cybersecurity and Infrastructure Security Agency's Zero Trust Maturity Model defines five pillars: Identity, Devices, Networks, Applications and Workloads, and Data. Together they describe a security architecture built on one foundational assumption: somewhere in the chain, a human being initiated the action. A person logged in with a credential. A device was enrolled. A session was established.
Autonomous AI agents break this assumption in three specific ways.
First, the per-session model fails. NIST SP 800-207 specifies that access to resources should be granted on a per-session basis. An autonomous agent does not operate within a single session. It may execute a chain of tool calls across hours or days, spawn sub-agents with delegated permissions, and interact with external systems at each step. The per-session grant model has no natural anchor point in this workflow. Chapter 4 established the 82:1 projection for agent-to-human ratios in enterprise environments by 2027 (Deloitte/Salesforce Agentic AI Survey, 2025). At that ratio, there is no human session count that maps cleanly to agent activity count.
Second, device identity becomes meaningless. Device-level Zero Trust assumes the endpoint matters: a managed device with an enrolled certificate is more trustworthy than an unmanaged one. An AI agent running in a cloud container has no device in any meaningful sense. It may execute on ephemeral infrastructure that exists for minutes. Device posture cannot serve as the identity anchor.
Third, network segmentation addresses the wrong boundary. Chapter 9 described the Lethal Trifecta: access to sensitive data, exposure to untrusted content, and the ability to communicate. The five CISA pillars address each Trifecta component partially. They address them at the network layer. An agent that has been granted legitimate access, that receives a prompt injection through a legitimate content source, and that communicates through an approved API channel satisfies every network-layer control while executing a malicious instruction chain. The boundary to enforce is not the network boundary. It is the agent's identity.
Three Authorities, One Quarter, No Coordination
In Q1 and Q2 2026, three independent authorities converged on the same architectural pattern.
On 19 March 2026, Microsoft published its Zero Trust for AI reference architecture. It introduced AI as a sixth Zero Trust pillar and specified that AI agents must hold cryptographically verifiable identities distinct from, but linked to, the initiating human user. The four requirements: verify the identity and behaviour of AI agents continuously; restrict access to models, prompts, plugins, and data sources to only what is needed; design AI systems to be resilient to prompt injection and lateral movement; and monitor agent behaviour at the network layer. Microsoft is developing a Zero Trust Assessment for AI pillar, expected in summer 2026.
On 22 April 2026, Google launched the Gemini Enterprise Agent Platform at Cloud Next. It shipped three components as mandatory elements of enterprise agentic architecture: Agent Identity (each agent assigned its own cryptographically verifiable digital identifier, enabling auditable work tracking), Agent Registry (inventory, lifecycle management, and access controls per agent), and Agent Runtime (provisioning for multi-day autonomous workflows). Agent-to-agent orchestration in the Gemini platform implements delegation tracing: sub-agents inherit scoped permissions from parent agents, not the full permission set of the originating human user. That single design decision is the difference between a governed multi-agent system and a privilege escalation waiting to happen.
In February 2026, the Cloud Security Alliance published the Agentic Trust Framework as an open governance specification (community-authored, available on GitHub). It defines three deployment tiers: Tier 1, where all agent actions require human approval; Tier 2, where post-action notification under governance is acceptable; and Tier 3, where policy-as-code and SOC-integrated incident response govern autonomous operation. Agent Identity and an agent registry are requirements at every tier, including Tier 1. No organisation can operate even the most constrained agent deployment without a traceable identity per agent.
No central coordination produced this convergence. A hyperscaler security architecture team, a product platform launch, and an industry consortium framework arrived at the same pattern independently, in the same ninety-day window. That is not vendor marketing. It is the architectural baseline forming in real time.
The Lethal Trifecta: Complete Mitigation at Last
Chapter 5 introduced the Lethal Trifecta. Three conditions, when present simultaneously in an agentic deployment, create the conditions for a serious security incident: access to sensitive data, exposure to untrusted content, and the ability to communicate externally. Chapters 7 through 11 built the governance and compliance layer that constrains each condition. The Trifecta has not, until this chapter, had a named and complete mitigation pattern.
Agent Identity, Agent Registry, and Agent Gateway are that pattern.
Agent Identity closes the first question the Lethal Trifecta raises: which entity has access to sensitive data? Without a cryptographically verifiable per-agent identity, the answer to a post-incident investigation is "the service account." With agent identity, the answer is traceable to a specific agent, a specific deployment, a specific task chain, and the human owner accountable for that agent's behaviour. Identity is not just a security control. It is the evidence layer that makes governance possible.
Agent Registry closes the second question: what access has been granted, to what data, under what conditions? Chapter 9's NHI Security Strategy established the five components required for governing non-human identities: discovery, lifecycle management, zero-standing privilege, workload federation, and behavioural anomaly detection. The Agent Registry is the governance structure that makes all five operational. An agent not in the registry has no governed identity. An agent not in the registry cannot be granted access under a zero-standing privilege model because there is no record to scope the permission against. Shadow AI is ungovernable not because the AI is hidden, but because the identity is unregistered.
Agent Gateway closes the third question: what communication was permitted, to what external systems, under what policy? The Logic Firewall, introduced in Chapter 5 and returning in technical depth in Chapter 26 (the new numbering for what was formerly Chapter 25), is a reasoning layer between agents and the external environment. The Agent Gateway is its operational implementation: policy-enforced communication that verifies the agent's identity, checks the request against the registry, and permits or blocks the external interaction based on declared purpose and classification.
Together, the three components answer the three Trifecta questions simultaneously. This is the first chapter in the book to provide a complete named mitigation for all three Trifecta components. It has taken twelve chapters to build the governance, compliance, and identity foundations that make the mitigation pattern deployable. That is the correct sequence: you cannot govern what you cannot identify, and you cannot identify what you have not registered.
The NZ Regulatory Picture: What Exists, What Does Not
NZISM v3.9 is the current standard for New Zealand government systems. It mandates Zero Trust architecture, specifies authentication controls, and requires non-human identity governance. It does not specify agent identity, agent registry, or agent gateway requirements. All NZISM references in this chapter cite version 3.9.
This is not a criticism of NZISM. Standards follow practice. The three-authority convergence described above is the practice that NZISM v3.9 will likely incorporate within twelve to eighteen months, based on the pattern-to-standard lag observable in previous NZISM updates. NZ government architects who implement the Agent Identity pattern now are building a posture that future NZISM revisions will likely formalise. They are ahead of the standard, not outside it.
IPP 3A takes effect tomorrow. Chapter 9 established the direct connection between agent identity and privacy compliance: agents that collect personal information from indirect sources without traceable identity cannot demonstrate IPP 3A compliance. The notification obligation falls on the agency, not the agent. An agency that cannot enumerate which agent collected what data from which source, on which date, is exposed. Agent Identity is the privacy compliance mechanism, not just the security control.
For NZ financial institutions, a useful reference point is Australia's APRA CPS 234. An analysis published by SMBTech Australia in April 2026, citing CPS 234 obligations, argues that for APRA-regulated entities, agentic AI systems with API access and production-adjacent permissions should be treated as privileged insiders from a Zero Trust control perspective. RBNZ's prudential framework does not yet include agent-specific identity requirements. The CPS 234 framing is a forward indicator of likely RBNZ evolution, not a binding NZ obligation. NZ financial institutions should treat the APRA framework as a compliance planning signal.
A research paper by Bandara et al., published on arXiv on 6 April 2026 (preprint; not yet peer-reviewed), proposes continuous telemetry-driven governance as a replacement for periodic audit cycles. Its four principles map to what Agent Identity enables: proactive discovery over reactive declaration; telemetry evidence over manual attestation; continuous posture over point-in-time audit; and architecture-backed proof over policy-document trust. An agent without an identity cannot generate the telemetry that continuous governance requires. Identity is the foundation of the evidence chain.
The Dimension the International Frameworks Have Missed
Microsoft's Zero Trust for AI reference architecture addresses agent identity in the context of enterprise security. Google's Gemini Enterprise platform addresses it in the context of enterprise product governance. The Cloud Security Alliance's Agentic Trust Framework addresses it in the context of compliance maturity. None of them addresses it in the context of cultural governance.
In Aotearoa, this is a gap.
When an AI agent processes whakapapa data, it is touching information that carries relational and genealogical significance that no security classification system adequately captures. When an agent processes data about an iwi's land holdings, asset portfolios, or health statistics, it is handling taonga. When an agent operates in a context where its outputs may affect decisions about whānau, it is exercising a form of authority over culturally significant matters.
Kaitiakitanga, the principle of active stewardship and guardianship, is not satisfied by encryption at rest. It is not satisfied by access controls at the network layer. It requires that every entity touching culturally significant data can be identified, that the purpose of that access was declared in advance, that the access was authorised by those with the mana to authorise it, and that the agent's actions can be audited after the fact.
Agent Identity is the prerequisite for all of those requirements. Without a traceable identity, you cannot demonstrate that the agent was authorised. Without a registry entry with declared purpose, you cannot demonstrate that access was within scope. Without an agent gateway with policy enforcement, you cannot demonstrate that communication of taonga data was controlled.
Te Mana Raraunga, the Māori Data Sovereignty movement, calls for Māori data to be governed under tikanga principles and Te Tiriti o Waitangi obligations. The analysis in this section is an interpretive mapping of what those principles require of an agentic architecture: this is the author's analytical framework applied to those principles, not a published statement from Te Mana Raraunga. Part Three of this book (Chapters 13 through 16, beginning next week) will build the technical architecture for meeting those obligations with appropriate sourcing. But Part Three depends on a prerequisite this chapter establishes: the agent has an identity. Remove Agent Identity governance, and the technical patterns of Part Three become unimplementable. You cannot attach tikanga-derived governance to an entity you cannot identify.
The NCSC guidance published yesterday is a useful document. Patching frequently is correct. Reducing the attack surface is correct. Multi-factor authentication is correct. None of it is wrong. It is a perimeter-hygiene response to a logic-layer threat, and it is silent on the cultural governance dimension that distinguishes NZ's architecture obligations from those of any other jurisdiction. Building your frontier AI security posture on patching guidance alone is building on a foundation that will need to be extended. The architecture in this chapter is the extension that will last.
Agent Identity in Practice: A Registration Policy
The following Open Policy Agent configuration demonstrates a complete agent identity registration and governance policy. It extends the OPA pattern from Chapters 7 and 9 and adds three new elements: cultural classification, delegation chain enforcement, and gateway authorisation.
package agent.identity.governanceimport future.keywords.ifimport future.keywords.in# ===========================================================================# AGENT REGISTRATION POLICY# Chapter 12: The Sixth Pillar - Agent Identity and the New Perimeter# Extends: Chapter 9 NHI Security Strategy / OPA provenance pattern# ===========================================================================# Agent classification tiers (CSA Agentic Trust Framework alignment)agent_tier := tier if {input.agent.requires_human_approval == truetier := "tier_1"}agent_tier := tier if {input.agent.requires_human_approval == falseinput.agent.post_action_notification == truetier := "tier_2"}agent_tier := tier if {input.agent.requires_human_approval == falseinput.agent.post_action_notification == falseinput.agent.policy_as_code == truetier := "tier_3"}# Cultural data classification (Te Mana Raraunga / tikanga governance)# Separate from NZISM security classification; both apply independently.# Note: the field names below (maori_governance_required, whakapapa_present,# iwi_authorisation_present) are conceptual demonstrations of the schema# this architecture requires. The authoritative field schema for cultural# classification will be developed in Part Three (Chapters 13-16).cultural_classification := class if {input.data.maori_governance_required == trueinput.data.whakapapa_present == trueclass := "taonga_whakapapa"}cultural_classification := class if {input.data.maori_governance_required == trueinput.data.whakapapa_present == falseclass := "taonga_general"}cultural_classification := class if {input.data.maori_governance_required == falseclass := "standard"}# ===========================================================================# REGISTRATION REQUIREMENTS# An agent MUST be registered before any access is granted.# ===========================================================================registration_required if {input.agent.cryptographic_identity_present != true}registration_required if {input.agent.registry_entry_exists != true}registration_required if {input.agent.declared_purpose == ""}registration_required if {input.agent.owning_team == ""}# For taonga data: additional cultural governance registration requiredcultural_governance_registration_required if {cultural_classification != "standard"input.agent.iwi_authorisation_present != true}# ===========================================================================# DELEGATION CHAIN ENFORCEMENT# Sub-agents inherit scoped permissions from parent agents, not from# the originating human user's full permission set.# ===========================================================================allow_delegation if {input.delegation.parent_agent_registered == trueinput.delegation.scope_is_subset_of_parent == trueinput.delegation.human_owner_authorised_delegation == true}deny_delegation[reason] if {not allow_delegationinput.delegation.scope_is_subset_of_parent == falsereason := "Delegation scope exceeds parent agent permissions. Privilege escalation via delegation is not permitted."}# ===========================================================================# AGENT GATEWAY AUTHORISATION# Communication to external systems requires gateway authorisation.# ===========================================================================gateway_permit if {input.agent.registry_entry_exists == trueinput.communication.target_system in input.agent.declared_external_systemsnot communication_blocked_cultural[_]not communication_blocked_classification[_]}# Cultural governance: taonga data must not leave NZ without explicit authorisationcommunication_blocked_cultural[reason] if {cultural_classification in {"taonga_whakapapa", "taonga_general"}input.communication.target_region != "nz"input.communication.iwi_offshore_authorisation != truereason := sprintf("Communication of taonga data to region '%v' requires explicit iwi authorisation under tikanga governance.",[input.communication.target_region])}# NZISM v3.9 / PSR classification: restricted data must not cross jurisdiction without approvalcommunication_blocked_classification[reason] if {input.data.nzism_classification in {"RESTRICTED", "SENSITIVE"}input.communication.target_region != "nz"input.communication.gcso_approval != truereason := sprintf("Communication of '%v' data to region '%v' requires GCSO approval per PSR INFOSEC and NZISM v3.9.",[input.data.nzism_classification, input.communication.target_region])}# ===========================================================================# IPP 3A PROVENANCE (extending Chapter 9 pattern)# Agents processing personal information must carry provenance metadata.# ===========================================================================ipp3a_compliant if {input.data.contains_personal_information == false}ipp3a_compliant if {input.data.contains_personal_information == trueinput.data.provenance.collection_source != ""input.data.provenance.notification_status in {"notified", "exemption_recorded"}input.data.provenance.collecting_agent_id == input.agent.cryptographic_id}# ===========================================================================# DENY WITH EXPLANATION# ===========================================================================deny[reason] if {registration_requiredreason := sprintf("Agent '%v' is not registered. All agents require cryptographic identity, registry entry, declared purpose, and owning team before access.",[input.agent.name])}deny[reason] if {cultural_governance_registration_requiredreason := sprintf("Agent '%v' is accessing taonga data without iwi authorisation on record. Cultural governance registration required.",[input.agent.name])}deny[reason] if {not ipp3a_compliantreason := sprintf("Agent '%v' is processing personal information without IPP 3A-compliant provenance metadata. Effective 1 May 2026.",[input.agent.name])}deny[reason] if {communication_blocked_cultural[reason]}deny[reason] if {communication_blocked_classification[reason]}This policy extends the Chapter 9 NHI Security Strategy OPA pattern with three additions that Chapter 9 could not yet implement because the architectural foundation was incomplete. Cultural classification operates independently from NZISM security classification: a piece of taonga data may carry a LOW NZISM classification (because its technical sensitivity is low) while carrying the highest cultural governance requirement. Both classifications apply simultaneously, and the more restrictive constraint governs. The delegation chain enforcement prevents the privilege escalation pattern identified in the Google Gemini Enterprise architecture: sub-agents are constrained to the parent agent's permission scope, which is itself scoped against the human owner's authorised purpose. The collecting_agent_id field in the IPP 3A provenance record links the privacy obligation directly to the agent's cryptographic identity, making the compliance chain traceable rather than declaratory.
The CSA Maturity Model: Where Are You?
The Cloud Security Alliance's three-tier maturity model provides a practical self-assessment framework. Most NZ organisations deploying agentic AI today are in Tier 1, or are below it.
Below Tier 1 is the ungoverned state: agents operating without registered identity, without declared purpose, without an owning team accountable for their behaviour. This is shadow AI with API keys. Chapter 3 established the $670,000 breach cost premium associated with shadow AI deployments (IBM Cost of a Data Breach, 2025). Chapter 9 established that the 144:1 non-human to human identity ratio means ungoverned agents are not an edge case. They are the majority of the identity surface in most enterprises.
Tier 1 requires: agent identity registration, human approval for all actions, and a registry entry per agent. An organisation at Tier 1 knows what agents it has deployed. It can enumerate them. It has a human owner for each one. Every action the agent takes requires a human to authorise it. This is the minimum governable state.
Tier 2 adds anomaly detection, post-action notification under governance, and role-based access controls per agent. Agents at Tier 2 can act autonomously within defined parameters, with governance visibility after the fact. This is an appropriate tier for agents operating in regulated environments where real-time human approval is operationally impractical but accountability is legally required.
Tier 3 adds policy-as-code enforcement, SOC-integrated incident response, and streaming anomaly detection. Agents at Tier 3 operate within a fully automated governance envelope: policy decisions are made programmatically, anomalies trigger SOC workflows, and the governance posture is continuous rather than periodic. This is an appropriate tier for agents with significant autonomous authority in high-stakes domains.
Most NZ enterprises should be targeting Tier 2 as the governance baseline for production agentic deployments in 2026. Tier 1 is the entry requirement; some environments may remain at Tier 1 for extended periods where full human oversight is both practical and appropriate. Tier 3 is the forward target for high-risk or highly autonomous agents. The CSA framework does not prescribe timelines, but IPP 3A enforcement from 1 May 2026 and the MCSS reporting framework already create compliance requirements that Tier 1 registration directly addresses.
What This Means for the Architecture You Build Next Week
Chapter 9 gave you the NHI Security Strategy: discovery, lifecycle management, zero-standing privilege, workload federation, and behavioural anomaly detection. Chapter 11 gave you the cloud governance layer: where your agents can run, based on what data they process. This chapter gives you the identity architecture that connects those two.
The implementation sequence is: register before deploy. Before any agent is permitted to operate in a production environment, it requires a registry entry that includes a cryptographic identifier, a declared purpose, an owning team, and a cultural data classification where relevant. The OPA policy above enforces this as a hard gate. An unregistered agent cannot access any governed resource.
The NCSC guidance published yesterday is the right starting point for organisations that have not yet begun. Patching, segmentation, MFA: these are the controls that the guidance recommends, and they are correct. They are the security floor. Above that floor is the architecture that governs not what your infrastructure looks like, but what your agents are, what they are authorised to do, and whether the data they touch is handled with the stewardship it is owed.
NZISM v3.9 will likely catch up. RBNZ will likely follow the APRA pattern. NZ will likely have sector-specific agent identity requirements within the next regulatory cycle. Architects who build the pattern now will not need to rebuild it when the standard arrives. Whether that prediction proves exact depends on implementation details we cannot yet see. The pattern is sound. The timeline is qualified.
Next week in Part Three, Chapter 13: Māori Data Sovereignty Foundations. The identity layer established here is the prerequisite for everything that follows. Part Three will build the technical architecture for meeting Te Tiriti obligations, tikanga governance requirements, and Te Mana Raraunga principles. It begins where this chapter ends: with an agent that has a name.
When an AI agent processes data in your organisation this week, can you name it, trace its authorisation chain, and confirm it had the appropriate cultural governance clearance for the data it touched? That question is not hypothetical. It is the first question Part Three will answer architecturally.
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 & 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] National Cyber Security Centre (NZ). "The Implications of Frontier AI Models for Cyber Defence." 23 April 2026. https://www.ncsc.govt.nz/protect-your-organisation/the-implications-of-frontier-ai-models-for-cyber-defence/
[2] Microsoft Security Blog. "Zero Trust for AI: Reference Architecture." 19 March 2026. https://www.microsoft.com/en-us/security (Zero Trust for AI)
[3] Google Cloud Next 2026. "Gemini Enterprise Agent Platform: Agent Identity, Registry, and Runtime." SiliconAngle, 22 April 2026.
[4] Cloud Security Alliance. "Agentic Trust Framework." February 2026. https://github.com/cloudsecurityalliance (community specification)
[5] Deloitte / Salesforce. "Agentic AI Survey 2025." August-September 2025. (3,235 enterprise leaders). Source: Chapter 4 established 82:1 agent-to-human projection.
[6] IBM Security. "Cost of a Data Breach Report 2025." 2025. (Shadow AI adds $670,000 to average breach cost). Source: Chapter 3 established this figure.
[7] NZISM v3.9. "New Zealand Information Security Manual, version 3.9." GCSB/NCSC. https://www.nzism.gcsb.govt.nz/
[8] Privacy Amendment Act 2025 (NZ). Royal Assent 23 September 2025. IPP 3A effective 1 May 2026. https://www.legislation.govt.nz/
[9] SMBTech Australia. "Agentic AI and CPS 234 Privileged Access Obligations." April 2026. (APRA CPS 234 analysis; cited as forward indicator for NZ context; not a binding NZ obligation.)
[10] Bandara, M. et al. "AI Trust OS: Continuous Telemetry-Driven Governance." arXiv 2604.04749, 6 April 2026. https://arxiv.org/abs/2604.04749 (arXiv preprint; not yet peer-reviewed at publication date.)
[11] Te Mana Raraunga. Māori Data Sovereignty principles. https://www.temanararaunga.maori.nz/