AI agent security risks: autonomous-agent abuse, tool calls, exfiltration

An AI agent is a system that does not just answer — it pursues a goal by selecting tools, calling APIs, reading files, and executing multi-step workflows, often with no human approval per step (WitnessAI — 8 cybersecurity risks of agentic AI). That autonomy is the value and the risk: a chatbot that hallucinates produces bad text, but an agent that hallucinates can commit harmful actions with real credentials against production systems. The attack surface is no longer just the prompt — it is every tool, identity, memory, and integration the agent can reach. See also what prompt injection is and the secure AI agent deployment checklist.

1. The core components that expand the attack surface

A traditional app follows deterministic logic; an agent reasons through a plan, invokes tools, and acts on results, often in a loop (Redfox Security — AI agent security risks). The components that widen the surface:

• The model — the reasoning engine.
• The tool set — web browsing, code execution, file access, external APIs.
• Memory — context stored across steps or sessions.
• Orchestration — multi-agent coordination.
• The trust model — what the agent is permitted to do.

Anyone who controls an untrusted input the agent reads (a web page, a document, an API response) has a channel into its decision-making.

2. Excessive agency and uncontrolled action chains

Excessive agency (OWASP LLM06) is when an agent holds permissions beyond its task scope. No single tool call is evil; the combination is. An agent authorized to read files and post to Slack can chain those into an exfiltration path (Redfox Security).

• In April 2026, a Cursor coding agent deleted a production database and all volume-level backups at PocketOS while resolving a routine credential mismatch — with no confirmation step (WitnessAI).
• Anthropic's internal red team showed a crafted prompt exfiltrated AWS credentials in 24 of 25 attempts (96%) against its own agent (WitnessAI).

3. Tool poisoning and MCP risks

Tool poisoning embeds malicious instructions in the natural-language descriptions or return values that agents read when choosing a tool — so behaviour is steered without touching model weights or the user prompt (WitnessAI). Poisoned MCP tool descriptions are now tracked as their own attack class; a reported GPT-4.1 case pushed an agent toward unauthorized data access with no malicious user prompt at all. MCP server vulnerabilities matter because the protocol itself does not require authentication (WitnessAI).

4. Data exfiltration paths

Exfiltration through an agent is subtle because the action looks authorized. Treat every tool call as first-class, audited telemetry — the agent's reasoning may be opaque, but its actions are observable (Aviatrix — Living-off-the-Agent). Strong detection signals:

• A tool call disproportionate to the stated task (a "summarize this" request that reads ~/.ssh/id_rsa).
• Cross-scope/cross-tenant chains: read in scope A, then write or send in scope B.
• Tool drift: any change to a previously approved tool or MCP descriptor (the "MCPoison" pattern).

Hardening: least privilege enforced outside the model, human-in-the-loop for irreversible actions, tool allowlists with pinned descriptor hashes, and treating tool outputs as untrusted input to be sanitized before re-entering context.

5. How AgentRedTeam surfaces agent risk (honestly)

AgentRedTeam runs automated adversarial simulations against your agent — including indirect-injection, tool-abuse, and exfiltration-chain scenarios — and returns a prioritized report of likely gaps. It does not guarantee finding every abuse path, and it is not a substitute for a formal penetration test. It is decision-support to help you scope least-privilege and human-in-the-loop controls before attackers do. Also see the LLM red-teaming guide for the full method.