Part 2 in our series on workload security covers why knowing “who” and “what” behind every action in your environment is becoming the most urgent — and least solved — problem in enterprise security
In Part 1 of this series, we reached three conclusions: The battlefield has shifted to cloud-native, container-aware, AI-accelerated offensive tools — VoidLink being the most advanced example — specifically engineered for the Kubernetes environments; most security organizations are functionally blind to this environment; and closing that gap requires runtime security at the kernel level.
But we left one critical thread underdeveloped: identity.
We called identity “the connective tissue” between runtime detection and operational response. Identity is becoming the control plane for security, the layer that determines whether an alert is actionable, whether a workload is authorized, and whether your organization can answer the most basic forensic question after an incident: Who did this, and what could they reach?
Part 1 showed that the workloads are where the value is, and the adversaries have noticed.
Part 2 is about the uncomfortable reality that our identity systems are unprepared for what’s already here.
The Attacks from Part 1 Were Identity Failures
Every major attack examined in Part 1 was, at its core, an identity problem.
VoidLink’s primary objective is harvesting credentials, cloud access keys, API tokens, and developer secrets, because stolen identities unlock everything else. ShadowRay 2.0 succeeded because the AI framework it exploited had no authentication at all. LangFlow stored access credentials for every service it connected to; one breach handed attackers what researchers called a “master key” to everything it touched.
The pattern across all of these: attackers aren’t breaking in. They’re logging in. And increasingly, the credentials they’re using don’t belong to people, they belong to machines.
The Machine Identity Explosion
Machine identities now outnumber human identities 82-to-1 in the average enterprise, according to Rubrik Zero Labs. They are the silent plumbing of modern infrastructure, created informally, rarely rotated, and governed by no one in particular.
Now add AI agents. Unlike traditional automation, AI agents make decisions, interact with systems, access data, and increasingly delegate tasks to other agents, autonomously. Gartner projects a third of enterprise applications will include this kind of autonomous AI by 2028.
A recent Cloud Security Alliance survey found that 44% of organizations are authenticating their AI agents with static API keys, the digital equivalent of a permanent, unmonitored master key. Only 28% can trace an agent’s actions back to the human who authorized it. And nearly 80% cannot tell you, right now, what their deployed AI agents are doing or who is responsible for them.
Every one expands the potential damage of a security breach, and our identity systems were not built for this.
What Workload Identity Gets Right — And Where It Falls Short
The security industry’s answer to machine identity is SPIFFE, and SPIRE, a standard that gives every workload a cryptographic identity card. Rather than static passwords or API keys that can be stolen, each workload receives a short-lived, automatically rotating credential that proves it is based on verified attributes of its environment.
Credentials that rotate automatically in minutes become worthless to malware like VoidLink, which depends on stealing long-lived secrets. Services that verify each other’s identity before communicating make it far harder for attackers to move laterally through your environment. And when every workload carries a verifiable identity, security alerts become immediately attributable; you know which service acted, who owns it, and what it should have been doing.
Where It Breaks Down: AI Agents
These identity systems were designed for traditional software services, applications that behave predictably and identically across every running copy. AI agents are fundamentally different.
Today’s workload identity systems typically assign the same identity to every copy of an application when instances are functionally identical. If you have twenty instances of a trading agent or a customer service agent running simultaneously, they often share one identity because they’re treated as interchangeable replicas of the same service. This works when every copy does the same thing. It doesn’t work when each agent is making independent decisions based on different inputs and different contexts.
When one of those twenty agents takes an unauthorized action, you need to know which one did it and why. Shared identity can’t tell you that. You can’t revoke access for one agent without shutting down all twenty. You can’t write security policies that account for each agent’s different behavior. And you can’t satisfy the compliance requirement to trace every action to a specific, accountable entity.
This creates gaps: You can’t revoke a single agent without affecting the entire service, security policies can’t differentiate between agents with different behaviors, and auditing struggles to trace actions to the responsible decision-maker.
Standards could eventually support finer-grained agent identities, but managing millions of short-lived, unpredictable identities and defining policies for them remains an open challenge.
The Delegation Problem No One Has Solved
There’s a second identity challenge specific to AI agents: delegation.
When you ask an AI agent to act on your behalf, the agent needs to carry your authority into the systems it accesses. But how much authority? For how long? With what constraints? And when that agent delegates part of its task to a second agent, which delegates a third, who is accountable at each step? Standards bodies are developing solutions, but they are drafts, not finished frameworks.
Three questions remain open:
- Who is liable when an agent chain goes wrong? If you authorize an agent that spawns a sub-agent that takes an unauthorized action, is the accountability yours, the agent developer? No framework provides a consistent answer.
- What does “consent” mean for agent delegation? When you authorize an agent to “handle your calendar,” does that include canceling meetings and sharing your availability with external parties? Making delegation scopes precise enough for governance without making them so granular they’re unusable is an unsolved design problem.
- How do you enforce boundaries on an entity whose actions are unpredictable? Traditional security assumes you can enumerate what a system needs to do and restrict it. Agents reason about what to do at runtime. Restricting them too tightly breaks functionality; too loosely creates risk. The right balance hasn’t been found.
Identity Makes Runtime Security Actionable
In Part 1, we shared that Hypershield provides the same ground-truth visibility in containerized environments that security teams have long had on endpoints. That’s essential, but alone, only answers what is happening. Identity answers who is behind it, and for agents, we need to know why it’s happening. That’s what turns an alert into an actionable response.
Without identity, a Hypershield alert tells you: “Something made a suspicious network connection.” With workload identity, the same alert tells you: “Your inference API service, owned by the data science team, deployed through the v2.4 release pipeline, acting on delegated authority from a specific user, initiated an outbound connection that violates its authorized communication policy.”
Your team knows immediately what happened, who’s responsible, and exactly where to focus their response, especially when threats like VoidLink operate at AI-accelerated speed.
The Path Forward: Zero Trust Must Extend to Agents
The foundation exists: workload identity standards like SPIFFE for machine authentication, established protocols like OAuth2 for human delegation, and kernel-level runtime security like Hypershield for behavioral observation. What’s missing is the integration layer that connects these pieces for a world where autonomous AI agents operate across trust boundaries at machine speed.
This is a zero trust problem. The principles enterprises have adopted for users and devices must now extend to workloads and AI agents. Cisco’s own State of AI Security 2026 report underscores the urgency: While most organizations plan to deploy agentic AI into business functions, only 29% report being prepared to secure those deployments. That readiness gap is a defining security challenge.
Closing it requires a platform where identity, runtime security, networking, and observability share context and can enforce policy together. That is the architecture Cisco is building toward. These are the practical steps every organization should take:
- Make stolen credentials worthless. Replace long-lived static secrets with short-lived, automatically rotating workload identities. Cisco Identity Intelligence, powered by Duo, enforces continuous verification across users, workloads, and agents, eliminating the persistent secrets that attacks like VoidLink are designed to harvest.
- Give every detection its identity context. Knowing a workload behaved anomalously is not enough. Security teams need to know which workload, which owner, what it was authorized to reach, and what the blast radius is. Universal Zero Trust Network Access connects identity to access decisions in real time, so every signal carries the context needed to act decisively.
- Bring AI agents inside your governance model. Every agent operating in your environment should be known, scoped, and authorized before it acts — not discovered after an incident. Universal ZTNA’s automated agent discovery, delegated authorization, and native MCP support make agent identity a first-class security object rather than an operational blind spot.
- Build for convergence, not coverage. Layering point tools creates the illusion of control. The challenges of continuous authorization, delegation, and behavioral attestation require a platform where every capability shares context. Cisco Secure Access and AI Defense are designed to do this work — cloud-delivered, context-aware, and built to detect and stop malicious agentic workflows before damage is done.
In Part 1, we said the battlefield shifted to workloads. Here in Part 2: identity is how you fight on that battlefield. And in a world where AI agents are becoming a new class of digital workforce, zero trust isn’t just a security framework, it’s the critical framework that protects and defends.
We’d love to hear what you think! Ask a question and stay connected with Cisco Security on social media.
Cisco Security Social Media
