Your AI Research Agent Can Be Poisoned by the Prospect's Own Website: Prompt Injection in GTM Research

Your research agent reads the About page. It reads the docs, the pricing page, the reviews on G2, sometimes a resume someone uploaded into the funnel you're piping through Clay. Every one of those pages is content the agent was told to trust the second it landed in its context window.

That's the setup almost nobody checks. GTM teams point agents at a prospect's website to build account briefs, score fit, and draft first-touch messaging. And the agent treats what it reads as neutral input, the same as a row in a spreadsheet. It isn't neutral. A website is something the prospect controls completely. And text on that page can be written to be read as an instruction instead of a fact.

This isn't a tutorial on attacking your own pipeline. But it's what to check before an agent's read of a prospect's website turns into an action nobody signed off on.

What Prompt Injection Actually Is

OWASP's GenAI Security Project lists prompt injection as LLM01 in its 2025 Top 10 for LLM Applications, the top spot for the second edition running. The definition splits into two kinds. Direct injection is a user typing malicious instructions straight at a model: ignore your previous instructions and do X. But indirect injection is the one that matters for a research agent: the model reads those instructions inside content it was asked to process instead, a document, an email, a webpage. Which is exactly what happens when a research agent summarizes a prospect's site.

Where the Term Comes From

Riley Goodside demonstrated the underlying trick against GPT-3 on September 11, 2022, showing that a carefully placed instruction inside a prompt could override what the model was told to do. Simon Willison named it the next day, September 12, crediting Goodside's demonstration explicitly and drawing the parallel that still holds: prompt injection is SQL injection for language models. The failure isn't a bug in one model release. So it isn't something a patch fixes. An LLM reads instructions and data through the same channel, with nothing structural telling it which is which.

That distinction, instruction versus data, is the entire disease. And everything below is one version or another of rebuilding the wall that channel doesn't have.

Why GTM Research Pipelines Are an Easy Target

The Fields Your Agent Already Trusts

About-page copy. Review-site quotes. Confirmation text on a form. Hidden structured data in a page's JSON-LD, the part search engines read and humans never see. All of it lands in an agent's context looking exactly as trustworthy as anything else there, because nothing marks it as anything else. OWASP's AI Agent Security Cheat Sheet names this directly as a primary delivery surface for indirect injection. And by 2026 it isn't just OWASP saying so. Zscaler's ThreatLabz team, Palo Alto's Unit 42, and Google's own Threat Intelligence Group, working with Google DeepMind, have each independently documented the same pattern in live traffic.

Two Real, Documented Examples

Here's one that's already public and has nothing to do with security research at all. Hiring platforms started finding resumes with white-on-white text instructing AI screening tools to rate the candidate highly. Staffing firm ManpowerGroup told the New York Times it detects hidden text in around 10% of the resumes it scans with AI; hiring platform Greenhouse put its own estimate at 1%. Nobody built that trick to attack anyone. But job seekers built it to game a parser. The mechanism, text a machine reads and a human doesn't, is identical to what a hostile page does to your research agent. The only thing that changed is who's holding the pen.

The second is closer to home. Zscaler's ThreatLabz seeded an autonomous test agent at two live websites its researchers found already carrying hidden instructions: one posing as documentation for a Python library, one a typosquat of a real crypto portfolio tracker, both hiding the text with CSS positioning and JSON-LD so a human visitor would never see it. The fake documentation page told visiting agents to pay a small licensing fee to an attacker's wallet. Across 26 different large language models tested against it, four followed the instruction and completed the payment, including versions of Llama and Gemini. So that's a webpage successfully hijacking a general-purpose AI agent into paying an attacker. A GTM research agent visiting any prospect's site, targeted or not, reads with the same trust.

Scale it up and the trend isn't shrinking. Google's Threat Intelligence Group and Google DeepMind rescanned CommonCrawl snapshots of the open web, static sites, blogs, forums, and comment sections, explicitly excluding social platforms, and measured a 32% relative increase in pages carrying content their classifiers flagged as malicious indirect prompt injection, between November 2025 and February 2026. That figure describes ordinary crawled web pages, the same kind your research agent reads, not resumes or ATS systems. And separately, Unit 42 cataloged 22 distinct payload techniques in real-world telemetry and found most of them boring on purpose: plain visible text was the single largest category, with basic HTML attribute cloaking and CSS suppression covering most of the rest. You don't need an exotic attack. You need a page and a reason to hide something on it.

The Fix: A Strict Data/Instruction Boundary

Treat Scraped Content as Text to Summarize, Never a Command

OWASP's mitigation guidance comes down to one move: segregate untrusted external content and run it through a separate call that validates or summarizes before it reaches the model doing the acting. Translate that into an operator rule and it's simple to state, harder to actually enforce: nothing an agent reads off a website is allowed to change what it does next. Only what it reports. The About Us paragraph gets summarized. But it never gets obeyed.

Gate Before Send

No agent output, a scored lead, a drafted email, a field written back to the CRM, reaches a prospect or a system of record without a person checking it first. This is the single most effective control on this list, because it catches injection and ordinary AI error with the same gate. You don't need to know whether a bad output came from a poisoned page or a model having an off day. So you just need the gate to exist.

Label Confidence, Not Certainty

Every claim an agent pulls off the open web gets tagged verified, inferred, or open. A funding round confirmed on TechCrunch is verified. A headcount guessed from a LinkedIn scrape is inferred. A claim that only shows up on the company's own About page, the one page a prospect fully controls, is open until something independent confirms it. Skip this step and a poisoned or simply wrong data point passes as fact three steps downstream. And nobody can tell which enriched field to distrust when the output looks off.

How This Shows Up in an Actual Research Stack

None of this is abstract if you're already running agents on Claude Code, pulling pages through Firecrawl or Browse AI, or doing semantic discovery with Exa. All of it sits upstream of the same boundary. The tools aren't the risk. What happens to their output after the fetch is.

We're not a security firm. And this isn't a security audit. We're a GTM engineering shop that applies OWASP's published framework to the same research pipelines we build for clients, because the alternative is pretending a scraped field can't lie. Every research pipeline built here treats what a page says about itself as data to weigh, not an instruction to follow. Nothing writes to a CRM or reaches a prospect without a human checking it first. And every claim gets labeled by how it was sourced, not just by what it says.

There's a mirror-image version of this problem too: companies embedding hidden instructions in "Summarize with AI" buttons, aimed at persisting into an AI assistant's memory so it recommends them by name later. Microsoft found 50 distinct attempts like that from 31 companies over 60 days of research, published in a February 2026 report. That's a marketing risk aimed at consumer AI assistants. This piece is about the more common exposure, the one that touches every GTM team running agents whether they've been targeted or not: your own research agent visiting any prospect's site and taking what it reads as ground truth. If your motion is leaning on agents for more than research, drafting outreach, updating records, taking action on what they find, the readiness question gets bigger than input hygiene alone.

A Checklist Before You Trust an Agent's Output

Seven questions worth asking about your own stack today, not the vendor's:

• Does the agent ever act on what it reads, or only report it?
• Is there a human gate before anything reaches a prospect or a system of record?
• Are claims labeled by how confident the agent actually is, not just presented as fact?
• Would a hidden instruction on a prospect's page change what the agent does next?
• Does anyone check the raw scraped text, or only the agent's summary of it?
• Can you point to which field in your last hundred enrichments came from an unverified page?
• If a scored lead looked wrong, could you trace why, or would you just re-run it?

None of this is a reason to keep agents out of GTM research. But it's the discipline that makes using them safe. The website was always going to be untrusted input. The only question is whether your pipeline was built knowing that.