Every AI agent you deploy is a user. It holds credentials, makes decisions, and touches systems. But unlike the humans on your team, it was never onboarded, never assigned an owner, and will almost certainly never be offboarded. That gap is now the fastest-growing security exposure in business technology — and almost nobody is measuring it.
We wrote recently about the state of the AI market and about why agentic AI is replacing traditional automation. This is the other half of that story: what happens after the agents are running.
80% of organizations have agents doing things they were not meant to do
That is not a projection. In 2026 reporting on agent deployments, four out of five organizations said their AI agents had taken actions beyond their intended scope. The specifics are worse than the headline.
Meanwhile 98% of companies plan to deploy more agents in the next twelve months. The exposure is compounding while the governance is standing still.
The number that reframes the problem
Security teams spend most of their identity budget on humans. But humans are no longer the majority of identities on your network — not remotely.
Estimates vary by methodology, and the spread is itself informative. The Cloud Security Alliance puts non-human identities at an average of 45 to 1 against human users, rising to 144 to 1 in cloud-heavy environments. GitGuardian’s 2026 analysis puts it at 80 to 1. Other vendors claim 100 to 1. Nobody agrees on the ratio, which tells you something important: most organizations cannot count their machine identities at all.
The governance numbers are more consistent, and bleaker:
| Finding | Share |
|---|---|
| Organizations with no clear ownership of AI identities | 51% |
| Non-human identities unchanged for over a year | 47% |
| Workforce using unapproved AI tools (shadow AI) | 45% |
| Organizations taking over 24 hours to revoke an exposed credential | 30% |
| Organizations with a formal API key offboarding process | 20% |
| Organizations confident they can prevent an identity-based attack on machine accounts | 15% |
| Non-human identities holding full administrative privileges | 1 in 20 |
Read the last two rows together. One machine identity in twenty has full admin rights, and only 15% of organizations believe they could stop an attack against those identities. That is the whole problem in two lines.
Prompt injection is now the number one risk on the OWASP LLM list
Traditional application security assumes code and data are separate things. Large language models collapse that distinction — to an LLM, instructions and content arrive as the same stream of text. That is not a bug anyone can patch. It is how the technology works, and it is why prompt injection holds the top position on the OWASP Top 10 for Large Language Model Applications.
There are three variants, and the dangerous one is not the obvious one.
- Direct injection — an attacker types malicious instructions straight into the agent. Easiest to imagine, easiest to defend.
- Indirect injection — instructions hidden inside content the agent reads on its own: an email, a PDF, a web page, a support ticket. Nobody attacks your agent; your agent simply reads something poisoned. This is the dominant enterprise pattern.
- Stored injection — malicious instructions written into the agent’s long-term memory or knowledge base, so the attack persists across sessions long after the original delivery.
These are not theoretical. The public record already includes Slack AI exfiltrating data via instructions planted in a public channel (2024); EchoLeak, a zero-click data-theft flaw in Microsoft 365 Copilot triggered by an ordinary email (2025); remote code execution in the Cursor IDE through a poisoned configuration (CVE-2025-54135); private repository access through malicious content in public GitHub issues; and memory-poisoning attacks that made an agent transfer assets based on false recollections it had been fed weeks earlier.
Notice what those have in common. In none of them did the attacker breach a network perimeter. They sent content an agent was designed to read.
Why a single leaked key is worse than it used to be
Machine credentials leak constantly. GitGuardian detected 29 million secrets on public GitHub in 2025, with AI-related secrets alone accounting for 1.27 million — an 81% year-over-year increase. Internal repositories are roughly six times more likely to contain hardcoded secrets than public ones, on the reasonable-sounding but false assumption that internal means safe.
The response window is brutal. When AWS credentials are exposed publicly, the average time before someone attempts to use them is 17 minutes. The fastest observed attempt was nine. Against that clock, the 30% of organizations that take more than a day to revoke a credential are not really responding at all.
Agents amplify this because they chain. The 2025 Salesloft-Drift incident showed the shape of it: one compromised OAuth token opened Salesforce environments belonging to a long list of downstream enterprises. The agent had legitimate access. The attacker just inherited it.
Your compliance certificate does not cover this
This is the part that surprises most business owners. SOC 2, ISO 27001, PCI DSS and NIST 800-53 all contain identity provisions — and none of them was written with agentic AI credentials in mind.
The practical consequence is that an organization can pass its audit cleanly while running an entirely ungoverned population of AI agents holding production credentials. The auditor asks about user access reviews. Nobody asks who owns the service account your scheduling agent authenticates with, when it was last rotated, or what happens to it when that agent is retired.
If you are pursuing SOC 2 or ISO 27001 right now, this is worth raising with your auditor before they raise it with you. The frameworks will catch up. Better to be early.
Six controls that actually close the gap
None of this requires an enterprise security program. It requires treating agents as what they are — users — and applying the discipline you already apply to people.
- Build a registry. One list: every non-human identity, its named human owner, its purpose, the systems it can reach, its privilege scope, and its expiry date. Most organizations cannot produce this, and producing it is usually where the surprises surface.
- Give every agent a named owner. Not a team — a person, accountable for defining the workflow, approving the permission scope, and revoking access when it ends. Ownership is the control that makes every other control enforceable.
- Adopt zero standing privilege. Just-in-time access scoped to a specific task with automatic expiry, rather than a permanent credential sitting in a config file waiting to be useful to somebody.
- Rotate on a short clock. Credential lifetimes measured in hours or days, with revocation pre-authorized so nobody has to convene a meeting during those seventeen minutes.
- Log prompt-to-action traceability. When an agent does something unexpected, you need to reconstruct which input caused it. Standard application logs will not tell you that.
- Give shadow AI a sanctioned path. Forty-five percent of your workforce is already using unapproved AI tools. Banning them drives usage underground where you cannot see it; offering an approved route with real credentials pulls it back into view.
The uncomfortable summary
The average organization went from about 5 AI agents in early 2025 to roughly 13 by April 2026. Almost none of them built identity governance at the same pace. What that produces is a population of privileged accounts that no one owns, no one rotates, and no one can revoke quickly — sitting inside an architecture where reading a malicious email is a viable attack path.
The good news is that this is an unusually tractable problem. It is not a technology gap; the tooling exists. It is an ownership gap, and ownership is free.
Frequently asked questions
What is a non-human identity?
Any credential that authenticates something other than a person: service accounts, API keys, OAuth tokens, certificates, CI/CD pipeline credentials, and the credentials AI agents use to reach your systems. They authenticate the same way a human account does, but usually with broader permissions and far less oversight.
Can prompt injection be fixed with better filtering?
Not reliably. Input filtering catches known patterns and misses novel phrasings, and because instructions and data share one channel in an LLM, there is no clean parser boundary to enforce. Effective defense is layered: capability-based architecture that limits what an agent can do regardless of what it is told, runtime monitoring of tool calls and data egress, and human approval on consequential actions.
We are a small business running two or three agents. Does this apply?
Yes, and the fix is proportionally smaller. Two or three agents means a registry you can write in a spreadsheet in an afternoon, and an owner for each. The organizations that get hurt are the ones that scaled to dozens of agents before anyone asked who owned them.
How do we find agent credentials we have already lost track of?
Start with your identity provider and cloud console: list every service account and API key, then work backwards to what created it and who still needs it. Scan your repositories for hardcoded secrets, including private ones. Anything you cannot attribute to a current, named business purpose should be rotated or revoked — and the safe way to find out whether something is still in use is to rotate it, not to leave it alone.
Getting ahead of it
Delana Technologies builds agentic AI systems and the Zero Trust architecture that keeps them contained. If you are deploying agents — or already have — call 239.414.5126 or contact us for an identity inventory. Most of what we find is fixable in weeks.
Sources: Cloud Security Alliance, “Non-Human Identity and Agentic AI Governance” whitepaper; GitGuardian, State of Secrets Sprawl 2026; Non-Human Identity Management Group, AI agent security review 2026; OWASP Top 10 for Large Language Model Applications; Sysdig, “Prompt Injection Attacks” technical guide, 2026.