![\"Retail](\"https:\/\/dmsretail.com\/RetailNews\/wp-content\/uploads\/2022\/05\/RETAIL-ONLINE-TRAINING-728-X-90.png\")
<\/a><\/p>\n<\/p>\n
Part 2 in our series on workload security covers why knowing \u201cwho\u201d and \u201cwhat\u201d behind every action in your environment is becoming the most urgent \u2014 and least solved \u2014 problem in enterprise security<\/em><\/p>\n In\u00a0Part 1 of this series, we reached three conclusions: The battlefield has shifted to cloud-native, container-aware, AI-accelerated offensive tools \u2014\u00a0VoidLink\u00a0being the most advanced example \u2014 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.<\/p>\n But we left one critical thread underdeveloped: identity.<\/strong><\/p>\n We\u00a0called\u00a0identity \u201cthe connective tissue\u201d between runtime detection and operational response. Identity is becoming the\u00a0control plane<\/em>\u00a0for security, the layer that\u00a0determines\u00a0whether an alert is actionable, whether a workload is authorized, and whether your organization can answer the most basic forensic question after an incident:\u00a0Who did this, and what could they reach?<\/em><\/p>\n Part 1 showed that the workloads are where the value is, and the adversaries have noticed. <\/p>\n Part 2 is about the uncomfortable reality that our identity systems are unprepared for\u00a0what\u2019s\u00a0already here.<\/p>\n Every major attack examined in Part 1 was, at its core, an identity problem.<\/p>\n VoidLink\u2019s<\/strong>\u00a0primary\u00a0objective\u00a0is harvesting credentials, cloud access keys, API tokens, and developer secrets, because stolen identities unlock everything\u00a0else.\u00a0ShadowRay\u00a02.0\u00a0succeeded because the AI framework it exploited had no authentication at\u00a0all.\u00a0LangFlow\u00a0stored access credentials for every service it connected to; one breach handed attackers what researchers called a \u201cmaster key\u201d to everything it touched.<\/p>\n The pattern across all of these:\u00a0attackers\u00a0aren\u2019t\u00a0breaking in.\u00a0They\u2019re\u00a0logging in.<\/strong>\u00a0And increasingly, the credentials\u00a0they\u2019re\u00a0using\u00a0don\u2019t\u00a0belong to\u00a0people,\u00a0they belong to machines.<\/p>\n Machine identities now outnumber human identities 82-to-1<\/strong>\u00a0in the average enterprise,\u00a0according to Rubrik Zero Labs. They are the silent plumbing of modern infrastructure, created informally, rarely rotated, and governed by no one in particular.<\/p>\n Now add AI agents<\/strong>. Unlike traditional automation, AI agents make decisions, interact with systems, access data, and increasingly delegate tasks to other agents, autonomously.\u00a0Gartner projects\u00a0a third\u00a0of enterprise applications will include this kind of autonomous AI by 2028.<\/p>\n A recent\u00a0Cloud Security Alliance survey\u00a0found 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\u2019s actions back to the human who authorized it. And\u00a0nearly 80%\u00a0cannot tell you, right now, what their deployed AI agents are doing or who\u00a0is responsible for\u00a0them.<\/p>\n Every one\u00a0expands the potential damage of a security breach, and our identity systems were not built for this. <\/p>\n The security industry\u2019s answer to machine identity is\u00a0SPIFFE, and SPIRE,\u00a0<\/strong>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.\u00a0<\/p>\n Credentials that rotate automatically in minutes become worthless to malware like\u00a0VoidLink, which depends on stealing long-lived secrets. Services that verify each other\u2019s 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\u00a0immediately\u00a0attributable; you know\u00a0which<\/em>\u00a0service acted,\u00a0who<\/em>\u00a0owns it, and\u00a0what<\/em>\u00a0it should have been doing.\u00a0<\/p>\n These identity systems were designed for traditional software services, applications that behave\u00a0predictably and identically across every running copy. AI agents are fundamentally different.\u00a0<\/p>\n Today\u2019s\u00a0workload identity systems\u00a0typically\u00a0assign the same\u00a0identity to\u00a0every 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\u00a0often\u00a0share one identity\u00a0because\u00a0they\u2019re\u00a0treated as interchangeable replicas of the same service. This\u00a0works when every copy does the same thing. It\u00a0doesn\u2019t\u00a0work when each agent is making independent decisions based on different inputs and different contexts.\u00a0<\/p>\n When one of those twenty agents takes\u00a0an unauthorized\u00a0action, you need to know which one did it and why. Shared identity\u00a0can\u2019t\u00a0tell you that. You\u00a0can\u2019t\u00a0revoke access for one agent without shutting down all twenty. You\u00a0can\u2019t\u00a0write security policies that account for each agent\u2019s different behavior. And you\u00a0can\u2019t\u00a0satisfy the compliance requirement to trace every action to a specific, accountable entity.\u00a0<\/p>\n This creates gaps: You\u00a0can\u2019t\u00a0revoke a single agent without affecting the entire\u00a0service,\u00a0security policies\u00a0can\u2019t\u00a0differentiate between agents with different behaviors, and auditing struggles to trace actions to the responsible decision-maker.\u00a0<\/p>\n Standards could eventually support finer-grained agent identities, but managing millions of short-lived, unpredictable identities and defining policies for them\u00a0remains\u00a0an open challenge.\u00a0<\/p>\n There\u2019s\u00a0a second identity challenge specific to AI agents:\u00a0delegation<\/strong>.\u00a0<\/p>\n When you ask an AI agent to act on your behalf,\u00a0<\/em>the agent needs to carry your authority into the systems it accesses. But how much authority? For how long?\u00a0With what\u00a0constraints? And when that agent delegates part of its task to a\u00a0second<\/em>\u00a0agent, which delegates a\u00a0third<\/em>, who is accountable at each step? Standards bodies are developing solutions, but they are\u00a0drafts, not finished frameworks.\u00a0\u00a0<\/p>\n Three questions\u00a0remain\u00a0open:<\/p>\n In Part 1, we shared that\u00a0Hypershield\u00a0provides the same ground-truth visibility in containerized environments that security teams have long had on endpoints.\u00a0That\u2019s\u00a0essential, but alone, only answers\u00a0what<\/em>\u00a0is happening. Identity answers\u00a0who<\/em>\u00a0is\u00a0behind it,\u00a0and for agents, we need to know\u00a0why\u00a0<\/em>it\u2019s\u00a0happening.\u00a0That\u2019s\u00a0what turns an alert into an actionable response.\u00a0<\/p>\n Without identity, a\u00a0Hypershield\u00a0alert tells you: \u201cSomething made a suspicious network connection.\u201d<\/em>\u00a0With workload identity, the same alert tells you:\u00a0\u201cYour 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.\u201d<\/em>\u00a0\u00a0<\/p>\n Your team knows\u00a0immediately\u00a0what happened,\u00a0who\u2019s\u00a0responsible, and exactly where to\u00a0focus\u00a0their response, especially when threats like\u00a0VoidLink\u00a0operate at AI-accelerated speed.\u00a0<\/p>\n The foundation exists: workload identity standards like SPIFFE for machine authentication, established protocols like OAuth2 for human delegation, and kernel-level runtime security like\u00a0Hypershield\u00a0for behavioral observation.\u00a0What\u2019s\u00a0missing is the integration layer that connects these pieces\u00a0for\u00a0a world where autonomous AI agents\u00a0operate\u00a0across trust boundaries at machine speed.\u00a0<\/p>\n This is a\u00a0zero trust\u00a0problem.<\/strong>\u00a0The principles enterprises have adopted for users and\u00a0devices\u00a0must\u00a0now extend to workloads and AI agents. Cisco\u2019s own\u00a0State of AI Security 2026\u00a0report 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\u00a0gap\u00a0is a defining security challenge.\u00a0\u00a0<\/p>\n 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:<\/p>\n In Part 1, we said the battlefield shifted to workloads. Here in Part 2:\u00a0identity\u00a0is how you fight on that battlefield.<\/strong>\u00a0And in a world where AI agents are becoming a new class of digital workforce, zero trust\u00a0isn\u2019t\u00a0just a security\u00a0framework,\u00a0it\u2019s\u00a0the critical framework that protects and defends.<\/p>\n We\u2019d love to hear what you think! Ask a question and stay connected with Cisco Security on social media.<\/em><\/p>\n Cisco Security Social Media<\/mark><\/strong><\/p>\n LinkedInThe Attacks from Part 1 Were Identity Failures<\/h2>\n
The Machine Identity Explosion<\/h2>\n
What Workload Identity Gets Right \u2014 And Where It Falls Short\u00a0<\/h2>\n
Where It Breaks Down: AI Agents<\/h2>\n
The Delegation Problem No One Has Solved<\/h2>\n
\n
Identity Makes Runtime Security Actionable<\/h2>\n
The Path Forward: Zero Trust Must Extend to Agents<\/h2>\n
\n
\n
Facebook
Instagram<\/p>\n<\/p><\/div>\n