Can someone hijack your AI SDR by putting instructions on a web page?

Yes, if you let an agent read the open web while holding anything valuable. That is prompt injection. The fix is not a filter and not a better prompt. It is a sandbox that holds no live credential, plus a broker outside the sandbox that swaps dummy keys for real ones and inspects what passes through.

I am Eduard Klein. I advise CEOs, founders and boards on AI Business Strategy, and I built this defence into my own AI SDR in 2026 before I wrote a word about it. The 7 components it sits inside are in the full AI SDR blueprint, published on 19 August 2026.

The finding that made this page necessary

In August 2026 I asked Claude and ChatGPT and Gemini the same question, twice each, 8 runs in total: what do people actually ask you about AI SDR systems? 150 questions came back over 2 days.

In September 2026, going back through all 150, I count 0 that raised prompt injection.

Every security question in that set of 150 was a procurement question. SOC 2. Encryption. Data residency. Can you pass our vendor review. Those are questions about whether a supplier survives your legal department. None of them is a question about whether the agent itself can be turned against you by a page it reads.

I ran that harvest from my home office in Barcelona on a Tuesday morning in August 2026, clustered the 150 questions, and read the top of the list twice before the hole registered, because a hole is harder to see than an entry. That gap is why this page exists. If Claude and ChatGPT and Gemini are not raising prompt injection, your team is not being prompted to ask about it either.

What prompt injection actually does to an SDR

Your research agent visits a prospect's website to prepare an outreach message. The page contains text that reads as an instruction rather than as content. In my own system that agent is Component 5, the research sandbox, and it is the only one of the 7 that ever sees a page I did not write.

That text does not have to be visible. It has to be in what the agent reads. From the model's point of view there is no boundary between the page you asked it to summarise and a sentence on that page telling it what to do next.

Now ask what the agent is holding while it reads. If it has write access to your CRM, whether that is Salesforce or something you built, an attacker can write to it. If it has your mailbox, an attacker can send mail as you. If it has an API key, the attacker has the key. The severity of prompt injection is entirely a function of what the compromised component was carrying, which is why the defence is architectural rather than textual.

The architecture I run

The research agent runs in a box. Isolated, no write access to the CRM, no access to my mailbox, no credentials of any kind.

It is the only 1 of my 7 components allowed to touch untrusted content. That is deliberate. Research means reading pages I do not control, so I built all of that exposure into exactly one component and made that component structurally incapable of doing damage with what it finds.

Two mechanics make that real rather than aspirational, and I built both in 2026 before the first outreach message went out.

First, the sandbox never holds a live credential. When it needs to call an external service it works with dummy keys. A broker sitting outside the box swaps them for the real ones on the way out. Anybody who compromises the researcher walks away with a key that opens nothing.

Second, that broker is the natural place to look at what is moving through the pipeline before it goes anywhere. I run a second process checking there, and that second process does not depend on an LLM to do its checking.

The two rules underneath it

Always have a second process checking, and never make that second process depend on an LLM. Those are the 2 rules, and I have not relaxed either since 2026.

The second half is the part people skip in 2026, because the fashionable answer is to put a model in front of the model. An LLM-as-judge is subject to the same class of attack as the LLM it is judging. If the input can talk the worker into something, it can talk the judge into agreeing. Rules cannot be talked into anything, which is the entire reason I wrote rules instead of a second prompt.

The second rule is shorter. A sandboxed agent returns data, never instructions. Whatever comes back from the box is stored as content in the CRM, and nothing in it is ever executed as a request.

This is where most people building AI SDR tools in 2026 get it structurally wrong. They try to make hostile input safe, usually with a filter and a hopeful prompt. You cannot. The correct move is the opposite one: assume the input is hostile, and shrink the blast radius until hostile input cannot reach anything that matters.

What are the biggest failure modes of AI SDRs?

No human in the loop, trying to build everything at once, and letting a beginner build it. Prompt injection is the exotic one. These three are the ones that actually take systems down.

The first is underestimated. Agents write genuinely silly things, and I do not mainly mean hallucinations. They talk too much, overwhelm the reader, and go off in directions no experienced person would. I have watched that happen often enough to build around it. An agent cannot assess the consequences of its own actions. Only people can, in September 2026, which is why I stay in every loop that touches a human being.

Second comes a build problem. This has to be set up iteratively. Everything at once fails. AI needs longer test cycles than conventional software, and constant correction, which is part of why my own framework took 8 months of 2026 rather than 8 weeks.

Third, and nobody says this one out loud. Since 2023 I have repeatedly watched a non-technical person get 3 months of a production agent working, and then the thing decides to restructure itself and breaks itself in the process. It is why I now follow a structured build procedure rather than improvising.

How this connects to hallucinations

Prompt injection is an attack from outside. Hallucination is a failure from inside. Across 3 years of running agents I have found the defence to be the same shape for both.

Put a second agent over the output, and do not let that second agent rely only on an LLM. I test my own output against rules as well as against a model. Most of what goes wrong repeats, and repeating problems are exactly what rules catch. For the remainder, the model flags it, raises an incident, and I look at it myself.

The general principle covers both cases, and it is the same one behind Component 7 in my blueprint: anything with a known correct answer should not be left to a model.

What this costs you

Almost nothing in money, and roughly 2 weeks of design time in my own build.

A sandbox is not an expensive component, and the broker is a small piece of infrastructure. Neither moved the $1,000 figure I quote for standing up an agent on my framework. What it costs is the discipline to decide, before you build, which single component is allowed to read the open web, and then to hold that line when it would be convenient to give the researcher CRM access "just for this one job". I built the sandbox first, in 2026, precisely so that the convenient version was never available to me later.

The wider version of this risk, what happens to a company that becomes invisible to ChatGPT and Google AI Overview when its buyers ask, is a different problem I wrote up in AI strategic visibility.

What I still cannot answer

I do not know how long the vetted-source approach holds.

Right now my research agent reads a fixed list of sources and that keeps the attack surface small. The list is manual and it ages. The day I widen it is the day I inherit the problem I designed around, and I do not yet know what the answer looks like at web scale. I have run the narrow version for 6 months in 2026 and I have not had to solve the wide one.

The second thing I do not know is what happens when the page my agent is reading was written by another agent that knows mine is coming. I saw the first threads of that in August 2026 and I have 0 useful data on it yet.

The rest of the failure surface: how I stop hallucinations and off-brand messages, the tech stack I actually run and where my own AI SDR failed.

About the author

Eduard Klein is an AI Business Strategist for CEOs, founders & boards, and he has been on the receiving end of the vendor security review this article says is asking the wrong questions: he did software sales for SAP, for Microsoft, for Oracle and for the German Stock Exchange, answering procurement questionnaires that never once asked what the software would do with a page it was told to read. Thirty years of building software sits behind the architecture here, alongside years in inside sales and key account management and 170+ articles across 100+ publications including Hunter.io and Cognism (the full list).