Identity Is the Architecture: Agentic Asset Registers and the NZISM Chapter 16 Horizon
Chapter 12: The Sixth Pillar: Agent Identity and the New Perimeter | Series Overview: Zero Trust Architecture for the Agentic Enterprise | Chapter 14: Maori Data Sovereignty: Foundations and Tikanga Principles (LinkedIn URL: TBC)
In Q2 2025, unauthorised access accounted for NZ$3.7 million in NZ direct financial loss, the largest single share of any attack category that quarter, according to Layer3's NZ Threat Landscape 2026 report, which cites NCSC NZ data. On 1 May 2026, the Information Privacy Principle 3A amendment commenced. From that date, NZ organisations carry a statutory obligation to notify individuals when their personal information is collected indirectly, including when an AI agent collects it from a third party on the organisation's behalf.
Two questions, both architectural, both unanswerable without an inventory:
- Which AI agents in your organisation collected personal information from a third party in the last thirty days?
- If a credential associated with one of those agents was compromised this week, how long would it take to revoke its access end-to-end?
If those questions feel uncomfortable, you are reading the right chapter.
The Identity Perimeter Is Now the Operative Perimeter
For the better part of two decades, security architecture treated the network as the primary perimeter. Firewalls, segmentation, DMZs, micro-segmentation: these were the architectural controls of the perimeter era. Identity was a participant in access decisions, but the network defined where the boundary was.
That has changed. Per Google Cloud's 2025/2026 security reporting, cited in Layer3's NZ Threat Landscape 2026, identity compromise underpinned 83 per cent of major cloud and SaaS breaches across 2025 and into early 2026. The implication is structural rather than tactical. When you compromise identity, you compromise the architecture.
The NZ-domestic evidence follows the same pattern. In December 2025, the ManageMyHealth incident traced to valid user credentials; multi-factor authentication was available but not mandatory for the affected module. In February 2026, the MediMap incident traced to unauthorised access via credential compromise, after which the organisation moved to mandatory two-factor authentication across web and mobile platforms. In March 2026, NCSC NZ published a warning that attackers had been targeting IT helpdesks, constructing credible false identities from publicly available data and prior breach datasets, then requesting password resets or MFA changes.
Three incident shapes. One architectural finding.
In each case, the control that mattered was not firewall configuration. It was whether the system deciding "is this who they claim to be" was operating correctly. In the ManageMyHealth case, MFA optionality created the gap. In the MediMap case, credential compromise without behavioural detection created the gap. In the NCSC advisory, the gap was the human in the identity verification loop. In every case, the unit of analysis was the identity assertion, not the network packet.
This is the architecture EA practitioners now design for. The perimeter that matters is the one that decides whether a request belongs to whom it claims to belong to. Everything else supports that control.
The Agentic Extension: From Pillar to Practice
In the human-identity case, governance carries decades of accumulated practice: provisioning, deprovisioning, role-based access control, identity lifecycle management, and joiner-mover-leaver workflows. The 2025 to 2026 challenge is not that humans need new identity governance. It is that AI agents, as a new class of identity-bearing actor, need governance built in their own right.
Chapter 12 established Agent Identity as the Sixth Pillar of Zero Trust, with independent confirmation from Microsoft, Google, and the Cloud Security Alliance in Q1 to Q2 2026. Chapter 5 documented the Lethal Trifecta: the three-capability combination of sensitive data access, exposure to untrusted content, and the ability to communicate externally that turns an agent into a governance risk. Chapter 13's task is to operationalise both. How do you register, govern, and revoke agent identities at scale?
The pattern that has emerged is the agentic asset register. It is converging from three independent directions in early 2026.
The regulatory direction. The EU AI Act's Articles 9, 13, and 14, applicable from 2 August 2026 unless the Omnibus simplification measure passes, require risk management as an evidence-based ongoing process, deployer-interpretable systems, and human oversight as native architecture. The minimum operational infrastructure to meet these requirements is: a unique agent identifier, documented capabilities and granted permissions, cryptographic action signing with an immutable audit chain, centralised verbose logs, role-based permission enforcement at the action level, and rapid revocation capability.
The commercial direction. Proofpoint's Agent Integrity Framework 2026, published in March 2026, requires continuous intent verification, agent behaviour monitoring, and real-time alignment enforcement. The operational footprint is identical to the EU AI Act's compliance requirements.
The operational direction. At Google Cloud Next on 22 April 2026, Google shipped Agent Identity, Agent Registry, and Agent Gateway as mandatory layers of its Gemini Enterprise Agent Platform. This is production infrastructure, available now, from the largest enterprise cloud provider.
When regulatory, commercial, and operational domains converge on the same architectural pattern within ninety days of each other, the pattern is not one option among many. It is the baseline.
The convergence matters for a second reason. In 2024 and most of 2025, NZ practitioners working on agentic governance had to choose between regulatory frameworks, which were high in abstraction and slow to apply, commercial security tooling, which was proprietary and narrow, and platform vendor capabilities, which were vendor-specific. The Q1 to Q2 2026 convergence collapses that fragmentation. The same six fields appear in all three directions. Organisations that adopt the register pattern from any one direction will find themselves architecturally compatible with the other two.
Where board governance of identity risk requires an architectural foundation, the agentic asset register provides the inventory infrastructure that makes that governance actionable. That is the demand the Cyber Sunday Cyber News series has framed from the board level; this chapter provides the architectural supply.
What the Register Contains
A workable agentic asset register is not exotic. It is the configuration management database (CMDB) pattern extended to agentic workloads. NZ EA practitioners who operate a mature CMDB already have most of the structural primitives in place. The additions are agent-specific.
A practical YAML-anchored register entry looks like this:
agent:id: "agent-claims-triage-001"display_name: "Claims Triage Agent"persona: "Claims Triage Officer" # ALEA Pillar 1: Agent Personaowner_team: "Insurance Operations"business_owner: "Head of Claims"created: "2026-04-15"last_reviewed: "2026-05-01"identity:workload_identity: "claims-triage@svc.example-nz.govt.nz"cryptographic_signing: requiredcredential_rotation_days: 30spiffe_id: "spiffe://example-nz.govt.nz/claims-triage"capabilities:sensitive_data_access:- claims_database_read- customer_pii_readuntrusted_content_exposure:- email_inbox_readcommunication_channels:- internal_api_writelethal_trifecta_flag: truereview_cadence_days: 30permissions:granted:- role: claims_triage_readerscope: "claims-region-auckland"granted_date: "2026-04-15"granted_by: "head-of-claims"review_date: "2026-07-15"boundaries:max_decisions_per_hour: 50escalation_required_above: 25000human_review_triggers:- confidence_below_threshold- lethal_trifecta_path_activeaudit:logging_target: "central-audit-store"log_retention_years: 7immutable_hash_chain: enabledreasoning_chain_logged: trueipp_3a:indirect_collection_capable: truenotification_workflow: "ipp3a-notify-pipeline"third_party_sources_logged: requiredrevocation:method: "credential_revocation_and_workload_termination"rto_minutes: 5last_tested: "2026-04-20"The fields are not aspirational. Each maps to a specific control requirement. The workload identity field maps to NZISM v3.9 Section 16.1 authentication controls. Cryptographic signing addresses the EU AI Act Article 13 deployer interpretability requirement. The lethal_trifecta_flag operationalises Chapter 5's risk classification. The reasoning_chain_logged field connects to the Logic Logging discipline established in Chapter 10. The ipp_3a block is the architectural response to the 1 May 2026 commencement addressed in Chapter 9: it is not enough to have a notification policy in a document; the register must record which agents are capable of indirect collection and which workflow notifies the affected individual.
The architectural decision that determines whether this works is whether the register is the source of truth for identity assertions, or whether it sits adjacent to the actual workload identity provider. If the register is adjacent, it drifts. If the register is the source of truth, the workload identity provider reads from it. Google Cloud, Microsoft Azure, and AWS agent identity services are now structured to support this configuration.
Two operational fields warrant comment because they are consistently under-specified in early adopter implementations. The last_reviewed field is not a vanity timestamp. It is the audit anchor that demonstrates NZISM v3.9 Section 16.7 access review obligations are being met. An agent that has not been reviewed within its declared cadence should be automatically flagged. The last_tested field on the revocation block is the second. A revocation method that has never been exercised is documentation, not capability. Quarterly tested revocation across the highest-risk agents, those with the lethal_trifecta_flag set, is the minimum operational standard. ManageMyHealth's December 2025 incident response would have been faster if revocation paths had been pre-tested at the workload identity level.
A cultural classification field sits as a placeholder in register implementations that will carry Maori data sovereignty obligations. Part Three of this series (Chapters 14 to 17) introduces the Te Mana Raraunga governance overlay that gives that field its content. The operational identity infrastructure this chapter establishes is the foundation on which that governance layer builds.
The NZISM v3.9 Chapter 16 Horizon
NZISM v3.9, published 9 May 2025, contains the current authoritative identity and access control provisions for NZ government information systems. Three sections are directly relevant to agentic identity work today.
Section 16.1 sets authentication controls, updated to align with NIST guidance and the Department of Internal Affairs' Government Digital Identity Standards. Section 16.6 covers event monitoring, logging, and auditing, the upstream requirement that Chapter 10's Logic Logging discipline implements at the agent layer. Section 16.7 covers access review and audit, the periodic verification that granted permissions remain appropriate.
NCSC NZ has confirmed that NZISM v3.9 Chapter 16 is next in scope on its published roadmap. The exact scope and publication date have not been announced. Based on the NIST alignment language already present in v3.9 and the direction of the NZ Government Digital Identity Standards, the likely areas of update include passwordless authentication standards, MFA requirements for government systems, and phishing-resistant credential guidance.
For the EA practitioner, the planning implication is direct. Identity architecture work undertaken between now and the Chapter 16 update can either align with the documented direction of v3.9 or it can carry retrofit risk later. The path that aligns now, by adopting passwordless and phishing-resistant patterns today, is the only one that addresses the active threat surface from the NCSC March 2026 advisory, the operative notification obligation from Chapter 9's IPP 3A coverage, and the MCSS CS-CMM Level 2 baseline simultaneously. The path that waits leaves those obligations unaddressed in the interim.
The agentic asset register pattern aligns with this trajectory. Cryptographic signing aligns with phishing-resistant credentials. Workload identity aligns with NIST SP 800-63's identity assurance levels. Permission boundaries align with least privilege as a baseline rather than an aspiration. The register is forward-compatible by construction, provided it is established as the source of truth rather than a shadow record.
Vendor Lock-In as an Architectural Risk Class
On 28 April 2026, OpenAI models became available on AWS Bedrock in limited preview, with GPT-5.5, GPT-5.4, Codex, and Bedrock Managed Agents all accessible through Bedrock APIs. The structural significance for EA practice is that vendor lock-in for AI agents now operates at four distinct layers simultaneously.
The API dependency layer: which model APIs does the agent call?
The agent framework layer: which orchestration platform governs the agent's reasoning and action execution?
The data gravity layer: where do the agent's training and contextual data reside?
The cloud commitment layer: which cloud provider's economics underpin the cost structure?
Organisations that designed agentic workflows on the assumption of a single-cloud, single-model stack had an architectural assumption invalidated by a commercial announcement in seventy-two hours. The lesson is not specific to the vendors involved. It is that lock-in architecture is a permanent design concern, not a one-time procurement question.
The agentic asset register is the inventory that makes lock-in analysis possible. You cannot assess API dependency exposure or agent framework portability without a register recording which agents are operating, which APIs they call, and which orchestration platforms govern them. The four-layer analysis becomes a query rather than a workshop when the inventory exists.
For the next agentic procurement decision, three fields make this analysis operational: an API endpoint identifier, a framework runtime identifier, and a data residency assertion. Add those to the register and the lock-in question becomes a reporting task.
The Investment Case and the Regulatory Clock
ISC2's Zero Trust Certification Roadmap, published 29 April 2026, placed the cost differential between mature and immature Zero Trust deployments at US$1 million to US$1.76 million per breach, citing IBM and Ponemon research. The figure is the cost difference between deployment maturity levels, not the breach cost itself, and it is measured per breach, not per year.
For NZ practitioners, this investment case sits alongside three operative regulatory clocks.
The Minimum Cyber Security Standards' first reporting period closed on 30 April 2026, establishing a CS-CMM Level 2 baseline for mandated agencies' identity and access controls. Agencies that achieved Level 2 have the foundation for extending those controls to agentic workloads.
As Chapter 9 established, IPP 3A commenced on 1 May 2026, creating a notification obligation for indirect personal information collection. Without a register, demonstrating compliance is a manual exercise across every agent deployment.
NZISM v3.9 Chapter 16 is on the published roadmap as the next major identity-focused update. The period between now and that publication is, in planning terms, the least costly time to align identity architecture with the documented direction.
The compounding implication is direct. Identity architecture investment made in this period addresses an active threat surface, per the NCSC NZ March 2026 advisory; an operative compliance obligation, per IPP 3A; a measured baseline, per MCSS CS-CMM Level 2; and a publicly signalled regulatory direction, per the NZISM v3.9 Chapter 16 roadmap. The agentic asset register is the architectural pattern that responds to all four simultaneously.
A second international pattern reinforces this picture. Zscaler joined OpenAI's Trusted Access for Cyber programme on 16 April 2026, integrating GPT-5.4-Cyber into the Zero Trust Exchange. LLM endpoints, vector stores, and AI gateways are being placed behind Zero Trust policy enforcement in production today. According to Cyber360 research published in The Hacker News on 28 April 2026, 53 per cent of government, defence, and critical-services security leaders still rely on manual processes to move sensitive data between systems. The register and the Zero Trust integration pattern together close that gap for agentic data flows.
What to Do This Week
For NZ EA practitioners, the practical sequence is short.
First, list every AI workload in production: internal copilots, automated triage agents, chatbots with backend access, embedded model calls in business systems. The list does not need to be complete. It needs to exist by Friday.
Second, classify each entry against the Lethal Trifecta. Does it touch sensitive data? Does it ingest content from outside the trust boundary? Can it communicate beyond the originating system? Three affirmative answers means the agent goes to the top of the register queue.
Third, choose a register source of truth. The options are extending an existing CMDB, adopting the platform vendor's agent registry, or standing up a dedicated register tool. For most NZ organisations, extending the CMDB is the right starting point. The CMDB already has change governance, ownership records, and audit lineage. The agent register fields are an extension, not a replacement.
Fourth, exercise the revocation path on the highest-risk agent in the register. If revocation takes longer than the declared recovery time objective, the gap is documented before a real incident exposes it. If no revocation method exists, that agent should not be in production with its current credentials.
Fifth, log the IPP 3A position for every agent capable of indirect collection. The notification workflow does not need to be sophisticated at first. It needs to exist.
None of these five actions require Chapter 16 to publish, the EU AI Act to commence, or a vendor to release a new feature. They require a list, a classification, a source of truth, a tested revocation path, and a notification workflow. Most NZ organisations can complete the first three this week.
Where This Sits in the Architecture
Chapter 12 established Agent Identity as the Sixth Pillar. This chapter has shown what the register that operationalises that pillar contains. Chapter 26 returns to the Logic Firewall: the active enforcement layer that determines what registered agents are permitted to do at runtime. Knowing which agents are operating is the prerequisite for governing what they reason about.
V.E.R.A.'s external verification of agent reasoning operates outside the model under test. The agentic asset register provides the identity and permissions inventory that makes that external verification possible: you cannot verify what an agent reasons about if you do not know which agents are operating, what they are authorised to do, and what they have done.
For NZ EA practitioners working on identity architecture in the period before the NZISM v3.9 Chapter 16 update, the practical question is not whether to build the register pattern. It is which agents to register first and which existing CMDB or identity governance investments can be extended rather than replaced.
Start with the agents that combine all three Lethal Trifecta capabilities. They are the smallest population with the largest architectural exposure. If the register pattern holds for that population, it will hold for the rest.
What is the smallest agentic workload in your organisation that would benefit most from being the first entry in your agentic asset register?
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] Layer3. "NZ Threat Landscape 2026." 2026. layer3.co.nz
[2] NCSC NZ. "NZISM v3.9: New Zealand Information Security Manual." 9 May 2025. nzism.gcsb.govt.nz
[3] NCSC NZ. "Advisory: Social Engineering Targeting IT Helpdesks." March 2026. ncsc.govt.nz
[4] NCSC NZ. "Minimum Cyber Security Standards." 30 October 2025. ncsc.govt.nz
[5] Google Cloud. "2025/2026 Cloud and SaaS Security Reporting." 2026. cloud.google.com. Note: Primary source confirmation recommended before publication; cited via Layer3 NZ Threat Landscape 2026 in this article.
[6] Proofpoint. "Agent Integrity Framework 2026." March 2026. proofpoint.com
[7] Google Cloud. "Google Cloud Next 2026: Agent Identity, Agent Registry, and Agent Gateway Announcements." 22 April 2026. cloud.google.com
[8] European Union. "Regulation (EU) 2024/1689 (EU AI Act), Articles 9, 13, and 14." 2024. eur-lex.europa.eu
[9] Office of the Privacy Commissioner / Ministry of Justice. "Privacy Amendment Act 2025: Information Privacy Principle 3A." Commenced 1 May 2026. privacy.org.nz
[10] Department of Internal Affairs. "NZ Government Digital Identity Standards." 2026. digital.govt.nz
[11] NIST. "SP 800-63: Digital Identity Guidelines (Revision 4)." 2022. nist.gov
[12] ISC2. "Zero Trust Certification Roadmap." 29 April 2026. isc2.org. Note: Cost differential cites IBM Cost of a Data Breach and Ponemon Institute research; verify citation chain to primary sources before publication.
[13] Zscaler / SiliconANGLE. "Zscaler Joins OpenAI Trusted Access for Cyber Programme." 16 April 2026. siliconangle.com
[14] Cyber360 / The Hacker News. "Security Leaders and Manual Data Processes Research." 28 April 2026. thehackernews.com. Note: Exact 53 per cent figure recommended for primary source verification before publication.
[15] Amazon Web Services / OpenAI. "OpenAI Models on Amazon Bedrock: Limited Preview." 28 April 2026. aws.amazon.com