Prompt Injection: When Your Data Attacks Your Agent

Prompt injection is an attack in which instructions embedded in content an AI reads get treated as commands to follow. Direct injection is the person at the keyboard trying to talk a system out of its rules. Indirect injection is subtler and matters more for agents: the malicious instruction hides inside data the AI was asked to process — a webpage, a document, a review — and fires when the model reads it.

Ads agents inherit a vector most discussions miss: your account data contains text written by strangers. Every query in your search terms report is something an anonymous member of the public typed into Google. When your agent reads that report, other people's words enter its context window. Your data is, in the technical sense, user-generated content.

How prompt injection works

The mechanism is the model's central limitation: language models process instructions and data in the same stream, and nothing intrinsic marks a sentence as "content to analyse" rather than "command to obey". An attacker who can place text where a model will read it gets a chance to steer the model that reads it.

Mapped to an ad account: anyone can search Google for a string designed to look like instructions, and if it accrues impressions against your keywords, it can land in the report your agent reviews weekly. Landing pages and competitor sites the agent is asked to fetch carry the same property — attacker-writable text, agent-readable context.

A realistic assessment needs both halves. What injected text could do: bias the agent's analysis, plant a recommendation, nudge it toward proposing a write the attacker wants. What it cannot do through a well-designed connector: execute anything silently — spend-affecting writes surface as explicit tool calls for your approval, so a hijacked suggestion still has to walk past you wearing its arguments; delete anything — through a connector with no remove tools exposed, deletion is not expressible at all, the design argued in the case for AI that cannot delete; or reach accounts outside the connector's scope. The attack degrades from "compromise the account" to "try to fool the human reviewing the change" — a real risk, but a familiar, bounded one.

Mitigations you can buy, not just practise

The mitigations that matter are architectural, and they are worth naming because they are buyable properties, not habits: approval gates on writes, so no instruction — yours or an attacker's — moves money without a human click; capability absence, so the worst classes of action have no tool to call; scoped connectors, so one poisoned context cannot roam every client account; and an audit trail, so anything odd is reconstructable after the fact. Layered together, they assume the model will sometimes be fooled and make the fooling survivable.

Your own contribution is a reading habit: when an agent's recommendation seems to come from nowhere, ask what data produced it. An agent that quotes its sources makes injected text visible in the quoting.

And when evaluating any ads-AI vendor, injection makes a crisp interview: Which tools exist, exactly? Are writes gated? Can it delete? Is fetched content treated as data? What does the log show? Vendors with real answers have thought about the problem; the full set of AdCopilot's answers lives on the security page.