The shadow identity crisis: Who let the agents in?

Every enterprise security leader is living through the same experiment right now, whether they chose it or not. Over the past year, AI agents have moved from chat windows into the machinery of the business itself. They open pull requests, query production databases, draft and send emails, and reach into internal tools through frameworks like the Model Context Protocol, which has become the standard way of wiring language models into corporate systems. Cisco's State of AI Security 2026 research captures the scale of this shift: 83% of organisations surveyed planned to deploy agentic AI capabilities into their business functions, yet only 29% felt truly prepared to do so securely. That gap between ambition and readiness is where the next generation of breaches will come from.

Earlier this year, SOFTSWISS outlined its vision of AI becoming embedded across the organisation rather than existing as a standalone productivity tool. The deeper AI becomes integrated into everyday workflows, the more important it becomes to treat AI identities with the same discipline as human ones to prevent a shadow identity crisis. We have spent the past decade building identity and access management around the assumption that the entities touching our systems are either people or well-understood service accounts, both of which can be vetted, trained, and monitored. However, AI agents completely break that premise. 

Give an AI agent a task, and it walks away with API keys, database credentials, and standing access to internal tools, which often amount to much more than what we would hand a human contractor on day one. It is the equivalent of giving a new temp the master key, the finance password, and the customer files before they have filled out a single form. No interview, no reference check, no ninety-day period where someone watches how it handles judgment calls.We have effectively hired a new class of worker and skipped every control we built for exactly this purpose.

What makes this especially dangerous is the mechanism called indirect prompt injection, which deserves more attention from boards than it currently gets. Unlike a phishing email that targets a person's judgment, this attack hides malicious instructions inside the content an agent is already trusted to process: a support ticket, a webpage, a code comment, an email in an inbox the agent has been asked to summarize. The agent cannot reliably tell the difference between an instruction from its legitimate user and one smuggled in through the data it is reading. 

Security researchers have already documented this moving from theory into practice. A Model Context Protocol server connected to GitHub was manipulated through a malicious issue that hijacked an agent's behavior and triggered the exfiltration of data from private repositories. That is precisely why indirect prompt injection should be viewed as a governance issue, rather than just a technical one.

What should concern security leaders most is the blast radius. Traditional software vulnerabilities tend to have boundaries. A flaw in one application does not usually hand an attacker access to the email system, the finance database, and the customer support queue simultaneously. Agentic AI is designed to erase those boundaries by intention, because the entire value proposition is an agent that can browse, query, write, and act across many systems on our behalf. That same design that makes agents useful is what makes a single successful injection so costly. One compromised agent with broad tool access does not produce one bad outcome. It produces a cascade of authorized-looking actions across every system that agent was trusted to touch, and the industry's own data breach research shows the cost of that exposure landing well into the millions when access controls are absent.

There is also a newer wrinkle that most Zero Trust conversations have not caught up to yet: agents increasingly talk to other agents, not just to humans. A research agent that has been  poisoned can pass tainted output downstream to a financial or operational agent, which then acts on instructions it never should have trusted. The identity threat is no longer confined to human credentials and service accounts. It now includes the implicit trust agents extend to one another, often without any human in the loop to catch the handoff going wrong.

None of this is an argument against deploying AI agents. In an industry like ours, where real money moves in real time across jurisdictions and there is no such thing as a quiet shift, the operational case for automation is not going away, and it should not. The argument is that we cannot keep treating agents as trusted employees while withholding the controls we would never skip for an actual employee. 

Zero Trust was built on the principle that trust is never assumed and always verified, continuously, regardless of where a request originates. That principle has to extend to non-human identities with the same rigor: least-privilege access scoped tightly to what a given task requires, credentials that expire rather than persist indefinitely, behavioral monitoring that flags an agent acting outside its normal pattern, and clear ownership for every agent's lifecycle from provisioning to retirement, the same way we would track a departing employee's access.

None of this means slowing AI adoption down. It means treating agent identity with the same seriousness that we assign human identity, rather than simply bolting it onto an IAM program that was never built for a workforce that runs around the clock. We are handing these agents access because they make us faster. Whether that access ends up working for us or against us comes down to whether anyone is watching closely enough.