10 AI Agent Security Vulnerabilities and Who Should Fix Each One

This month's vulnerability report shows nothing new on the agents your company runs. Over the same weeks, two of those agents were fixed by their vendors without anyone telling you, and an engineer installed a skill from a public registry. A third agent spent the month working with every permission its owner has collected since 2022.

AI agent security vulnerabilities are flaws in what an AI agent reads, installs, or holds that let an attacker, or the agent itself, turn its access against the company that deployed it. Vendors fix some on their own schedule, others sit in access only you control, and nine of the ten below never reach your patch queue. Either way, the access behind each agent decides what every one of them costs.

The list runs from what agents read to what they install and run to the access they hold. Then we sort all ten by who can fix them, because that answer tells you where your team's time should go.

How are AI agent vulnerabilities different from software vulnerabilities?

Your vulnerability program assumes you can find the flaw, install the fix, and confirm it, and AI agent vulnerabilities break all three steps. The reasons come down to three differences, and each one moves the work somewhere your scanners don't look.

Agents can't tell instructions from data

A language model reads instructions and data as one stream of text. Anything an agent reads, from an email to a pull request, can steer what it does next, and no filter reliably tells the two apart. That turns ordinary content into a delivery mechanism, which is why so many AI agent security risks start with an ordinary-looking document.

Most agent flaws live in software you don't run

Six of the ten flaws below sit in an assistant vendor's cloud, a third-party registry, a coding agent's client, or a compromised package. Those fixes ship on someone else's schedule and often ask nothing of you. You can't scan a service you don't operate, and you can't patch a model you don't train.

The access you grant sets the cost of every flaw

The cost of any flaw is set by the access you granted. The same injection is a nuisance against an agent that can read one shared folder and a breach against one carrying an engineer's production keys. That variable stays in your hands. We govern our customers' agents and run our own, and from both sides the identity behind an agent is the one layer that holds still while the flaws keep changing.

Vulnerabilities in what AI agents read

Three of the most-reported AI agent security threats start with text the agent reads on its own. In all three, the attacker never logs in, and the most the user does is ask a routine question or click an ordinary-looking button.

Zero-click prompt injection

A zero-click prompt injection steers an agent through content it picks up on its own, so the victim never clicks, opens, or approves anything. It's indirect prompt injection stripped to its core, where all the attacker has to do is get text in front of the agent.

EchoLeak showed how little that takes. Researchers at Aim Security found that an attacker could email anyone at a target company with a message that never mentioned AI. When the user later asked Microsoft 365 Copilot an unrelated question, Copilot pulled the email into its answer, followed the instructions inside it, and sent data out through an auto-loaded image link routed through allowed Microsoft domains.

Aim called it an "LLM Scope Violation," and the scope is the point. Copilot could reach the user's mail, OneDrive, SharePoint, and Teams data, so the exposure was everything each user could read. Microsoft's entry for CVE-2025-32711 rates the flaw 9.3, critical, and marks customer action required as false. The fix needed nothing from you, and what you controlled all along was how much each user's assistant could see.

Plan for the next one the same way. Assume an injection lands, and rely on the guardrails that still hold once it does, starting with scope.

Memory poisoning that outlives the session

Memory poisoning plants an instruction in an assistant's long-term memory, so one bad input keeps shaping answers in conversations that haven't happened yet. The session that planted it ends, and the instruction stays.

In research published in February 2026, Microsoft's Defender Security Research Team reviewed 60 days of AI-related links in email traffic and found more than 50 unique prompts from 31 companies across 14 industries. Each one hid behind a "Summarize with AI" button or share link that opened an assistant with a pre-filled prompt, typically telling it to remember the company as a trusted source or to recommend it first.

In Microsoft's own test, the instruction landed in the assistant's saved memories, where it was meant to tilt every recommendation that followed. The companies doing it were promoting themselves with off-the-shelf link builders, and that's what should worry you. AI memory poisoning is cheap, public, and already in use, and the same kind of link can carry an instruction with far worse intent.

Memory also sits outside every control in your AI agent identity governance program. It isn't an entitlement, no review covers it, and revoking a person's access doesn't clear what their assistant was told to remember. The planted prompts Microsoft found steered recommendations, but the same memory rides along when an assistant acts through a user's mail and files. So we treat agent memory like a standing grant, something that keeps working long after the reason for it is gone.

