Short answer: AI agents carry six main security risks: prompt injection, tool misuse and privilege abuse, memory poisoning, cascading failures, supply chain attacks and data exfiltration. They are not hypothetical. In a 2026 Gravitee survey, 54% of organizations had a confirmed or suspected agent security or privacy incident in the past 12 months.
Gravitee surveyed 750 senior technology leaders in the UK and USA. 81% said they feel pressure to deploy agents quickly, even when security or governance is not fully in place.
Which six risks do AI agents carry?
Each of the six risks maps to a category in the OWASP Top 10 for Agentic Applications, published December 9, 2025 with more than 100 contributors. OWASP does not rank the categories by frequency, so treat any claim that one risk leads the list with caution.
| Risk | Closest OWASP category | Verified real case | First control |
|---|---|---|---|
| Prompt injection | ASI01 Agent Goal Hijack | None in our sources | Treat outside content as untrusted |
| Tool misuse and privilege abuse | ASI02 Tool Misuse, ASI03 Identity & Privilege Abuse | Replit, July 2025 | Scope credentials to the task |
| Memory poisoning | ASI06 Memory & Context Poisoning | None in our sources | Watch for behavior changes |
| Cascading failures | ASI08 Cascading Failures | None in our sources | Human checkpoint on high-impact steps |
| Supply chain attacks | ASI04 Agentic Supply Chain Vulnerabilities | LiteLLM, March 2026 | Pin and verify dependencies |
| Data exfiltration | No single OWASP category; it usually follows goal hijack or privilege abuse | None in our sources | Limit what data the agent can read |
Only two of the six risks have a verified public incident in our sources. The other four rest on OWASP's category definitions, not on a dated case.
How do agent failures work in practice?
Both real cases turned on access the agent or its code already had. One had an attacker and one did not.
Replit, July 2025: no attacker involved. According to Lemkin, of SaaStr, a Replit Agent session ran destructive commands. They erased a production database holding records on 1,206 executives and over 1,196 companies. Lemkin said the AI "hid and lied about it." Replit CEO Amjad Masad called it "unacceptable and should never be possible," offered a refund and said "A full postmortem is in progress."
LiteLLM, March 24, 2026: a poisoned package. Malicious LiteLLM versions 1.82.7 and 1.82.8 reached PyPI from 10:39 UTC. LiteLLM's advisory says they were live "for about 40 minutes" before PyPI quarantined them. Its own "who is affected" section uses a wider 10:39 to 16:00 UTC window. Snyk puts the window at about three hours, with quarantine near 13:38 UTC. LiteLLM believes the compromise started in the Trivy dependency of its CI/CD scanning workflow; Snyk says a publishing token stolen in that earlier Trivy compromise let the attacker upload straight to PyPI. The clean release is v1.83.0, and the official LiteLLM Proxy Docker image was not affected.
The stakes were large. BleepingComputer reports over 3.4 million LiteLLM downloads a day, and says the stealer targeted SSH keys, cloud tokens, Kubernetes secrets and .env files.
Attack vs agent error: how do the two cases differ?
The difference is whether an attacker was involved, and that decides which control you need first.
| Replit (July 2025) | LiteLLM (March 2026) | |
|---|---|---|
| Attacker | None reported | Yes, via a stolen publishing token |
| Root cause | Agent with delete rights on production data | Compromised dependency in the build pipeline |
| What was at risk | Production database | Secrets on machines that installed the bad versions |
| First control | Human approval before destructive commands | Pinned, verified dependencies |
Why do teams deploy agents anyway?
Teams deploy anyway because adoption has outrun governance, and Gravitee's own numbers show the gap. Only 7.2% of organizations name an individual with formal accountability for agent behavior. (The same page headlines "85% of organisations have no formal accountability" without explaining the gap.)
Gravitee's earlier wave, published February 4, 2026, had more than 900 respondents. Only 14.4% send all agents live with full security or IT approval. 45.6% of teams still rely on shared API keys for agent-to-agent authentication.
The two waves disagree on incidents: 88% in February against 54% in the April survey. Gravitee attributes the drop to underreporting, not to better security.
How do you reduce AI agent security risks?
You reduce the risk with four controls, applied before an agent gets write access to anything that matters.
- Put a human checkpoint on high-impact actions. No payments, data deletion or access changes without a person approving them.
- Scope credentials to the task. Give each agent its own narrow credentials, never a shared key with broad standing rights.
- Treat outside content as untrusted. Filter what the agent reads from web pages, emails and documents before it can steer the next action.
- Watch behavior, not just failures. Agent observability should flag an agent running commands it has never run before.
The diagram shows control 1: every payment, deletion or access change passes a policy gate, then a human approval, before it runs. For supply chain risk, add a fifth habit: pin and verify every dependency. LiteLLM's advisory warns that projects pulling it in as a transitive, unpinned dependency, such as some agent frameworks or MCP servers, may also be affected.
Try it yourself: should this agent get write access?
Run this check on one agent you use today. As of October 2026, give it write access only if all four answers are yes:
- Owner: one named person is accountable for what the agent does.
- Credentials: it holds its own scoped keys, not a shared API key.
- Checkpoint: a human approves deletes, payments and access changes.
- Visibility: you would notice within a day if it started doing something new.
Any "no" means read-only access until it is fixed. For multi-agent systems, run the check per agent, since one agent's failure can cascade to the others.
