Agentic AI Security Risks: Threats, Vulnerabilities, and Mitigations

Traditional AI security focused on a narrow problem: preventing a chatbot from saying something it shouldn't. Agentic AI changes the threat model entirely. When an AI system can plan multi-step workflows, execute code, read and write files, call APIs, and interact with external services, the attack surface expands from "bad output" to "bad actions."

The OWASP Top 10 for Agentic Applications, released in December 2025, captures this shift. Its opening line: "Once AI began taking actions, the nature of security changed forever." The list covers ten risk categories specific to autonomous AI, from agent goal hijacking to rogue agents that act harmfully while appearing legitimate.

In May 2026, CISA and the other Five Eyes cybersecurity agencies published their first joint guidance on agentic AI, "Careful Adoption of Agentic AI Services." Six national agencies coordinated on a single document, which tells you how seriously governments are taking this surface. Their central message: agentic AI doesn't require an entirely new security discipline. Organizations should fold these systems into existing frameworks like zero trust, defense-in-depth, and least-privilege access. But the specific risk vectors are new enough that most security teams haven't accounted for them yet.

The core problem is autonomy plus access. A chatbot that hallucinates a wrong answer is annoying. An agent that hallucinates a wrong action, then executes it with write access to your production database, is a breach.

Drawing from the OWASP Agentic Top 10, the CISA Five Eyes guidance, and real incidents from 2025-2026, these are the threat vectors that security teams need to understand and plan for.

1. Prompt Injection Through Tool Outputs

The most discussed agentic risk, and for good reason. When agents ingest data from external sources (emails, documents, web pages, API responses), attackers can embed instructions in that data. The agent treats the content as trusted context and follows the hidden instructions.

The EchoLeak vulnerability (CVE-2025-32711, CVSS 9.3) demonstrated this in Microsoft 365 Copilot. A crafted email with hidden instructions triggered data exfiltration during routine summarization, with zero clicks required from the user. The agent processed the email, followed the embedded instructions, and sent sensitive data from OneDrive and SharePoint to an external endpoint through a trusted Microsoft domain.

Mitigation: Treat every tool output as untrusted input. Apply input sanitization between tool responses and agent reasoning. Use secondary inference scanning to detect embedded instructions in data the agent processes.

2. Tool Poisoning and MCP Supply Chain Attacks

Tool poisoning occurs when an attacker embeds malicious instructions in a tool's metadata: its name, description, or input schema. Since agents read tool descriptions to decide how to use them, a poisoned description can redirect agent behavior without modifying any application code.

A worked example from Invariant Labs: an add_numbers tool whose description contains a hidden instruction to read ~/.ssh/id_rsa and pass its contents as a parameter. Static code analysis finds nothing wrong. The vulnerability exists entirely in the relationship between the tool description and how the LLM interprets it.

The Model Context Protocol (MCP) amplifies this risk because it centralizes tools in servers that many agents share. Every agent that trusts an MCP server inherits its behavior. Three structural gaps make this worse: no cryptographic signing on tool descriptions, descriptions hidden from end users, and cross-tool propagation where compromised descriptions in one tool manipulate agent behavior toward other tools.

Mitigation: Pin and hash tool descriptions at ingestion. Maintain allowlists of approved MCP servers with version pinning. Block network egress for tools that don't need it. Treat third-party MCP servers as untrusted by default.

3. Data Exfiltration Through Agent Actions

Agents with broad permissions can be tricked into exporting data under the guise of legitimate business tasks. In one documented incident, an attacker tricked a reconciliation agent into exporting "all customer records matching pattern X," where X was a regex that matched every record in the database. The agent found the request reasonable because it was phrased as a business task.

The scale of this risk is staggering. In the Mexican government breach (December 2025 to February 2026), an attacker used Claude Code to exfiltrate 195 million taxpayer records and 220 million civil records across nine agencies. The AI executed roughly 75% of remote commands autonomously, with 1,088 prompts generating 5,317 commands. The attacker told the AI it was running a legitimate bug bounty program.

Mitigation: Implement transaction-level thresholds. No agent should move more than N records or N bytes without human approval. Apply data loss prevention (DLP) rules to agent output channels. Log every data access and export for audit.

4. Privilege Escalation

Agents often inherit the permissions of the user or service account that runs them. If an agent needs read access to a CRM and write access to a code repository, it typically gets both through a single identity with combined permissions. Attackers exploit this by crafting inputs that trick agents into using tools in unauthorized ways.

The CISA guidance identifies privilege risk as one of five distinct risk categories and recommends starting with low-risk, non-sensitive use cases. Their advice: avoid granting broad or unrestricted access, especially to sensitive data or critical systems.

Mitigation: Create dedicated service accounts for each agent with scoped permissions. Apply least privilege at the tool level, not just the account level. Use short-lived tokens instead of persistent credentials. Audit permission grants regularly.

The May 2026 CISA guidance organizes agentic AI risk into five categories. This framework is useful because it moves beyond individual attack vectors and addresses systemic risk.

Privilege risks cover what an agent can access and do. The guidance recommends scoped permissions per agent, short-lived credentials, and starting with low-risk use cases before expanding.

Design and configuration risks address how agents are built. Default configurations that grant broad access, lack of input validation on tool outputs, and missing audit trails all fall here.

Behavioral risks involve what agents actually do at runtime. Agents may take unexpected actions, exhibit emergent behaviors in multi-agent systems, or respond to adversarial inputs in ways their designers didn't anticipate.

