When Five Governments Tell You to Slow Down
Return to Part 0: Table of ContentsPrevious Article: Chapter 16 - The Non-Human Identity Crisis
On 1 May 2026, six allied cyber agencies published a joint document on the careful adoption of agentic AI services. The agencies were the Cybersecurity and Infrastructure Security Agency, the National Security Agency, the Australian Signals Directorate's Australian Cyber Security Centre, the Canadian Centre for Cyber Security, the National Cyber Security Centre in the United Kingdom, and the National Cyber Security Centre New Zealand (NCSC NZ) as a named co-author.
Thirty pages. Five risk categories. Six governments aligned.
The five risk categories are privilege, design and configuration, behavioural, structural, and accountability. Privilege is listed first.
That ordering is deliberate. Privilege accumulation, agents acquiring permissions beyond what their assigned task requires and credentials persisting beyond the point when the task has ended, sits at the top of the list because it is the precondition for every other failure mode. An agent cannot exfiltrate data without access. It cannot corrupt a workflow without scope to do so. It cannot escape containment without credentials that travel farther than they should.
The previous chapter named the problem directly: non-human identities are multiplying at a pace that traditional identity and access management was never designed to govern. Service accounts, application programming interface tokens, AI agents, and automation scripts collectively outnumber human identities by ratios that make manual oversight cognitively unworkable. Chapter 16 argued that five questions should be answered before any agentic workload goes into production.
This chapter provides the technical foundation that makes those answers possible: a standard for issuing short-lived, cryptographically verifiable identity documents to agent workloads at runtime, based on what they are running and not merely where they are running.
That standard is Secure Production Identity Framework for Everyone, known as SPIFFE. The reference implementation is SPIFFE Runtime Environment, known as SPIRE.
What SPIFFE Is, and Why the Framing Matters
SPIFFE is a Cloud Native Computing Foundation graduated project. Graduated status means it has passed the CNCF's production-maturity threshold. AWS, Azure, and Google Cloud Platform all offer native SPIFFE/SPIRE support or SPIFFE-compatible workload identity tooling.
The name matters less than the design principle. SPIFFE answers a question that the identity architectures built around human users were never asked to answer: how do you establish the identity of a running workload when there is no human in the authentication loop?
Human identity systems resolve this through a credential: a password, a certificate, a biometric token. The human presents the credential; the credential is verified; access proceeds. This model has three properties we generally treat as fixed. The human exists before the credential is issued. The credential represents the human's authorisation. The human remains accountable for what happens during the session.
None of these properties hold for an AI agent executing autonomously.
An agent workload is created at runtime. It may not have existed five minutes ago. Its authorisation derives from the task it has been assigned, not from the identity of a human who logged in. Accountability for its actions, for accountability to mean anything, must be traceable to the specific workload instance that took the specific action at the specific time, not to the human who deployed the agent system in general.
SPIFFE addresses this by shifting identity from a credential-as-secret model to a credential-as-attestation model. Instead of issuing a long-lived API key that a workload can present anywhere, SPIFFE issues a SPIFFE Verifiable Identity Document at runtime, bound to the workload's attested properties, valid for a defined period, and automatically expiring when that period ends.
The SVID is not a password. It is a statement: this workload, running in this environment, with these characteristics, is authorised to act within this scope, until this time.
SVIDs: The Anatomy of a Runtime Identity Document
A SPIFFE Verifiable Identity Document takes one of two forms: an X.509 certificate or a JSON Web Token. The X.509 form is most common in production deployments, particularly for mutual Transport Layer Security service-to-service communication. The JWT form is used where HTTP header-based identity presentation is required.
Both forms carry the SPIFFE ID: a URI in the format spiffe://trust-domain/path. The trust domain identifies the administrative boundary the workload belongs to. The path identifies the workload within that boundary. A SPIFFE ID for an AI agent handling procurement approvals in a NZ public-sector organisation might look like:
spiffe://agency.govt.nz/agents/procurement/approval-processorThis ID is not a secret. It is a verifiable assertion of identity. What makes it secure is not that the ID is hard to guess; it is that the ID is cryptographically signed by a trusted Certificate Authority within the trust domain, short-lived (default SVID lifetimes in production deployments run from one to twenty-four hours; some implementations use lifetimes measured in minutes for high-sensitivity workloads), bound to the workload's attestation, and automatically rotated. SPIRE handles renewal before expiry without human intervention.
The practical consequence is significant. A compromised SVID provides access only for the remaining lifetime of the document. An attacker who extracts a short-lived SVID has a credential that expires in minutes or hours. An attacker who extracts a long-lived API key may have access for months or years, until someone notices and rotates it. As Chapter 16 noted, many organisations discover they cannot rotate quickly when it matters.
The five-country guidance's privilege category names persistent credentials as a specific risk vector. SVIDs address that risk at the credential architecture level: persistence is not a property the credential carries.
SPIRE: The Runtime Environment That Issues SVIDs
The SPIFFE standard defines what SVIDs are. SPIRE is the reference implementation that issues them.
SPIRE has two components: the SPIRE Server and the SPIRE Agent. The SPIRE Server is the trust anchor for a deployment. It manages the Certificate Authority that signs SVIDs, maintains the workload registry, and processes attestation requests from SPIRE Agents. There is one SPIRE Server per trust domain, typically deployed as a high-availability cluster in production.
The SPIRE Agent runs on every node where workloads that need SPIFFE identities execute. It attests the node to the SPIRE Server, then serves SVID requests from workloads on that node via the SPIFFE Workload API. When an AI agent process starts, it requests an SVID from the SPIRE Agent on its node. The SPIRE Agent verifies the workload's identity through node attestation and workload attestation, then presents the request to the SPIRE Server. The Server issues the SVID if the workload matches a registered entry. The SPIRE Agent delivers it to the workload.
This is the critical architectural point: the SVID is issued based on what the workload is, not what it claims. The workload does not authenticate to SPIRE by presenting a secret. The SPIRE Agent observes the workload's characteristics, its process identifier, its Kubernetes service account, its container image, its namespace, and verifies them against the registered entry. Identity is attested, not asserted.
The defence and government sectors reached this conclusion for human identity decades ago. The Personal Identity Verification credential and the Common Access Card, the US federal government's cryptographic authentication standards for human users, embed the same principle: identity must be cryptographically verifiable per transaction, not assumed from network location or session. New Zealand's RealMe service applies the same principle to citizen digital identity: the credential is machine-verifiable at each interaction, not trusted implicitly because the same person authenticated earlier. SPIFFE is the workload-identity equivalent of that principle for non-human actors. The defence and government sectors decided that human identity required cryptographic attestation. The agentic era requires the same conclusion for agent identity.
The Agent Registry as Pre-Condition
SPIRE cannot issue SVIDs to workloads it has not been told to expect.
This is the architectural step practitioners most commonly overlook. The SPIRE Server maintains a workload registry: a set of entries, each combining a SPIFFE ID with a set of selectors describing the workload's characteristics. Before a workload can receive an SVID, an entry for it must exist in the registry.
This creates a two-step deployment sequence that is architecturally sound and operationally demanding.
The first step is building the registry: every agent workload that will need a cryptographic identity must be enumerated, described, and registered before SPIRE can serve its identity needs. This is not a one-time exercise. Agent deployments in mature agentic enterprises are continuous; new agents are commissioned, updated, and decommissioned regularly. The registry must stay current.
Chapter 13 of this book established the agentic asset register as the governance pre-condition for all subsequent identity work. The SPIRE workload registry is the technical implementation of that governance concept. The asset register is the source of truth from which SPIRE registry entries are derived. If the asset register is incomplete, the SPIRE registry will be incomplete. If the SPIRE registry is incomplete, some workloads will operate without SVIDs: they will fall back to whatever credential mechanism they were using before SPIFFE adoption, which in most cases means a static API key or a long-lived service account token.
The governance decision is therefore not "deploy SPIFFE/SPIRE" in isolation. It is: maintain a complete and current agentic asset register, then enrol it in a trust domain. The first step is a governance programme. The second is a technical deployment.
New Zealand Information Security Manual v3.9 Section 16.1 requires automated identity and access management governance and continuous drift monitoring. Minimum Cyber Security Standards Level 2, for which the first reporting window closed 30 April 2026, requires asset metadata and configuration-as-code controls. Agentic workloads running on static credentials satisfy neither requirement adequately: the credential itself is static, the governance is manual, and the audit trail for what the credential was used for depends on application-layer logging rather than identity-layer attestation. SPIFFE/SPIRE closes both requirements at the architecture level.
Deploying SPIRE: Server and Agent Configuration
The following YAML provides a functional starting point for a SPIRE deployment covering an AI agent workload in a Kubernetes environment. This is a scaffold, not a production-ready configuration; environment-specific values (trust domain, node attestation method, Certificate Authority configuration) must be supplied.
# SPIRE Server Configuration# Reference: SPIFFE/SPIRE documentation (CNCF)# Deployment: Kubernetes with Helm chart (spire-helm)# Trust domain: replace agency.govt.nz with your organisation's domainserver:bind_address: "0.0.0.0"bind_port: "8081"trust_domain: "agency.govt.nz"data_dir: "/opt/spire/data/server"log_level: "INFO"ca_subject:country: ["NZ"]organisation: ["Agency Name"]common_name: "SPIRE Server CA"ca_ttl: "24h" # CA certificate lifetimedefault_svid_ttl: "1h" # SVID lifetime for standard workloads# Node attestation: Kubernetes SAT (Service Account Token)# Use when running on Kubernetes; alternatives: AWS IID, GCP GCENodeAttestor "k8s_sat" {clusters = {"production-cluster" = {service_account_allow_list = ["spire:spire-agent"]}}}KeyManager "disk" {keys_path = "/opt/spire/data/server/keys.json"}Notifier "k8sbundle" {namespace = "spire"config_map = "spire-bundle"config_map_key = "bundle.crt"}---# SPIRE Agent Configuration# Runs on every node; communicates with SPIRE Serveragent:data_dir: "/opt/spire/data/agent"log_level: "INFO"server_address: "spire-server.spire.svc.cluster.local"server_port: "8081"socket_path: "/run/spire/sockets/agent.sock"trust_domain: "agency.govt.nz"trust_bundle_path: "/run/spire/bundle/bundle.crt"NodeAttestor "k8s_sat" {cluster = "production-cluster"token_path = "/var/run/secrets/kubernetes.io/serviceaccount/token"}WorkloadAttestor "k8s" {# Verifies workload identity against Kubernetes metadataskip_kubelet_verification = false}WorkloadAttestor "unix" {# Additional attestation via process UID/GID for non-Kubernetes workloads}---# Workload Registry Entry# Register an AI procurement approval agent# Apply via: spire-server entry createworkload_entry:spiffe_id: "spiffe://agency.govt.nz/agents/procurement/approval-processor"parent_id: "spiffe://agency.govt.nz/ns/ai-workloads/sa/procurement-agent"selectors:- "k8s:ns:ai-workloads"- "k8s:sa:procurement-agent"- "k8s:container-image:registry.agency.govt.nz/ai/procurement-processor:v2.1.4"ttl: 3600 # 1-hour SVID; reduce to 600 (10 min) for high-sensitivitydns_names:- "procurement-approval-processor.ai-workloads.svc.cluster.local"admin: false # Non-administrative workload; cannot create entriesThree configuration decisions in this scaffold warrant explanation, because they are where deployment choices carry governance consequences.
The container-image selector in the workload registry entry binds the SVID to a specific image version. If the container image is updated without updating the registry entry, the workload will not receive an SVID. This is a feature: an unauthorised image cannot silently acquire a legitimate workload identity. Configuration management for SPIRE registry entries must be integrated into your container image pipeline.
The ttl field is the SVID lifetime. The one-hour default is appropriate for standard workloads. High-sensitivity workloads, those handling personal information subject to the algorithmic transparency requirement that took effect 1 May 2026, processing financial transactions, or operating under classified system requirements, should use shorter lifetimes. Ten-minute SVIDs are technically feasible and operationally workable with automated rotation; they reduce the exposure window for a compromised identity document to a period too short for most exfiltration scenarios to complete.
The admin: false field prevents the workload from creating or modifying SPIRE registry entries. Administrative capability in a SPIRE deployment should be confined to the pipeline processes that manage the registry, not granted to the workloads the registry governs.
Integrating SPIFFE with Existing Infrastructure
Most NZ organisations deploying SPIFFE/SPIRE will not be starting from a greenfield environment. They will be deploying SPIFFE alongside existing identity and access management infrastructure: Entra ID, Okta, AWS IAM, or Google Cloud IAM. The integration path is well-documented and does not require replacing existing systems.
The primary integration pattern is federation: the SPIRE trust domain federates with the organisation's cloud IAM provider, allowing SPIFFE SVIDs to be exchanged for cloud-native credentials. AWS supports this through IAM Roles Anywhere and IAM Identity Center's workload identity federation. Azure supports it through Workload Identity Federation in Entra ID. Google Cloud supports it through Workload Identity Federation for GKE and external workloads.
The practical result: an agent workload running in a Kubernetes cluster receives a SPIFFE SVID from SPIRE, then exchanges it for an AWS IAM role credential, an Azure Managed Identity token, or a Google Service Account key, without any static secret ever being stored or transmitted. The federation step is automated; the static secret is never created.
# Agent Identity Verification Flow# Pattern: SPIFFE SVID retrieval and AWS federation exchangeimport subprocessimport jsonimport boto3from typing import Optionalclass SPIFFEWorkloadIdentity:"""Retrieve SPIFFE SVID and federate to cloud IAM credential.Assumes SPIRE agent is running on same node with socket at/run/spire/sockets/agent.sock"""SPIRE_SOCKET = "unix:///run/spire/sockets/agent.sock"def get_svid(self) -> Optional[dict]:"""Retrieve current SVID from SPIRE agent via Workload API.Returns SVID as dict with x509svid and bundle fields."""try:result = subprocess.run(["spire-agent", "api", "fetch", "x509","-socketPath", self.SPIRE_SOCKET,"-format", "json"],capture_output=True, text=True, timeout=10)if result.returncode == 0:return json.loads(result.stdout)else:raise RuntimeError(f"SVID fetch failed: {result.stderr}")except Exception as e:# Log failure; do not proceed without identityraise RuntimeError(f"SPIFFE identity unavailable: {e}")def federate_to_aws(self,svid_jwt: str,role_arn: str,session_duration: int = 3600) -> dict:"""Exchange SPIFFE JWT SVID for AWS STS credentials.Requires IAM Roles Anywhere trust anchor configured forthe SPIRE trust domain."""sts = boto3.client("sts")response = sts.assume_role_with_web_identity(RoleArn=role_arn,RoleSessionName="spiffe-federated-agent",WebIdentityToken=svid_jwt,DurationSeconds=session_duration)return response["Credentials"]def get_cloud_credentials(self,role_arn: str) -> dict:"""Full flow: retrieve SVID, federate to AWS credentials.Raises if SPIFFE identity is unavailable: agent shouldnot proceed without verified identity."""svid_bundle = self.get_svid()jwt_svid = svid_bundle.get("svids", [{}])[0].get("jwt", "")if not jwt_svid:raise RuntimeError("No JWT SVID available for federation")return self.federate_to_aws(jwt_svid, role_arn)# Usage: at agent startup, before any resource accessif __name__ == "__main__":identity = SPIFFEWorkloadIdentity()try:credentials = identity.get_cloud_credentials(role_arn="arn:aws:iam::123456789012:role/ai-procurement-agent")print(f"Agent identity established. Credential expires: "f"{credentials['Expiration']}")except RuntimeError as e:# Identity unavailable: agent must not proceedprint(f"FATAL: Cannot establish agent identity. {e}")exit(1)The exit(1) in the failure path is deliberate. An agent that cannot establish a verified identity must not proceed. This is the protocol-level implementation of the five-country guidance's accountability category: if agent action cannot be attributed to a verified identity, the action must not execute.
The Compliance Convergence
The same SPIFFE/SPIRE deployment is consistent with requirements across three regulatory frameworks simultaneously, which is an unusual property for a technical architecture pattern.
NZISM v3.9 Section 16.1 requires automated identity and access management governance. SPIRE's automated SVID rotation and lifecycle management address this requirement for non-human workloads; manual secret rotation does not.
MCSS Level 2 requires asset metadata, configuration-as-code, and continuous drift monitoring. SPIRE's workload registry is configuration-as-code; the SVID issuance process generates per-workload audit records; SPIRE's node and workload attestation mechanisms detect configuration drift by design. A workload whose container image has changed will not match its registry entry and will not receive an SVID.
The EU's Network and Information Security Directive, NIS2 Article 21, requires supply-chain security measures including identity and access management for entities in scope. SPIFFE SVID cryptographic audit trails are aligned with the Article 21 accountability intent for workload identity, though the directive does not specifically endorse SPIFFE by name.
One architecture pattern closes all three gaps at the architecture level. This is not coincidental. The requirements converge because they are all responding to the same underlying gap: the absence of cryptographic identity verification for non-human workloads.
The CISA Zero Trust Maturity Model version 2 Identity pillar alignment is worth noting for NZ practitioners who reference CISA guidance as international context. The Identity pillar's maturity progression runs from traditional, characterised by manual identity governance and long-lived credentials, through advanced, which brings automated lifecycle management and just-in-time access, to optimal, which adds zero standing privileges and fully automated rotation. A SPIFFE/SPIRE deployment with short-lived SVIDs and automated rotation places a workload identity programme in the advanced tier. Combining zero standing privileges with SPIRE's workload attestation moves toward optimal. Both tier names should be verified against the current CISA ZTM v2 document at publication time; the names are drawn from the v2 structure per the researcher package.
The same progression describes where most NZ public-sector agentic workloads currently sit: in the traditional tier, operating on static credentials, with manual governance and no expiry management. SPIFFE/SPIRE provides the architecture path to advanced and optimal. That path has two steps: build the register, enrol it in a trust domain. Neither step is technically complex. Both require governance commitment.
Pope Leo XIV's first encyclical, Magnifica Humanitas, published 25 May 2026, articulates the philosophical case that technology must serve the human person and that humans must remain in command. The five-country guidance on agentic AI makes the same case architecturally: if agent action cannot be attributed to a responsible human, command has been ceded. Tuesday's Gen AI article explored this governance dimension at the organisational level. SPIFFE/SPIRE is the structural mechanism by which the human stays in command when agents act autonomously at the protocol level. Attribution is not a compliance checkbox. It is the technical pre-condition for accountability.
What to Do Before the Next MCSS Reporting Cycle
For NZ practitioners reading this in the first week of June 2026, the sequence has three steps.
Step 1: Verify your MCSS Level 2 submission included non-human workloads. If it did not, the next reporting cycle is the opportunity to close that gap. The SPIFFE/SPIRE deployment this chapter describes is the architecture that makes the Level 2 identity and access management governance requirements demonstrably met for agentic workloads.
Step 2: Run the agent registry inventory described in Chapter 13. The workload registry entries in the YAML above cannot be created until you know which agents exist and what their characteristics are. The inventory is the pre-condition; the SPIRE deployment follows from it. If you are starting from scratch, use the container image registry as the source of truth: every AI agent container image that is built or pulled is a candidate for a SPIRE registry entry.
Step 3: Choose your attestation method before deploying SPIRE. The Kubernetes Service Account Token attestation method in the configuration above is appropriate for Kubernetes-native deployments. AWS Identity and Access Management Instance Identity Document attestation is the right choice for EC2-hosted workloads. Azure Managed Identity attestation covers Azure virtual machine workloads. Google Cloud Compute Engine Instance Identity covers GCP compute. The attestation method is the foundation of the trust model; changing it after deployment requires re-registering all workloads. Choose once, deliberately.
The five-country guidance names five risk categories for agentic AI. Privilege is first because privilege is foundational: an agent that cannot accumulate permissions beyond scope, that operates on credentials that expire, and whose actions are attributable to a verified identity, is an agent whose other risk categories are materially constrained. SPIFFE and SPIRE are not a complete agentic security programme. They are the identity layer on which the remaining architecture rests.
The same principle that led the US Department of Defense and allied government agencies to require cryptographic verification for every human access event now applies to every agent action. The standard exists. The implementations are production-ready. The question is whether the governance programme to support them is in place before the second MCSS reporting cycle.
What does your current agentic credential estate look like? How many workloads in your environment are running on static API keys, shared service accounts, or long-lived tokens with no expiry date and no owner? And what is your plan for closing that gap before the next reporting window?
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] CISA, NSA, ASD ACSC, CCCS, NCSC UK, NCSC NZ. "Careful Adoption of Agentic AI Services." 1 May 2026. https://www.cisa.gov [specific URL to be confirmed at publication time]
[2] CNCF. "SPIFFE and SPIRE." Cloud Native Computing Foundation Graduated Project. https://www.cncf.io/projects/spiffe-and-spire/
[3] SPIFFE Project. "SPIFFE Concepts." https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/
[4] SPIFFE Project. "SPIRE Deployment Documentation." https://spiffe.io/docs/latest/deploying/
[5] NCSC NZ. "New Zealand Information Security Manual (NZISM) v3.9." Section 16.1. https://www.nzism.gcsb.govt.nz/
[6] NCSC NZ. "Minimum Cyber Security Standards (MCSS)." Cyber Security Capability Maturity Model Level 2. https://www.ncsc.govt.nz/
[7] CISA. "Zero Trust Maturity Model Version 2." https://www.cisa.gov/zero-trust-maturity-model [Tier names: traditional, advanced, optimal; verify against current v2 document at publication]
[8] European Parliament and Council of the European Union. "Directive (EU) 2022/2555 (NIS2 Directive)." Article 21. https://eur-lex.europa.eu
[9] Department of Internal Affairs NZ. "RealMe." https://www.realme.govt.nz
[10] NIST. "Federal Information Processing Standard (FIPS) 201: Personal Identity Verification (PIV) of Federal Employees and Contractors." https://www.nist.gov
[11] Pope Leo XIV. "Magnifica Humanitas." 25 May 2026. https://www.vatican.va [specific URL; exact wording verification flag remains open; paraphrased throughout]
[12] Amazon Web Services. "IAM Roles Anywhere." https://docs.aws.amazon.com/rolesanywhere/
[13] Microsoft. "Workload Identity Federation in Microsoft Entra ID." https://docs.microsoft.com/azure/active-directory/develop/workload-identity-federation
[14] Google Cloud. "Workload Identity Federation." https://cloud.google.com/iam/docs/workload-identity-federation
[15] Office of the Privacy Commissioner NZ. "Privacy Act 2020, Information Privacy Principle 3A." https://www.privacy.org.nz