Summary
- IBM’s 2026 Cost of a Data Breach report found 68% of organisations lack governance to manage or detect shadow AI, up from 63% the prior year.
- Only 38% of organisations now require IT approval before deploying AI, down from 45% — meaning agents are entering infrastructure with little oversight.
- Treating agent identity as an extension of human IAM is a recognised mistake; industry bodies now recommend workload identity standards such as SPIFFE/SPIRE and WIMSE.
- DNS can serve as a policy enforcement layer for agentic AI, analogous to DMARC for email, blocking unauthorised connections mid-execution.
- Model integrity requires cryptographic signing, a verifiable bill of materials, and runtime attestation inside trusted execution environments — not just supply-chain controls.
An old problem, a new scale
Shadow IT has tested security teams for decades, but agentic AI raises the stakes considerably. Unlike a rogue SaaS subscription, an autonomous AI agent can hold credentials, spawn sub-agents, access regulated data, and take consequential actions — all without a human in the loop. IBM’s 2026 Cost of a Data Breach report found that 68 percent of organisations lacked governance to manage AI or detect shadow AI, up from 63 percent the year before. Simultaneously, the proportion requiring IT approval before AI deployment fell from 45 to 38 percent. The trend is moving in the wrong direction.
The credential problem hiding in plain sight
The instinct to bolt AI agents onto existing human identity and access management infrastructure is understandable but problematic. Human IAM was designed for a person at a keyboard who can tap an approval prompt on their phone. Agents cannot do that, so the fallback is a static API key — one that typically never expires and carries broader scope than necessary. As DigiCert’s senior vice president of product Brian Trzupek puts it, that is “the exact credential we’ve spent a decade telling people to get rid of.” Long-lived, over-scoped API keys effectively undo zero-trust architecture. Sub-agents compound the risk further: when a parent agent spawns a child, the child does not automatically inherit the same authorisation boundaries, creating delegation gaps that are difficult to audit.
What the standards bodies recommend
IDC now recommends treating agent identity as a workload identity problem, separate from human IAM. That position aligns with the IETF’s Workload Identity Management and Security Extensions (WIMSE) and NIST’s Cybersecurity Framework version 2.0. The practical implementation points to SPIFFE — the Secure Production Identity Framework for Everyone — and its SPIRE runtime, an open workload identity standard already deployed in many Kubernetes environments. Under this model, agents are governed workloads requiring runtime attestation and short-lived credentials, not pseudo-employees with service accounts.
Using DNS as a policy enforcement point
Inventory and identity provide visibility, but enforcement needs a chokepoint. Because every agent must resolve a DNS query before reaching an API endpoint or MCP server, DigiCert’s AI Trust framework proposes publishing agent policy records in DNS — analogous to DMARC records for email. Such a record would declare authorised agent identities, the certificate authority that issued their credentials, and permitted operational scopes. A gateway querying that record could terminate a session from an unrecognised agent or block a mid-execution connection to an unauthorised domain. IDC raises a valid concern about scale: as agent populations grow, stale records could become loopholes, and overly permissive scope declarations remain a risk. Trzupek’s response is that lifecycle automation — tying record expiry to certificate expiry — addresses the staleness problem, and that wildcard scopes are a discipline issue rather than an architectural one.
The AI Agent Passport concept
DigiCert’s proposed AI Agent Passport is a cryptographically protected record linking agent identity to its authorised systems, permitted operations, data sensitivity classifications, expiration state, and a named human owner. A single SPIRE server anchored to a certificate authority issues identity, while an Open Policy Agent engine enforces policy centrally — covering both internally built agents and third-party agents such as Microsoft Copilot or Salesforce Agentforce. Rather than replacing existing policy engines in AWS or GCP, the passport can hold pointers to those engines, which Trzupek describes as the pragmatic path for organisations with existing policy infrastructure.
Governing the models, not just the agents
Agents execute; models reason. Both require governance. The framework advocates encrypting and cryptographically signing model artefacts, packaging them to Open Container Initiative standards using tools like the Sigstore code-signing initiative, and maintaining a cryptographically verifiable model bill of materials that documents weights, datasets, and dependencies. At runtime, placing models inside trusted execution environments — Intel TDX or AMD SEV-SNP — keeps them encrypted in memory and isolated from the host operating system. DigiCert operates a confidential computing attestation service following the IETF Remote ATtestation Procedures (RATS) architecture, positioning a neutral third party as verifier rather than the cloud operator running the workload. For regulated sectors this matters acutely: in healthcare, for instance, cryptographic attestation can demonstrate that the algorithm approved through an FDA 510(k) pathway is the exact model running in clinical deployment.
Why it matters
CISOs are being asked to govern infrastructure they cannot see clearly. Agent populations are growing faster than policies to manage them, credentials are being issued in ways that contradict zero-trust principles, and the regulatory exposure — particularly in healthcare and finance — is concrete. The window to establish governance before agents become deeply embedded in enterprise workflows is narrow. Organisations that wait will inherit the same remediation costs they accumulated during the cloud era, only with a technology that can act autonomously and at speed.
What to do now
- Audit your environment for AI agents deployed without IT approval, including sub-agents spawned from tools such as Claude Desktop or OpenAI Codex.
- Stop issuing long-lived API keys to AI agents; move toward short-lived credentials aligned with workload identity standards such as SPIFFE/SPIRE and the IETF WIMSE framework.
- Evaluate DNS-based policy enforcement as a chokepoint for agent verification, including automated record lifecycle tied to certificate expiry.
- Require a named human owner, data sensitivity classification, and expiration date for every AI agent operating in your environment.
- Extend model governance beyond the supply chain to runtime: assess trusted execution environments and third-party attestation services for models handling regulated data.
- Review your SBOM practices to include a model bill of materials covering weights, datasets, and dependencies for AI systems in scope.