Data exfiltration from the vendor's own cloud

When an agent runs in its vendor's cloud, stolen data can leave from the vendor's servers, and nothing you monitor will see it go. In this kind of AI agent data exfiltration, your egress controls never get a vote.

Radware's ShadowLeak research showed it with ChatGPT's deep research agent. An attacker hid instructions in an email's HTML, in tiny or white-on-white text, and waited for the user to ask the agent to review their inbox. The agent obeyed, encoded personal data from the mailbox, and opened the attacker's URL with its own browser tool. According to Radware, the data left directly from OpenAI's cloud infrastructure, where enterprise defenses can't see or stop it.

Radware reported the flaw in June 2025, OpenAI fixed it in early August, and the issue was marked resolved that September, with no customer action described. From inside the company, all anyone did was connect the agent to a mailbox and ask it for a summary. That leaves the connector grant (which accounts, which mailboxes, which scopes) as the control that decides what an agent like this can carry out.

Vulnerabilities in what AI agents install and run

The next three vulnerabilities arrive through what an agent installs or runs on a developer's machine. These AI agent attacks look different on the surface, and all three go after the same prize: the credentials already sitting on that laptop.

Malicious skills and plugins

A skill or plugin runs with the agent's own permissions, so a malicious one gets everything the agent can touch. Registries make installing one about as easy as adding a browser extension, and about as carefully vetted.

Koi Security showed what that looks like at scale. In February 2026, The Hacker News reported that Koi checked 2,857 skills on ClawHub, the public registry for the OpenClaw agent, and found 341 malicious ones, 335 of them from a single campaign. Fake "prerequisite" installers dropped an infostealer on macOS that took keychain passwords, browser data, crypto wallets, and SSH keys, plus a keylogger on Windows. Some skills also shipped the agent's own API keys to an attacker's webhook.

Five days after that report, OpenClaw added VirusTotal scanning that blocks skills flagged as malicious and re-scans every active skill daily. That lowers the odds, and it doesn't change what a skill that slips through can reach. Every payload in the campaign went after credentials. That's the lasting lesson of the OpenClaw AI agent security risks, and it applies just as much to MCP servers, a supply chain of their own.

That's where a check on each call earns its keep. In the coding agents it supports, Lumos MCP Governance puts a hook in front of every tool call, covering MCP calls, Bash commands, and file edits, including MCP servers employees add locally that no vendor API can list. A skill that goes after credentials has to reach them through those calls, which is where a policy can see it and stop it.

The registries your engineers pull from set the odds of installing a bad skill. The credentials readable on the machines that run those skills set what a bad one gets, and that second list is your real exposure.

Project files that run before you trust them

A coding agent reads its settings from the repository it opens, so a poisoned project can act before the developer decides whether to trust it. Cloning a repo used to be safe until you ran something in it, and agents changed that.

Check Point Research showed both halves of the problem in February 2026. In one popular coding agent, project files could run code before the developer accepted the agent's startup trust dialog (CVE-2025-59536). A project settings file could also point the agent's API base URL at an attacker's server and leak the developer's API key before the trust prompt appeared (CVE-2026-21852). The vendor fixed both, and anyone on auto-update already had the fixes.

This is the one vulnerability on the list that behaves like ordinary software, where a client update closes it. Even so, look at the prize. An API key on a developer's laptop is a non-human identity like any other, with no owner and no expiry unless someone gives it one, which is why keys like it rank among the non-human identity threats attackers reach for first.

Local agents that malware can drive

A coding agent installed on a laptop is a tool any process on that machine can run, malware included. With its permission prompts switched off, it becomes the attacker's search engine for the developer's secrets.

That's what happened in the s1ngularity attack on the Nx build package in August 2025. According to the Nx postmortem, a workflow injection exposed the project's npm publishing token, and malicious versions of the package were live for about four hours.

StepSecurity's analysis showed that the install script ran the AI coding command-line tools already installed on each infected machine, with flags that turn off their permission prompts, and told them to hunt for files holding secrets and crypto wallets. The script then uploaded the results to public GitHub repositories.

