Check text for prompt injection before it reaches your AI
The short answer. Do not let untrusted text reach the model unscreened, and do not let the work it triggers go unrecorded. Screen the input with prompt_shield: it scans for the patterns hidden instructions use, judges the text as a whole, and returns safe, review, or block with the reasons named and a verifiable receipt attached. Then run the work through Zambo, so every tool call the AI makes in response leaves its own receipt. Before and after, both on the record: the screen decides what gets in, and the receipts show what ran.
Scope, stated once and applied everywhere on this page: a verifiable receipt proves the saved result was not changed since it was saved. It does not prove the result was correct. A screening verdict is a saved result: the receipt proves the verdict is the one the check produced, not that the text was certainly hostile or certainly clean.
How hidden instructions travel
- Pasted text. A block copied from a forum, a doc, or a message thread carries a paragraph the human never read, addressed to the model.
- Pages and files the AI fetches. Content written for crawlers and agents can include lines a human visitor would never see rendered, telling the reader model what to do next.
- Tool outputs and data feeds. A record in a database, a field in a JSON response, a commit message: anything the AI is asked to process can carry text shaped as an instruction.
- Chains of agents. One agent's output becomes the next agent's input, so an instruction planted upstream arrives downstream wearing a trusted sender's formatting.
The common thread is that the model reads all of it with the same attention it gives you. The defense cannot be "the AI should know better"; it has to be mechanical: examine the text before the model does, with a tool whose job is only that.
Before, during, and after
- Before: screen the input. Run prompt_shield on text from outside your own hand before it enters the prompt: pastes, fetched pages, file contents, long tool outputs. Act on the recommendation it returns: block, review, or safe, with the flagged patterns as the reason.
- During: keep the work on one recorded connection. Add https://zambo.dev/mcp (no key) to the AI, and the calls it makes run through Zambo: 153 tools, each returning a verifiable receipt. If a screened-through attack still steers a call, the call is on the record with its saved result.
- Can my AI audit my website?
- How can I make my AI agent safer?
- After: audit the record. The receipts show what actually ran, in order, unchanged since each was saved. That is the difference between suspecting a hijack and reviewing one. The output side of the same discipline, catching results an AI invented rather than produced, is covered in How do I catch an AI agent making up results?
Screening is a call like any other: free to try, Day Pass $0.99 for 24 hours when you need volume, Zambo Pass $29/month or $290/year ($19/month for $ZAMBO holders) for ongoing use. The tool's own reference is at zambo.dev/api/prompt-shield.
What screening does not do
It does not catch everything. A screen knows the patterns it knows; a payload phrased to dodge them, or split across turns so no single message looks like an order, can pass, and a safe verdict is a check result, not a promise about the text. It also does not make the model's other failures go away: an AI can be honestly wrong without any attacker involved, and the receipts record that wrongness faithfully rather than fixing it. The honest stack is layered: screen what goes in, record what runs, review what matters. The failure mode this page exists to kill is the quiet one, where hostile text reached the model, the model obeyed it, and nothing anywhere wrote down that any of it happened. The related silent-failure pattern, tools failing without a trace, is covered in AI agent silent tool failure.
Questions, answered
How do I protect my AI from prompt injection?
Screen what goes in, and keep a record of what ran. Through Zambo, prompt_shield checks text before it reaches the model: a pattern scan plus a semantic analysis returns a recommendation of safe, review, or block, with the risk scored and the flagged patterns named, and the check itself returns a verifiable receipt. Then run the work through the same connection, so every tool call the AI makes leaves a receipt you can audit afterward. Screening lowers the chance hidden instructions reach the model; the record is how you find out what happened when something gets through anyway.
What does prompt_shield check?
It looks for the shapes hidden instructions take: orders to ignore or override the AI's own instructions, jailbreak and policy-bypass attempts, attempts to make the AI reveal its system prompt, and attempts to extract private data such as credentials or customer lists. The verdict names what it flagged rather than just scoring it, and the worked example on this page shows both ends of the scale from real runs: an attack paragraph blocked at risk 100, and an ordinary summary request passed at risk 0, each with its receipt verified.
What should happen when a text gets flagged?
Follow the recommendation the verdict carries. Block means the text does not reach the model. Review means a human reads it first, knowing which patterns fired. Safe means it proceeds, with the screening on the record either way. The point of screening at the door is that the decision happens before the model has read the instructions, because after it has read them, asking it to un-read them is not a control.
Can screening catch every attack?
No. A screen checks for the patterns it knows and judges the text it is shown; a novel phrasing or an attack split across messages can pass it, the same way a spam filter misses some spam. That is why the pattern on this page pairs screening with receipts: the screen is the lock on the door, and the record of what the AI actually ran is how you audit the house. Anyone selling certainty here is selling the thing the worked example refuses to claim.
Why keep a receipt of a screening?
Because the screening is itself a claim someone may need to check: that this input was examined, by this tool, on this date, with this verdict. A verifiable receipt fixes that result at the moment it was produced, so a later review, a client, an auditor, your future self, can recompute the check instead of trusting a log line the screened system wrote about itself. On this page, both screening receipts were verified against the public endpoint before the page cited them.