Half 2 in our sequence on workload safety covers why realizing “who” and “what” behind each motion in your surroundings is turning into probably the most pressing — and least solved — drawback in enterprise safety
In Half 1 of this sequence, we reached three conclusions: The battlefield has shifted to cloud-native, container-aware, AI-accelerated offensive instruments — VoidLink being probably the most superior instance — particularly engineered for the Kubernetes environments; most safety organizations are functionally blind to this surroundings; and shutting that hole requires runtime safety on the kernel degree.
However we left one crucial thread underdeveloped: identification.
We referred to as identification “the connective tissue” between runtime detection and operational response. Identification is turning into the management aircraft for safety, the layer that determines whether or not an alert is actionable, whether or not a workload is permitted, and whether or not your group can reply probably the most primary forensic query after an incident: Who did this, and what may they attain?
Half 1 confirmed that the workloads are the place the worth is, and the adversaries have observed.
Half 2 is in regards to the uncomfortable actuality that our identification techniques are unprepared for what’s already right here.
The Assaults from Half 1 Have been Identification Failures
Each main assault examined in Half 1 was, at its core, an identification drawback.
VoidLink’s major goal is harvesting credentials, cloud entry keys, API tokens, and developer secrets and techniques, as a result of stolen identities unlock all the things else. ShadowRay 2.0 succeeded as a result of the AI framework it exploited had no authentication at all. LangFlow saved entry credentials for each service it linked to; one breach handed attackers what researchers referred to as a “grasp key” to all the things it touched.
The sample throughout all of those: attackers aren’t breaking in. They’re logging in. And more and more, the credentials they’re utilizing don’t belong to individuals, they belong to machines.
The Machine Identification Explosion
Machine identities now outnumber human identities 82-to-1 within the common enterprise, in keeping with Rubrik Zero Labs. They’re the silent plumbing of contemporary infrastructure, created informally, hardly ever rotated, and ruled by nobody specifically.
Now add AI brokers. Not like conventional automation, AI brokers make selections, work together with techniques, entry knowledge, and more and more delegate duties to different brokers, autonomously. Gartner initiatives a 3rd of enterprise purposes will embrace this sort of autonomous AI by 2028.
A latest Cloud Safety Alliance survey discovered that 44% of organizations are authenticating their AI brokers with static API keys, the digital equal of a everlasting, unmonitored grasp key. Solely 28% can hint an agent’s actions again to the human who licensed it. And almost 80% can’t let you know, proper now, what their deployed AI brokers are doing or who is liable for them.
Each one expands the potential injury of a safety breach, and our identification techniques weren’t constructed for this.
What Workload Identification Will get Proper — And The place It Falls Quick
The safety trade’s reply to machine identification is SPIFFE, and SPIRE, a normal that offers each workload a cryptographic identification card. Moderately than static passwords or API keys that may be stolen, every workload receives a short-lived, mechanically rotating credential that proves it’s primarily based on verified attributes of its surroundings.
Credentials that rotate mechanically in minutes develop into nugatory to malware like VoidLink, which depends upon stealing long-lived secrets and techniques. Providers that confirm one another’s identification earlier than speaking make it far more durable for attackers to maneuver laterally by means of your surroundings. And when each workload carries a verifiable identification, safety alerts develop into instantly attributable; you understand which service acted, who owns it, and what it ought to have been doing.
The place It Breaks Down: AI Brokers
These identification techniques have been designed for conventional software program providers, purposes that behave predictably and identically throughout each working copy. AI brokers are essentially totally different.
Immediately’s workload identification techniques usually assign the identical identification to each copy of an software when situations are functionally similar. When you have twenty situations of a buying and selling agent or a customer support agent working concurrently, they typically share one identification as a result of they’re handled as interchangeable replicas of the identical service. This works when each copy does the identical factor. It doesn’t work when every agent is making unbiased selections primarily based on totally different inputs and totally different contexts.
When a kind of twenty brokers takes an unauthorized motion, it’s good to know which one did it and why. Shared identification can’t let you know that. You can’t revoke entry for one agent with out shutting down all twenty. You can’t write safety insurance policies that account for every agent’s totally different habits. And also you can’t fulfill the compliance requirement to hint each motion to a particular, accountable entity.
This creates gaps: You can’t revoke a single agent with out affecting the complete service, safety insurance policies can’t differentiate between brokers with totally different behaviors, and auditing struggles to hint actions to the accountable decision-maker.
Requirements may ultimately assist finer-grained agent identities, however managing tens of millions of short-lived, unpredictable identities and defining insurance policies for them stays an open problem.
The Delegation Downside No One Has Solved
There’s a second identification problem particular to AI brokers: delegation.
Once you ask an AI agent to behave in your behalf, the agent wants to hold your authority into the techniques it accesses. However how a lot authority? For a way lengthy? With what constraints? And when that agent delegates a part of its activity to a second agent, which delegates a third, who’s accountable at every step? Requirements our bodies are creating options, however they’re drafts, not completed frameworks.
Three questions stay open:
- Who’s liable when an agent chain goes incorrect? For those who authorize an agent that spawns a sub-agent that takes an unauthorized motion, is the accountability yours, the agent developer? No framework offers a constant reply.
- What does “consent” imply for agent delegation? Once you authorize an agent to “deal with your calendar,” does that embrace canceling conferences and sharing your availability with exterior events? Making delegation scopes exact sufficient for governance with out making them so granular they’re unusable is an unsolved design drawback.
- How do you implement boundaries on an entity whose actions are unpredictable? Conventional safety assumes you may enumerate what a system must do and prohibit it. Brokers purpose about what to do at runtime. Limiting them too tightly breaks performance; too loosely creates danger. The suitable steadiness hasn’t been discovered.
Identification Makes Runtime Safety Actionable
In Half 1, we shared that Hypershield offers the identical ground-truth visibility in containerized environments that safety groups have lengthy had on endpoints. That’s important, however alone, solely solutions what is occurring. Identification solutions who is behind it, and for brokers, we have to know why it’s occurring. That’s what turns an alert into an actionable response.
With out identification, a Hypershield alert tells you: “One thing made a suspicious community connection.” With workload identification, the identical alert tells you: “Your inference API service, owned by the information science crew, deployed by means of the v2.4 launch pipeline, appearing on delegated authority from a particular person, initiated an outbound connection that violates its licensed communication coverage.”
Your crew is aware of instantly what occurred, who’s accountable, and precisely the place to focus their response, particularly when threats like VoidLink function at AI-accelerated pace.
The Path Ahead: Zero Belief Should Lengthen to Brokers
The muse exists: workload identification requirements like SPIFFE for machine authentication, established protocols like OAuth2 for human delegation, and kernel-level runtime safety like Hypershield for behavioral statement. What’s lacking is the mixing layer that connects these items for a world the place autonomous AI brokers function throughout belief boundaries at machine pace.
This can be a zero belief drawback. The ideas enterprises have adopted for customers and gadgets should now prolong to workloads and AI brokers. Cisco’s personal State of AI Safety 2026 report underscores the urgency: Whereas most organizations plan to deploy agentic AI into enterprise capabilities, solely 29% report being ready to safe these deployments. That readiness hole is a defining safety problem.
Closing it requires a platform the place identification, runtime safety, networking, and observability share context and may implement coverage collectively. That’s the structure Cisco is constructing towards. These are the sensible steps each group ought to take:
- Make stolen credentials nugatory. Substitute long-lived static secrets and techniques with short-lived, mechanically rotating workload identities. Cisco Identification Intelligence, powered by Duo, enforces steady verification throughout customers, workloads, and brokers, eliminating the persistent secrets and techniques that assaults like VoidLink are designed to reap.
- Give each detection its identification context. Figuring out a workload behaved anomalously will not be sufficient. Safety groups have to know which workload, which proprietor, what it was licensed to achieve, and what the blast radius is. Common Zero Belief Community Entry connects identification to entry selections in actual time, so each sign carries the context wanted to behave decisively.
- Convey AI brokers inside your governance mannequin. Each agent working in your surroundings ought to be recognized, scoped, and licensed earlier than it acts — not found after an incident. Common ZTNA’s automated agent discovery, delegated authorization, and native MCP assist make agent identification a first-class safety object slightly than an operational blind spot.
- Construct for convergence, not protection. Layering level instruments creates the phantasm of management. The challenges of steady authorization, delegation, and behavioral attestation require a platform the place each functionality shares context. Cisco Safe Entry and AI Protection are designed to do that work — cloud-delivered, context-aware, and constructed to detect and cease malicious agentic workflows earlier than injury is completed.
In Half 1, we mentioned the battlefield shifted to workloads. Right here in Half 2: identification is the way you battle on that battlefield. And in a world the place AI brokers have gotten a brand new class of digital workforce, zero belief isn’t only a safety framework, it’s the crucial framework that protects and defends.
We’d love to listen to what you suppose! Ask a query and keep linked with Cisco Safety on social media.
Cisco Safety Social Media
LinkedIn
Fb
Instagram
