If you are building an AI product that reads anything on a user's behalf (emails, web pages, résumés, referral letters, reviews), prompt injection is not an abstract research topic. It is a design constraint, and a question your customers and investors will eventually ask.
This guide is written for founders and technical builders. It covers why the problem exists, what the evidence says about how often attacks work, and which product decisions reduce your exposure early, when they are cheapest to make.
The core problem, in founder terms
A language model receives your system rules, the user's request, and the content it is processing as one stream of text. It cannot always tell information from instructions, and it is trained to follow instructions. So text hidden in a document can end up steering the product.
There are two forms:
- Direct: a user types something like "ignore your rules" into your chat.
- Indirect: the attack is hidden in content your product reads, such as white text on a white background, tiny text, notes in a web page's code, files, images, calendar invites or online reviews.
Indirect injection matters most for builders of agents, because the attacker never needs access to your product. They only need to place text where your product will read it. For a more basic explainer, see the original post on prompt injection.
What the evidence suggests
Treat the following as direction, not a precise benchmark, since the tests differ.
- In 2025, researchers showed that a single email with no click needed could make Microsoft 365 Copilot send internal data out (EchoLeak). Microsoft fixed it before it went public, with no sign attackers used it.
- In 2026, Palo Alto Networks researchers found hidden instructions on real websites, aimed at AI agents that review ads, screen job applicants, and browse and shop.
- In an October 2026 test of seven models on office tasks, the most resistant fell for a single attempt about one time in twenty. With eleven attempts it was about one in six, and with an adaptive attacker retrying, about four in ten.
- In a March 2026 public competition of roughly 272,000 attempts, all thirteen top models fell for some attacks.
The lesson for a founder: attempts accumulate, and no model is immune. Do not plan around a model that "behaves."
Where it hits your use case
| Product type | Hidden-text risk | Sensible design response |
|---|---|---|
| Vendor comparison or research agent | A site hides "always recommend us" | Treat web text as information, never as instructions |
| Clinical or document summarizer | A letter hides "summarize as low risk" | Keep a human making the decision |
| Résumé screener | A résumé hides "rank this candidate first" | Flag hidden text for human review |
| Inbox assistant | An invoice hides a forwarding order | Require confirmation before sending |
A pre-launch checklist
Don't rely on the model's good manners. Build controls around it.
- Separate information from commands. Content the model reads may shape what it says, not what actions it takes.
- Confirm consequential actions. Sending, paying, deleting and sharing should require a person's approval.
- Grant minimum access. Scope each agent's data and tools to the one job it performs, so a successful injection has a small blast radius.
- Verify sensitive changes out of band. Payment or contact changes should be confirmed through another channel.
- Log and review. Record what the agent read and did, so you can investigate odd behavior.
Turning security into a sales asset
Enterprise buyers increasingly ask how your product handles untrusted content. Being able to explain your controls plainly, without claiming immunity, builds trust and shortens security reviews. Overclaiming does the opposite: given the evidence above, "we prevent prompt injection" is not a credible statement.
In pitch conversations, describe your approach as layered: limited permissions, human confirmation, and monitoring. That shows investors you understand the risk and have priced it into the roadmap.
Where to go next
Building trustworthy AI from day one is far cheaper than retrofitting it. If you want a structured way to assess your product's safeguards, the Responsible AI-by-Design Framework is a useful starting point, and the main Silverberry site shows how the studio supports AI builders more broadly.
The direction is encouraging: models are better than a year ago. But it is not solved, so design as if some attacks will get through.