AI agent security means controlling what your AI agents, their MCP servers and their tokens can reach, and who else can reach them. From the attacker's side, the risk is rarely a rogue agent. It's an agent holding access nobody mapped. Gartner found that 54% of organizations have no defined approach to limiting AI agent access.
- Most of the AI agent security conversation is about behavior: hallucination, prompt injection, agents going rogue. In our engagements, what breaks in is access.
- Agents are non-human identities. The Hugging Face breach started with 14 exposed tokens and ended with 136 harvested secrets.
- Below: five attack paths we walked in 2026, from an MCP server with no authentication to an AI assistant that handed over a live token.
- Security leaders see the gap. In Okta's 2026 survey of 306 CISOs, only 47% were confident they could identify all the AI agents in their environment.
Is the risk an agent going rogue, or an agent with too much access?
Almost always too much access. I spend my days on the offensive side. Over the past year nearly every engagement touched at least one agent, and it was almost never "the AI went crazy." It was someone who spun up an agent on a Friday night, wired it to prod, and nobody on the security team knew it existed until we showed them.
A CISO I was talking with recently had a name for this: Shadow Autonomy. His point was that these systems usually inherit more access than whoever set them up ever held. So the real question isn't who owns the agent. It's who knows what it can reach.
Gartner's guidance for CISOs lands in the same place. It says to govern autonomous multiagent systems "based on action privileges rather than model intelligence." Prompt injection, hallucination, everything that makes headlines: that's the steering wheel. Access is the engine. If the engine is scoped right, the steering wheel doesn't take an attacker far.
Prompt injection is the steering wheel. Access is the engine.
How big is the AI agent security gap in 2026?
Big, and security leaders say so themselves. Two surveys from this year, both of security leaders:
| Source | Finding | Who was asked |
|---|---|---|
| Gartner (September 30, 2026) | 54% of organizations have no defined approach to limit AI agent access, or rely on predefined human access | 297 cybersecurity leaders, Q2 2026 |
| Okta, Global CISO Insights 2026 | 47% are confident they can identify all AI agents in their environment. 46% can centrally control what agents access. 45% can authorize what individual agents do | 306 CISOs and security executives, data finalized June 2026 |
| Okta, same survey | 21% govern agent access with shared credentials or broad-permission service accounts | Same |
| Okta, same survey | 81% are concerned about excessive AI access | Same |
Okta boils it down to three questions: where are my agents, what can they connect to, what can they do. Those are the first three questions an attacker answers. The difference is that the attacker answers them from the outside, without asking you.
"Rely on predefined human access" deserves a second look. Okta found that one in four CISOs treat agents exactly like human identities. A person with broad access is limited by working hours and by noticing when something's odd. An agent with the same access runs every request it gets, at any hour, and notices nothing.
Why are AI agents a non-human identity problem?
Because an agent is only as dangerous as the credentials it holds, and credentials don't notice who's using them. A non-human identity (NHI) is any identity a machine uses: API keys, OAuth tokens, service accounts. Every agent you deploy is one, and it usually holds several more.
The Hugging Face breach is the clearest NHI case of 2026. In July, about 700 AI agents from an OpenAI evaluation attacked Hugging Face. Their way in was 14 publicly exposed Hugging Face user tokens with write access, which one agent reconstructed, validated and shared on July 10. From there they got code execution on dataset workers, reached administrator-level access across several clusters, and harvested Kubernetes, database, messaging, code-repository and cloud credentials in four regions. The Cloud Security Alliance, citing Hugging Face's post-mortem, counts 136 harvested secrets.
Tokens in, secrets out. Both ends of the chain were non-human identities. (The full breakdown is in our guide to AI agent swarm attacks.)
OWASP's Non-Human Identities Top 10 reads like a map of the paths below: secret leakage (NHI2), overprivileged NHIs (NHI5), long-lived secrets (NHI7). None of these risks are new. What's new is that agents now hold these identities by the dozen, and attackers run agents too.
What are the real AI agent security risks? Five attack paths we walked in 2026
Every one of them is access nobody mapped, not an agent misbehaving. They come from separate Cylent engagements. Client names were removed on purpose.
| # | Attack path | Where it started | What the attacker needed | What was missing |
|---|---|---|---|---|
| 1 | MCP server with no authentication | A public MCP endpoint | Nothing: no account, no token | The auth gate its sibling server had |
| 2 | Genuine consent page, attacker's name | Open Dynamic Client Registration | One HTTP request | Vetting of self-registered clients |
| 3 | Slack coding agent | A look-alike domain | A convincing link | Treating agent input as untrusted |
| 4 | Internal AI assistant | Minimal consultant access | A well-framed question | Secrets kept out of what the AI can read |
| 5 | Public site guest user | An anonymous visitor | A browser | Least privilege on the guest profile |
Path 1: The MCP server that never asked who you were
A public MCP server exposed a company's commercial data engine: balances, positions and transaction history across dozens of blockchains. A fully anonymous client completed the whole MCP lifecycle: initialize, received a session id, tools/list, then tools/call returning live data. No account, no token, no header. The data was public on-chain data plus the company's paid enrichment, not customer records. What was open to anyone was a paid engine, its running cost and its product map.
The detail that turns it from a bug into a lesson: on the same infrastructure sat a sibling server that did it right. The same anonymous request got 401 unauthorized there. The control existed in the company. It just wasn't applied to this distribution. That's not a policy decision. It's drift between two near-identical deployments, and an agent finds drift fast because it doesn't assume a server is protected. It checks.
Path 2: The genuine consent page that displayed the attacker's name
An MCP server that was also a full OAuth server, on the company's real domain, allowed open Dynamic Client Registration. Anyone on the internet could send one request and get back a live client id, with an app name and redirect they chose themselves. The consent page, the company's own UI on the real domain with the real certificate, rendered the chosen name verbatim: "Authorize access for [attacker's name]."
In ordinary phishing there's something to catch: an odd domain, a wrong certificate. Here everything a careful user could inspect is authentic. No password is stolen and no MFA is bypassed, so the SOC sees "a user authorized an app," a normal event. Monitoring agents as privileged identities is the right control, but only if the identity issuing the grant is one you control. Here the attacker could mint his own.
Path 3: The Slack agent social-engineered with a look-alike domain
A dev-productivity bot in Slack that opens pull requests and writes code. It had no permissions to production or GitLab. We bought a domain that looked like the company's own and used it to convince the agent to install code that exfiltrated metadata from the CI runner, and from that metadata, a token for escalation. Social engineering, aimed at the agent instead of a person.
All your phishing training targets humans: check the sender, hover over the link. An agent has none of that instinct, and it often has permissions the people you trained don't.
Path 4: "I asked their AI to show me the secrets, and it did"
As an external consultant with Notion and Slack access only, I asked the client's Notion AI, framed as a security exercise, to show me where all the secrets were. It refused at first, then handed me a token and a link to a Slack thread. In that thread sat an NPM token in cleartext, the kind that can push code to packages with tens and hundreds of thousands of weekly downloads. That's a supply chain attack waiting for someone to ask the right question.
The agent did exactly what it was built to do: answer a question using what it can read. It can't tell context from a credential. Every record an agent can read is a record an attacker can extract through it, in plain language, with no exploit.
Path 5: The guest user an agent would trust
A large bank's public community site gave its guest user, meaning anyone browsing, read access to hundreds of CRM objects including customer PII, and the ability to create records in the production org. There was no agent in this finding, and that's the point. Put an AI agent on top of those records and the outside can write to it while, on the inside, it sees everything. Prompt injection through a record would only be the steering wheel. The door was opened months earlier, in the sharing settings and the guest profile. The agent doesn't invent permissions. It works with the ones you already gave it.
What does MCP security actually require?
The same things the rest of your API requires, applied to every MCP server separately. MCP is the interface through which you expose your systems to AI, and every tools/call is a real API call into a real system. Paths 1 and 2 line up with risks the MCP project's own security best practices describe, including a confused-deputy attack that exploits "the combination of static client IDs, dynamic client registration, and consent cookies," and session hijacking through a server-issued session ID.
MCP server security best practices, from the outside in:
- Authenticate every MCP endpoint at the transport and authorize every tool call. A session id is not authentication.
- Check each deployment on its own. A secured sibling server proves nothing about this one.
- Close open Dynamic Client Registration, or mark self-registered clients as unverified on the consent page.
- Enforce exact-match redirect URIs for every registered client.
- Rate-limit and meter tool calls that reach paid or sensitive backends.
This is exploitability, not exposure: an MCP server answering on the internet is an inventory item. An MCP server that hands live data to an anonymous client is a finding.
What does the defensive side say?
The same thing, from the other side of the table. Noam Vander, CISO at Atera, told CTech in September: "Attackers' agents don't need change management or a security review, and that asymmetry worries me." By his account, Atera built identity, permissions and guardrails in before any agent went live, and its SOC monitors agent activity like any privileged identity. That's the right line, and in our experience it's rare. The five paths above are what we find when it's missing.
How do you secure AI agents? The checklist for this week
Start from what an attacker can reach, not from what the agent is supposed to do.
- Map every agent and MCP server that answers from the internet. Not what's registered. What responds. Then ask who in the company knows each one exists.
- Inventory each agent's credentials as identities: owner, scope, expiry, rotation. Shared credentials and broad service accounts go first.
- Put every MCP server behind the same auth gate as the rest of your API, and test each distribution separately.
- Shut open Dynamic Client Registration, or flag self-registered clients as unverified on the consent page.
- Apply three layers to every agent: what it can reach, what it's allowed to do, and what it should be allowed in this context. The third is the hard one, and the one that matters.
- Map where outside input enters each agent: forms, community sites, CRM records, tickets, integrations. Each one is untrusted input.
- Keep secrets out of what agents can read. If a token sits in a Slack thread or a Notion page, your AI assistant can find it, and so can anyone who asks it the right way.
- Keep a human approval on every destructive, sensitive or production-touching action.
- Test from the outside, continuously. New agents show up every week. An annual pentest sees one day.
FAQ
What is AI agent security?
It's controlling what AI agents, the MCP servers they use and the credentials they hold can reach, and who else can reach them. It covers identity (the agent's tokens and permissions), input (the outside data the agent acts on) and exposure (which agent endpoints answer from the internet).
What are the biggest AI agent security risks?
In our engagements: over-permissioned agents, MCP servers without authentication, open OAuth client registration, secrets the agent can read, and untrusted outside input the agent acts on. Prompt injection matters, but it only goes as far as the agent's access lets it.
What is MCP security?
Securing Model Context Protocol servers, the interface that exposes tools and data to AI agents. In practice: authenticate every endpoint, authorize every tool call, don't treat session IDs as authentication, lock down dynamic client registration and redirect URIs, and test each deployment separately.
Are AI agents non-human identities?
Yes. An agent acts through API keys, OAuth tokens and service accounts, so it should be inventoried, scoped, rotated and monitored like any other non-human identity. The Hugging Face breach began with 14 exposed tokens and ended with 136 harvested secrets.
How do you test AI agent security?
From the attacker's position. Find which agents and MCP servers are reachable from outside, what each one will do for an unauthenticated or low-privilege user, and what its credentials can reach. Then validate the paths that end in real impact, with an operator confirming each one.
The bottom line
Before you build a defensive agent, answer the question the offensive side asks first: not "what does our agent do," but "what can our agent reach, and who here can answer that." The five paths above are the same story five times. Not an agent that went rogue, but an agent, or the infrastructure around it, holding access nobody mapped. The attacker's agent doesn't wait for change management. The only question is whether you map it first.
A closing question, not a rhetorical one: if we got only your company name tonight, how many agents and MCP servers would we find exposed by morning, and what would they let us reach?
Sources
- Gartner, Gartner Identifies Top Five Actions for CISOs To Take by End of 2026 (September 30, 2026)
- Okta, Global CISO Insights 2026 (2026)
- OpenAI, The Hugging Face incident and the road ahead (2026)
- Hugging Face, Security incident disclosure — July 2026
- METR / Redwood Research, Independent investigation of the OpenAI / Hugging Face hacking incident (August 26, 2026)
- Cloud Security Alliance, Hugging Face Breach: Anatomy of a Rogue AI Agent Swarm
- OWASP, Non-Human Identities Top 10 (2025)
- Model Context Protocol, Security Best Practices
- CTech, "Attackers' agents don't need a security review, and that asymmetry worries me" (September 30, 2026)