Structural risks cover the systems agents operate within. This includes supply chain integrity, inter-agent communication security, and the blast radius when a single agent is compromised.

Accountability risks address who is responsible when things go wrong. When an autonomous agent takes an action that causes harm, the chain of accountability from developer to deployer to operator needs to be clear.

The agencies' strongest recommendation: don't treat agentic AI as a separate security domain. Integrate it into your existing security frameworks. Apply zero trust principles. Use defense-in-depth. And above all, enforce least-privilege access.

Lock down your agent file access with audit trails and granular permissions

Fast.io gives every agent a controlled workspace with four-level permissions, file versioning, and a unified audit log for human and agent activity. 50GB free, no credit card.

Sign Up Free

Security frameworks are useful for understanding the landscape, but teams need concrete steps. Here's a prioritized list of mitigations you can start implementing today, ordered by impact and effort.

Enforce Least Privilege at Every Layer

Create dedicated service accounts for each agent. Scope permissions to exactly what the agent needs, nothing more. Use short-lived tokens (minutes or hours, not days). Review permissions quarterly.

This is the single highest-impact mitigation. The Step Finance breach in January 2026, where $40 million in SOL tokens were stolen, happened because trading agents had unlimited transfer permissions with no human approval requirement.

Implement Human-in-the-Loop Controls

Set thresholds for actions that require human approval: transactions above a dollar amount, data exports above a row count, permission changes, and any action that affects production systems. The CISA guidance specifically recommends beginning with use cases that are low-risk and non-sensitive.

Build Audit Trails for Agent Actions

Every agent action should be logged with full context: what was requested, what tools were called, what data was accessed, and what the outcome was. This isn't just for incident response. Audit trails let you detect anomalous patterns before they become breaches.

Platforms like Fast.io provide built-in audit trails for workspace activity, tracking every file access, modification, and share event across both human and agent actions. When agents operate in shared workspaces alongside humans, having a single audit log that covers both is critical for accountability. Fast.io's granular permissions at the org, workspace, folder, and file level let you enforce least-privilege access for agent accounts the same way you would for human users.

Treat All External Data as Untrusted

Any data an agent ingests from outside its trust boundary (emails, documents, API responses, web content) should be treated as potentially adversarial. Apply input sanitization between data ingestion and agent reasoning. Use secondary inference scanning to detect embedded instructions.

Pin and Verify Tool Dependencies

Hash tool descriptions and schemas at deployment time. Don't allow automatic updates to tool metadata. Maintain an allowlist of approved MCP servers and review new additions. This prevents tool poisoning and rug-pull attacks where a trusted tool silently changes its behavior.

Monitor Agent Behavior at Runtime

Track complete tool-call chains per session. Flag unexpected sequences (Tool A calling Tool B when they've never been chained before). Set alerts for anomalous data volumes, unusual API call patterns, and requests outside normal operating hours.

One of the most overlooked attack surfaces in agentic AI is file access. Agents that can read, write, and share files operate with a level of access that most security teams haven't fully mapped.

The risks break down into three categories. First, agents may access files they shouldn't, either through overly broad permissions or through prompt injection that tricks them into reading sensitive data. Second, agents may write malicious content to files that humans later trust and open. Third, agents may share files externally in ways that bypass data loss prevention controls.

Local file storage offers zero visibility into what agents are doing. Cloud storage platforms vary widely in their agent-specific controls. S3 gives you fine-grained IAM policies but no built-in agent activity monitoring. Google Drive has sharing controls but wasn't designed for programmatic agent access patterns.

Fast.io was built for exactly this use case. Agents and humans share the same workspaces, with the same permission model applying to both. Every file access, modification, and share is logged in a unified audit trail. Granular permissions at four levels (org, workspace, folder, file) mean you can give an agent write access to a specific project folder without exposing the rest of the workspace. File versioning means you can roll back any agent-initiated change. And because Fast.io exposes its workspace through an MCP server, agents access files through the same controlled interface rather than through direct filesystem access.

The free agent plan includes 50GB of storage, 5 workspaces, and full audit trail access, enough to test these controls without commitment or a credit card.

For teams already using agent frameworks, the workspace approach addresses a fundamental gap: it puts a permission and audit layer between the agent and the files, rather than giving agents raw filesystem access and hoping for the best.

The organizations getting agentic AI security right share a common approach: they treat agents as principals in their security model, not just tools. An agent gets an identity, scoped permissions, monitored access, and a revocation path, just like a human employee or a service account.

Start with a risk assessment specific to your agentic deployments. Map every agent in your environment: what tools it can access, what data it can read and write, what external services it connects to, and what the blast radius would be if it were compromised. The CISA framework's five risk categories (privilege, design, behavioral, structural, accountability) make a practical checklist for this assessment.

Then prioritize mitigations based on your specific risk profile. If your agents process external data (emails, customer inputs, web content), indirect prompt injection is your top priority. If your agents use marketplace tools or MCP servers, supply chain integrity comes first. If your agents have broad system access, least-privilege enforcement is where you start.

Three principles from the CISA guidance are worth repeating:

1. Start with low-risk, non-sensitive use cases and expand gradually as your security controls mature.
2. Account for agentic AI in your existing security model and risk posture. Don't build a parallel governance structure.
3. The security properties of agentic AI should be evaluated at the system level, not just the model level. A secure model inside an insecure deployment is still insecure.

Agentic AI is moving fast. 48% of cybersecurity professionals already identify autonomous AI systems as the top attack vector for 2026. The organizations that build security into their agent deployments from the start will move faster and more confidently than those scrambling to retrofit controls after an incident.