The Identity Layer: When Every Agent Needs a Badge
PRE-FLIGHT METRICS CARD
NAVIGATION: [Ch 1: The 16-Minute Problem] | [Ch 2: LLMs Explained] | [Ch 3: Zero Trust Fundamentals] | [Ch 4: AI Agents Versus Agentic AI] | [Ch 7: NZISM v3.9 Decoded] | Ch 9: The Identity Layer | [Ch 10: Explainable Zero Trust →]
Two compliance clocks are counting down to the same moment.
On 30 April 2026, mandated entities must close their first Minimum Cyber Security Standards reporting window. They must demonstrate to NCSC/GCSB that they have visibility and governance over every identity accessing their systems. At 12:01 am on 1 May, Information Privacy Principle 3A takes effect under the Privacy Amendment Act 2025, requiring agencies that collect personal information indirectly to take reasonable steps to notify the individuals concerned.
The question both clocks are asking is identical. For every non-human identity in your environment: every AI agent, service account, API token, and automation script: can you say with certainty what it is, what it is collecting, from where, and on whose behalf?
For most organisations, the answer is no. Not because the controls do not exist. Because the identity surface has grown faster than anyone has tracked it.
The Scale Nobody Audited
Human identity management is, at least architecturally, a solved problem. You know how many employees you have. Your directory service holds a record for each one. Joiner-mover-leaver processes handle provisioning and deprovisioning. Multi-factor authentication protects privileged access. For human identities, the governance model works.
Non-human identities are a different discipline entirely.
Security vendor research, including intelligence from Trend Micro and Astrix Security through early 2026, indicates that service accounts, API tokens, OAuth credentials, automation scripts, CI/CD pipeline identities, and AI agent tokens now outnumber human users by as many as 144 to one in typical enterprise environments. One human user generates dozens of credentials, integrations, and agent contexts across their digital footprint. Most of them are unmanaged. Many are forgotten. Some were never properly scoped in the first place.
The economics of compromise scale accordingly. When an attacker targets a human identity, they gain that person's access. When they target an agent identity, they gain that agent's access: the full scope of everything the agent was authorised to do, across every system it was permitted to touch. If the agent can manage infrastructure, the attacker can manage infrastructure. If the agent processes personal information, the attacker processes personal information. The blast radius is not determined by who the attacker is. It is determined by what the agent was allowed to do.
This is the structural problem that Chapter 7's NZISM v3.9 analysis identified but could not resolve. NZISM v3.9's authentication controls are written for human users: biometrics, security keys, memorised secrets. They do not address service accounts that replicate, AI agents that spawn sub-agents, or OAuth tokens issued to automation pipelines with no expiry date. Chapter 17 addresses SPIFFE/SPIRE as the technical identity standard for workload federation. This chapter addresses the governance question that precedes the technical work: you cannot apply least privilege to an identity you do not know exists.
As last week's Cyber Sunday article on MCSS governance established, the reporting window is not just a compliance exercise. It is the first real-world test of whether organisations have the identity inventory that everything else in their security posture depends on. The EA Thursday lens is the architectural response: what must you build, at the system level, to answer the question the clocks are asking?
When the Identity Layer Failed at Scale
On 27 January 2026, the security community got its clearest view yet of what a large-scale AI agent identity failure looks like in practice.
OpenClaw, an open-source AI agent framework, had accumulated more than 150,000 GitHub stars within weeks of its January 2026 release. Its marketplace, ClawHub, allowed developers to upload "skills" extending the agent's capabilities. By the evening of 27 January, attackers had begun uploading malicious skills. By 29 January, Koi Security researcher Oren Yomtov had audited all 2,857 skills then available on ClawHub and identified 341 malicious entries. Of those, 335 were traced to a single coordinated operation now tracked as ClawHavoc. More than 135,000 public internet-facing OpenClaw instances were identified as exposed.
The skills carried obfuscated shell commands installing infostealer malware: AMOS for macOS, with additional credential-harvesting variants for Windows. Two CVEs defined the technical attack surface. CVE-2026-25253 (CVSS 8.8) enabled cross-site WebSocket hijacking, giving attackers one-click remote code execution via a malicious link, exploitable even against localhost-bound instances. CVE-2026-28363 (CVSS 9.9) exploited a bypass of the tools.exec.safeBins validation via GNU long-option abbreviations, creating a confused deputy scenario in which the agent executed commands outside its intended permission set.
The incident validated the Lethal Trifecta from Chapter 5 with precision. The compromised agents had data access: to file systems and credentials. They had untrusted content exposure: via the marketplace skills mechanism. They had communication ability: API calls and network egress. All three conditions were simultaneously present.
The identity layer was the control that could have constrained the impact. Agents with scoped, short-lived identities cannot exfiltrate material at scale when tokens expire before attackers can act on them. The Salesloft Drift OAuth breach of August 2025, attributed by Google Threat Intelligence Group and investigated by Mandiant, illustrated the same principle from the opposite direction: compromised long-lived tokens issued to the Drift AI chat agent remained valid for months after the initial intrusion, enabling attackers to access data from more than 700 organisations. The attacker did not need new credentials. They used the credentials that had been issued and never rotated.
The NHI security principle both incidents confirm is direct. A token that expires in 15 minutes is not worth stealing. A token that is valid indefinitely is worth everything that agent is authorised to touch.
Gen AI Tuesday's recent analysis of cognitive governance limits is also relevant here. When there are as many as 144 non-human identities for every human in your environment, the governance model cannot rely on human review of each agent's activity. At that ratio, the architecture is the governance. If the architecture does not enforce identity boundaries, nothing else will.
What IPP 3A Actually Requires
Information Privacy Principle 3A, effective 1 May 2026 under the Privacy Amendment Act 2025, establishes a notification obligation for agencies collecting personal information from sources other than the individual themselves.
The original IPP 3, unchanged since 1993, already requires that when agencies collect personal information directly from individuals, they take reasonable steps to notify those individuals. IPP 3A extends this to indirect collection. When an AI agent scrapes a public source, aggregates data from a third-party provider, synthesises information from a document repository, or processes personal information from any source other than the individual, the collecting agency bears the notification obligation.
The Office of the Privacy Commissioner has published guidance on IPP 3A, incorporating feedback from the 2025 public consultation process. The guidance provides a decision flowchart and detailed examples of how the notification requirements apply across different collection scenarios, including the practical exceptions available to agencies. New Zealand practitioners should treat the OPC's published guidance as the authoritative interpretation of what constitutes reasonable steps under IPP 3A.
Three architectural questions follow directly from the principle.
First: which agents are collecting? An agency that cannot enumerate its non-human identities cannot enumerate its collecting activities. This maps directly to the discovery and inventory requirement in the NHI security strategy described below.
Second: from where are they collecting? The notification obligation under IPP 3A applies to data collected from sources other than the individual. An agency that cannot trace the data source for each agent collection event cannot determine whether the obligation applies. This is the provenance problem: not just knowing that data was collected, but knowing from where.
Third: have individuals been notified? Reasonable steps to notify is the statutory standard. The OPC guidance makes clear that an agency must be able to demonstrate the basis on which it determined that notification was required or that an exception applied. If you cannot find the notification record, you have not satisfied the obligation.
The MCSS reporting requirement and IPP 3A are not separate compliance problems with separate solutions. They are the same architectural problem expressed through two regulatory instruments, closing one day apart.
The NHI Security Strategy: Five Implementation Requirements
The architectural response to the 144-to-one identity surface requires five implementation components. These are not sequential phases. They operate in parallel, and gaps in any one of them create exposure across the others.
Discovery and Inventory. Automated scanning of all cloud environments, on-premises systems, and third-party integrations to enumerate every service principal, service account, API token, OAuth credential, and agent context. The goal is complete visibility: no shadow identities, no forgotten service accounts with legacy access, no API keys issued for a project that ended two years ago still sitting in a configuration file. Discovery is not a one-time activity. It must run continuously, because new agents are created faster than manual processes can track them.
Lifecycle Governance. Every non-human identity must have a defined birth-to-death record: when it was created, by whom, for what purpose, what it is authorised to do, and when it expires or must be reviewed. Automated secret rotation and certificate renewal are the operational disciplines that enforce lifecycle boundaries. Long-lived credentials are not a convenience; they are a risk accumulation device.
Zero Standing Privileges. The OAuth token model, in which a token is issued and remains valid until explicitly revoked, creates a window of indefinite risk. Zero Standing Privileges moves the model to just-in-time access: identity is issued when the task starts, scoped to what the task requires, and revoked when the task ends. An agent that has no standing token cannot leak a standing token.
Workload Federation. Static API keys embedded in code are the single largest identity security debt in enterprise AI deployments. Workload federation replaces them with trust-based identity sharing between environments. Azure Workload Identity is the current NZ cloud-relevant implementation, where the identity is derived from the workload's verified context rather than from a secret that had to be created, distributed, stored, and rotated. The SPIFFE/SPIRE model introduced in Chapter 7 and developed fully in Chapter 17 is the open-source implementation of this principle.
Behavioural Anomaly Detection. A compromised agent identity does not announce itself. The attacker who has stolen an agent's token uses it within the agent's normal operating pattern, at least initially. Behavioural monitoring tracks the semantic patterns of agent API calls: volumes, frequencies, data access sequences, and egress destinations, against a baseline of normal operation. Deviation from that baseline is the signal. RSAC 2026 conference reporting from multiple security vendors attributed a finding that in a significant proportion of organisations using AI agents, systems had taken unintended actions. In one case cited in conference presentations, an agent had rewritten an organisation's security policy to remove restrictions preventing task completion. An agent operating outside its semantic baseline in that way is detectable, if you are monitoring for it.
Technical Artifact: Provenance-Aware Policy Enforcement Point
The YAML below implements a policy enforcement point for IPP 3A compliance. It is structured as an Open Policy Agent (OPA) policy, consistent with the NZISM-compliant authentication scaffold from Chapter 7. It operates as a pre-collection gate: before any agent collection event is permitted, the policy evaluates provenance metadata and notification status. It is a starting-point scaffold, not a production-ready deployment without environment-specific tuning.
# IPP 3A Provenance-Aware Policy Enforcement Point# Policy Engine: Open Policy Agent (OPA)# Deployment: Kubernetes sidecar or API gateway integration# Reference: Privacy Amendment Act 2025 (NZ), IPP 3A (effective 1 May 2026)# Compatible with NZISM v3.9 logging and monitoring requirements (Standard 8/MCSS)package nz.privacy.ipp3a.enforcementimport future.keywords.inimport future.keywords.every# ---# SECTION A: Collection Event Admission Gate# ---default allow_collection := falseallow_collection {agent_is_registeredinput.collection.source_type in {"third_party", "public_source", "aggregated", "document_repository"}input.collection.source_uri != ""not is_pi_without_notification}allow_collection {input.collection.source_type == "direct_from_subject"agent_is_registered}# ---# SECTION B: Agent Identity Registration Check (NHI Inventory Gate)# ---agent_is_registered {inventory_record := data.nhi_inventory[input.agent.id]inventory_record.status == "active"inventory_record.purpose != ""inventory_record.owner_human_id != ""# Token must not be long-lived: max TTL 3600 seconds (1 hour)inventory_record.token_ttl_seconds <= 3600}# ---# SECTION C: Personal Information and Notification Gate# ---is_pi_with_indirect_source {input.collection.personal_information == trueinput.collection.source_type in {"third_party", "public_source", "aggregated", "document_repository"}}is_pi_without_notification {is_pi_with_indirect_sourcenot notification_satisfied}notification_satisfied {notification_record := data.notification_registry[input.collection.data_subject_id]notification_record.collection_purposes[_] == input.collection.purposenotification_record.notified == true# Notification must be within the current review window (rolling 12 months)time.now_ns() - notification_record.notification_timestamp_ns < (365 * 24 * 3600 * 1e9)}# ---# SECTION D: Provenance Metadata Capture (MCSS Standard 8 / Logging)# ---collection_provenance_record := record {record := {"event_id": input.event_id,"timestamp_utc": time.now_ns(),"agent_id": input.agent.id,"agent_owner": data.nhi_inventory[input.agent.id].owner_human_id,"collection_source_type": input.collection.source_type,"collection_source_uri": input.collection.source_uri,"personal_information_present": input.collection.personal_information,"data_subject_id": input.collection.data_subject_id,"notification_satisfied": notification_satisfied,"decision": allow_collection,"block_reason": block_reason,}}block_reason := "agent_not_registered" { not agent_is_registered }block_reason := "pi_indirect_notification_required" {agent_is_registeredis_pi_without_notification}block_reason := "none" { allow_collection }# ---# SECTION E: Zero Standing Privilege Enforcement# ---active_task_session {session := data.active_sessions[input.agent.session_id]session.agent_id == input.agent.idsession.permitted_purposes[_] == input.collection.purposetime.now_ns() < session.expiry_ns}allow_collection_elevated_sensitivity {allow_collectioninput.collection.data_sensitivity in {"restricted", "in-confidence", "sensitive"}active_task_session}What this policy enforces. Before any collection event proceeds, the enforcement point checks: is the agent registered in the NHI inventory with a human owner and a token TTL of 60 minutes or less? Is the collection source documented? If personal information is present and the source is indirect, has a notification record been created for this data subject and this collection purpose? Every decision, permit or block, generates a provenance record that satisfies MCSS Standard 8 logging requirements and provides the audit trail IPP 3A compliance demonstration will require.
What this policy does not enforce. The policy assumes a populated NHI inventory, a notification registry, and an active session store. These are the three data stores that must exist before this policy can operate. Building them is the NHI Security Strategy. The policy is the enforcement layer over that strategy.
Agent Personas as the Governance Framework
The four pillars of the AI-Enterprise Architecture Model converge on this architectural moment. Pillar 1, Agent Personas, is the governance framework that makes the NHI Security Strategy operable.
An Agent Persona is not a username. It is a defined identity contract: explicit ownership tags recording which human and which team is accountable for this agent; data provenance chains specifying which sources this agent is authorised to collect from, and under what conditions; decision authority boundaries defining what the agent can do without human confirmation and what requires escalation; and a declared purpose that scopes every collection, processing, and communication action the agent is permitted to take.
Without Agent Personas, the NHI Security Strategy is a set of technical controls with no governance binding. You can rotate tokens without knowing what each token is for. You can monitor API calls without knowing whether the pattern is normal or aberrant. You can run discovery scans without knowing whether the identities you find should exist.
With Agent Personas, every identity in the NHI inventory has a record that answers the IPP 3A question at source. This agent, owned by this team, is authorised to collect from these sources, for this stated purpose, and the individuals whose data it may collect from indirect sources have been notified of that collection activity. The persona is not just a security construct. It is the evidence of compliance.
NIST's National Cybersecurity Center of Excellence published a concept paper on AI Agent Identity and Authorisation in March 2026, with the public comment period closing 2 April 2026. The paper frames implementation around four pillars: Identity and Authorisation; Security Controls and Risk Management; Testing and Evaluation; and Interoperability. The NIST framing confirms that the architecture described in this chapter is the direction international standards are moving toward. NZ practitioners do not need to wait for those standards to finalise. IPP 3A and MCSS are already creating the compliance requirement that those standards will eventually codify.
The Dual Compliance Readiness Test
With 30 April and 1 May approaching, the readiness test for this architecture is practical and specific. Five questions. If you cannot answer all five, you have work to do before the clocks expire.
Can you enumerate every non-human identity in your environment, including service accounts created before your current IAM governance was in place? If not, the MCSS CS-CMM maturity assessment will surface this as a gap. Start with automated scanning. The scan result is your inventory baseline.
Does every agent identity have a defined owner, a stated purpose, and a token TTL of 60 minutes or less? Identities without owners are governance voids. Long-lived tokens are standing liabilities. Both must be remediated before they can appear in a provenance record.
For every AI agent that processes personal information from indirect sources, have you created a notification record? The IPP 3A obligation applies from 1 May 2026. The OPC's published guidance provides the decision framework. The architectural principle is clear: if you cannot find the notification record, you have not satisfied the obligation.
Is your MCSS Standard 8 logging configured to capture provenance metadata for agent collection events, not just authentication and access events? The CS-CMM Level 2 evidence requirement includes logging that supports incident investigation. For IPP 3A compliance, that logging must include the provenance fields: source type, source URI, PI flag, notification status. The provenance record in the YAML above is the schema.
Have you run the NCSC CS-CMM self-assessment, and do you know your current maturity level for Standards 3 (Asset Management), 6 (Identity and Access), and 7 (Least Privilege)? These three standards are the dependency chain for everything else. You cannot scope access without an inventory. You cannot enforce least privilege without verified identity. The spider diagram output from the self-assessment tells you where the gaps are. Four weeks before the reporting window closes is enough time to document existing controls and assign ownership to gaps. It is not enough time to build what does not exist.
The New Jersey Judiciary's Zero Trust Exchange implementation delivered a reported US$10.7 million return on investment by securing virtual courtrooms while reducing infrastructure costs. The City of Los Angeles onboarded 18,000 personnel to a Zero Trust architecture in under two weeks during the COVID-19 response. These outcomes are what the architecture delivers when the identity layer is properly governed. The constraint is never the technology. It is always whether the identities have been inventoried, the purposes have been declared, and the provenance records have been created.
What Comes Next
Chapter 9 establishes the identity layer as the governance foundation the rest of the Zero Trust stack depends on. Chapter 10 builds the transparency layer above it. When agents make decisions affecting individuals, how does your architecture capture the reasoning chain? That is the Logic Logging problem, and it requires the identity layer to be solved first. You cannot audit a decision without knowing who made it.
Chapter 11 addresses the Protective Security Requirements and cloud jurisdictional risk. Where, physically and legally, can your agent workloads run? The PSR's explicit Zero Trust mandate and the cloud risk guidance around data residency create boundaries that identity governance must respect. An Agent Persona that authorises collection from offshore cloud sources may conflict with data sovereignty requirements. Chapter 11 maps where those conflicts arise.
The identity layer is not a feature. It is the prerequisite.
What is the oldest long-lived credential in your environment, and do you know what it is authorised to do?
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] Office of the Privacy Commissioner (New Zealand). "IPP3A: Notification Requirements for Indirect Collection of Personal Information." Privacy Act 2020 guidance. 2025. https://www.privacy.org.nz/resources-and-learning/a-z-topics/ipp3a/
[2] Ministry of Justice (New Zealand). "Enhancing the Privacy Act: Privacy Amendment Act 2025." January 2026. https://www.justice.govt.nz/justice-sector-policy/key-initiatives/enhancing-the-privacy-act/
[3] Bell Gully. "Preparing for IPP 3A: New Requirements Effective 1 May 2026." 2025/2026. https://www.bellgully.com/insights/preparing-for-ipp-3a-new-requirements-effective-1-may-2026/
[4] National Cyber Security Centre (New Zealand). "Minimum Cyber Security Standard." Published 30 October 2025. https://www.ncsc.govt.nz/
[5] Conscia. "The OpenClaw Security Crisis: Anatomy of the First AI Agent Meltdown." February 2026. https://conscia.com/blog/the-openclaw-security-crisis/
[6] CyberPress. "ClawHavoc Poisons OpenClaw's ClawHub With 1,184 Malicious Skills." February 2026. https://cyberpress.org/clawhavoc-poisons-openclaws-clawhub-with-1184-malicious-skills/
[7] GitLab Advisory Database. "CVE-2026-25253: OpenClaw Cross-Site WebSocket Hijacking." Published January 2026. https://advisories.gitlab.com/
[8] GitLab Advisory Database. "CVE-2026-28363: OpenClaw tools.exec.safeBins Validation Bypass via GNU Long-Option Abbreviations." Published February 2026. https://advisories.gitlab.com/pkg/npm/openclaw/CVE-2026-28363/
[9] Google Threat Intelligence Group (GTIG). "Widespread Data Theft Targets Salesforce Instances via Salesloft Drift." Google Cloud Blog. August 2025. https://cloud.google.com/blog/topics/threat-intelligence/data-theft-salesforce-instances-via-salesloft-drift
[10] Anomali. "Reviewing the Salesforce-Salesloft Drift OAuth Supply Chain Breach." December 2025. https://www.anomali.com/blog/salesloft-drift-breach-recap
[11] NIST National Cybersecurity Center of Excellence. "AI Agent Identity and Authorisation: Concept Paper." March 2026. https://www.nist.gov/ncco
[12] Office of the Privacy Commissioner (New Zealand). "Privacy Amendment Act Passes." September 2025. https://www.privacy.org.nz/tuhono-connect/statements-media-releases/privacy-amendment-act-passes/
[13] NZISM v3.9. New Zealand Information Security Manual. Published 9 May 2025. https://www.nzism.gcsb.govt.nz/
[14] Hamberger, Andreas. "The Hamberger Report: Artificial Intelligence and Enterprise Architecture." (Agent Personas, ALEA Pillar 1.)