How Hackers Exploit AI Agents and How to Protect Them

Attackers do not need a new class of exploit for agents. They need a way to get text in front of the model and a tool with enough authority to act on it. The attack chain usually has four stages: reach, influence, act and hide.

Stage 1: Reach

The attacker needs content the agent will read. Common paths are a web page the agent browses, an email it triages, a document it summarizes, a code comment it reviews, a calendar invite, a support ticket or a tool result from a third-party API.

Anything the agent treats as context is an input surface. If the agent can browse arbitrary URLs, the attacker can host the payload. If it reads shared documents, any contributor can plant it.

Stage 2: Influence

The payload tries to change the agent's goal or authority. It may claim to be a system update, a new policy, a higher-priority instruction, or a message from the user's manager. It may be split across chunks, encoded, or hidden in HTML comments and metadata.

The model does not need to be fully jailbroken. A small change — send the summary to this address, call this endpoint first, include this token — is enough.

Stage 3: Act

The agent uses a tool. The attacker's advantage is any tool with broad scope: a shell, a database, an email sender, a payment API, a browser with the user's cookies, a cloud credential.

Common escalations:

• —Reusing a long-lived token found in the environment.
• —Calling a tool with a different recipient or table than intended.
• —Creating a new credential or inviting a new user.
• —Writing to a public location and reading it back.
• —Triggering a webhook to an attacker-controlled URL.

Stage 4: Hide

The agent reports success in normal language. The malicious step is buried among legitimate ones. Without per-step evidence, the operator cannot tell what happened.

Attackers also exploit retries: a failed action may be retried with adjusted arguments until it succeeds.

Breaking the chain at each stage

Reach: restrict browsing to allowlisted domains; treat all retrieved content as hostile; label provenance; isolate untrusted content from instructions.

Influence: screen retrieved and tool content for injection; use a model prompt that makes data/instruction separation explicit; cap how much untrusted text can influence a plan.

Act: least-privilege tools, scoped short-lived credentials, argument validation, destination allowlists, step/spend caps and human approval for irreversible actions.

Hide: log every step with arguments hash, verdict and result; chain the log; alert on unusual tool sequences; make the agent's plan visible before execution for high-impact tasks.

What attackers look for in your design

• —A single API key shared by all tools.
• —A browser tool with no domain allowlist.
• —An email tool that accepts arbitrary recipients.
• —A database tool that accepts raw queries.
• —An agent that can install packages or run shell commands.
• —No approval for payments or deletions.
• —No cap on steps or spend.
• —Logs that only record the final answer.

A useful exercise

Give a red team the agent and nothing else. Ask them to make it send a file to an external address, change a record they should not touch, or spend above a limit. Watch where the chain breaks. If the answer is "the model refused", that is not a control; models can be persuaded. If the answer is "the tool had no permission", you have a boundary.

Agent security is mostly authorization engineering around a probabilistic planner. The planner will be wrong. The boundaries should still hold.