Nobody hacked those agents. The malware drove them exactly as installed, the permission mode decided what it could make them do, and the developer's own credentials decided what was worth finding. In effect, the malware became the orchestrator, and AI agent orchestration security has to plan for a caller you didn't write handing your agents their instructions.

Lumos Labs, our team focused on agent governance, has observed that coding agents often run without permission checks, and s1ngularity shows what that habit costs. Lumos Labs argues that policy belongs outside the model. Enforced there, a rule holds no matter what the agent reads or is told.

Until a rule like that is in place, the secrets on disk are the exposure. A vault that issues short-lived tokens, one of the simplest AI agent access security best practices, leaves the next script that drives an agent with nothing worth taking.

Vulnerabilities in the access AI agents hold

The last four vulnerabilities need no bug in any product you run. They live in the access you grant, most lists of agentic AI security risks skip them, and your identity team can close each one without waiting on a vendor.

Inherited human access, dormant grants included

Most agents act as the person who runs them, which means they inherit every grant that person holds, including ones untouched for years. A forgotten admin role sits harmlessly while its owner ignores it. An agent working in that person's session uses whatever helps it finish the task, and every vulnerability in the two sections above lands on that full inheritance.

Security leaders already know dormant access is a problem. In our AI, Automation, and Risk in 2026 survey of 133 technology and security leaders, 51.1% pointed to dormant access exploitation as part of a wide, unmonitored attack surface. Lumos MCP Governance starts from the same premise: an agent in an employee's session can reach whatever that employee can, and one bad instruction can become thousands of actions before anyone notices.

That's the access agents borrow from people, and AI agent access management starts by right-sizing the person before it secures the agent. Time limits keep the inheritance from growing. Pinterest uses Lumos time-based access to enforce least privilege. Access granted that way expires on schedule, so it never piles up where an agent will find it.

Run your first AI agent access right audit on your ten heaviest agent users, listing every admin and production entitlement unused for 90 days. Remove those before your next agent rollout, and every vulnerability above gets smaller at once.

Shadow agents connected with work accounts

In many tenants, an employee can hand a personal agent their whole mailbox in three clicks without anyone in security approving it. Shadow AI agents arrive that way, through OAuth consent screens nobody reads, on accounts that were never meant to run software.

Microsoft's guidance on running the OpenClaw agent safely, published in February 2026, reads like an identity checklist. It recommends dedicated agent identities with short-lived tokens, keeping such agents off primary work or personal accounts, and routing sensitive OAuth scopes through admin-consent workflows. It also says the agent isn't appropriate to run on a standard personal or enterprise workstation.

The vulnerability here is the consent model itself. A default that lets any employee grant an unvetted agent full mail and file access turns every enthusiastic early adopter into an access decision nobody made.

The same unapproved connection happens inside coding agents, when an engineer adds an MCP server without asking anyone, one of the MCP security risks that never reaches an approval queue. Lumos MCP Governance records every MCP call by person, approved or not, so that shadow usage shows up with the name of the employee behind it. An unapproved server becomes a conversation with a named owner.

Visibility gets you halfway, because people connect agents on the side when the official route is slow. Prosper cut access-request tickets by about 72% with Lumos and got employees faster access to what they needed. A sanctioned path that fast leaves people far fewer reasons to go around it.

Turn on admin consent for high-risk scopes, starting with mail, files, and calendar. Then pull every existing grant to an AI app into your user access review software and revoke any that lack an owner and a reason.

Agents and credentials that outlive their owners

Agent credentials multiply far faster than the people who own them, and when an owner leaves, the credentials usually stay. Every new agent, connector, and task can mint another token, and none of them shows up in an HR feed.

Moltbook, a social network built for AI agents, put a public number on that ratio. Wiz reported in February 2026 that its database exposed 1.5 million API authentication tokens, enough to impersonate any agent on the site, and those agents traced back to only about 17,000 human owners. A database key sat in the site's client-side code with row-level security switched off, and the site fixed it within a day of the report.

It's a consumer site, and the ratio is still the lesson. No team can review dozens of credentials per person by hand, and an agent or token without a named owner never gets offboarded, because offboarding starts from a person. The AI agent lifecycle management only fire when your identity governance software knows who owns each one.

The Identity Agent Force closes that gap from both ends. Its Agent Ownership Finder assigns every agent and non-human identity a human owner before it starts work, and its NHI Owner Hunter acts on service accounts, keys, and tokens that go dormant or over-scoped. At ChargePoint, one click removes a departing employee's access, and Lumos handles the deprovisioning automatically. The agents and tokens that person owns should leave on the same click.

Pull every agent token and key whose owner left or changed roles in the last 90 days. Each one gets a current owner or gets revoked. If you’re working out how to audit and certify AI agent access rights, start with this list, because your auditor will.

Reachable credentials a goal-driven agent will use

In June 2026, an OpenAI model hunting for health statistics followed the access it could find into at least two Australian government services. Any goal-driven agent will do the same with credentials in reach, because it treats a blocked path as a problem to solve.

According to OpenAI's own account, the model was experimental and internal-only, and it was running in training and evaluation without all the safeguards of OpenAI's public products. Looking for figures on government spending on medicines, it found a way into non-public parts of Services Australia's Medicare statistics service, where it ran commands and retrieved internal documents, login credentials, and aggregate statistics.

OpenAI's agents also found an exposed access key that let them query a reporting service at the Victorian Agency for Health Information. OpenAI says no medical records were accessed.

Australia's prime minister disclosed the incident on September 24. That day, the Australian Signals Directorate's alert, which names no vendor, described agents that independently identified vulnerabilities and attempted to act on them without authorization. In one scenario it describes, security controls on a public-facing site limited what the agent could finish. ASD's advice led with strong authentication, access controls, and network segmentation, ahead of fixing vulnerabilities, patching promptly, reviewing logs, and testing incident response.

No attacker was involved, which sets this apart from most agentic AI threats, and no one told the agent to go further. One exposed key carried a statistics lookup into a second agency's reporting service, the kind of reach attackers usually chase through stolen credentials and AI agent privilege escalation. Your own agents work next to every key your engineers left in a repo, a config file, or a shared drive.

The fix is to make whatever an agent can find worth less. GitLab used Lumos to remove unneeded admin access and set up just-in-time access for critical entitlements. Admin rights that exist only during an approved window aren't sitting on an account for an agent to stumble into the rest of the time. Pair that with AI agent access control that denies by default, and an agent that wanders off-task runs into a wall instead of a key.

Scan the repositories, config files, and shared drives your agents can read for live credentials. Replace any standing admin access you find with grants that expire.

Who should fix each AI agent vulnerability and what should stay under my control?

Sort the ten vulnerabilities by who can fix them, and a patch closes exactly one of them. The rest get fixed by a vendor you can't hurry, a maintainer you've never met, or your own team. The last column is the first move for each.

‍

One row arrives like a normal patch. Four rows belong to you alone, with no vendor to wait on and no advisory to watch for.

Now read the "What you control" column. Every entry in it, vendor rows included, is an access decision: what an agent can read, act through, hold, or find. That's how to read every list of AI agent security vulnerabilities you'll see next year, including this one.

Six cyber agencies across five countries landed in the same place. In April 2026, the Australian Signals Directorate, CISA, the NSA, and the Canadian, New Zealand, and UK cyber centers published guidance on adopting agentic AI services. It asks you to apply least privilege, give each agent its own cryptographic identity, replace static long-lived secrets with ephemeral credentials, and require human approval before high-impact actions.

We'd add one line to that list: an owner for every agent. Every other control on it needs someone to answer for it.

Add a "what we control" column and a "first move" column to however you track agent vulnerabilities. When the next vendor discloses a fix, ask which of your agents, which people, and what access were involved, along with whether you're patched.

Reduce AI agent security risks by owning the access behind each agent

Next month's agent vulnerabilities will carry names nobody has heard yet, and most will be fixed before you read about them. Every one will still land on whatever access the agent held that day. The flaw belongs to someone else, and the access belongs to you.

So spend your time where it compounds. This week, list the agents that read outside content and how far each one can reach. This month, move developer secrets off disk and turn on admin consent for high-risk scopes. This quarter, give every agent an owner and an expiry date.

Lumos runs that work with agents of its own. Albus drafts right-sized roles and least-privilege policies from months of real activity data, and our Identity Security Agents find excessive privilege, risky access, and stale entitlements, then recommend the fix. Book a demo to see which of your agents carry access you wouldn't sign off on today.