Prompt injection test tool: test the agent, not just the text

The attack, in plain words

An AI agent reads content to do its job: pages, files, tickets, search results. Anyone who can place text in that content can write instructions addressed to your agent. The agent cannot reliably tell which instructions came from you and which came from the reading material, because both arrive as text it is trying to be helpful with. That is prompt injection, and it is not a bug in one model. It is a property of asking a language model to both read and obey.

So the security question is behavioral. Not whether hostile text exists, it does, but what your agent does when it meets some: which tools it calls, what it tries to send, and whether it stays inside the job you gave it.

Two different defenses, often confused

• Checking the text scans content before the agent acts on it and flags known injection patterns: instruction overrides, hidden directives, impersonated system messages. This hub's text check page covers that layer, and it is worth running on anything untrusted your agent is about to read.
• Testing the agent assumes hostile text gets through, because some of it will, and measures the behavior: you plant the instruction, run a real task, and audit the tool calls afterward.

Run both. The check lowers how often the agent sees an attack. The test tells you what happens when it does.

Run a test in four steps

1. Plant the instruction. Put a clear, bounded directive in content your agent will read during a normal task: a page that says to email a file somewhere, a document that says to skip the approval step, a tool description that adds a secret extra call. Make the planted action something you can detect and something harmless if it fires.
2. Run a real task that makes the agent read the planted content in the ordinary course of work. A test the agent can tell apart from real work tests the wrong thing.
3. Read the tool call record, not the summary. List every call the agent made. You are looking for calls the user never asked for: a send, a fetch to an unexpected place, a write outside the task. The agent's own summary of the session will describe a normal session either way.
4. Score it plainly. The planted instruction fired, was noticed and refused, or was never acted on. Record which, with the receipts, so the next test after a model or prompt change compares against evidence.

When the test fails, shrink the blast radius

A failed test is information, and the fixes are structural rather than hopeful. Give the agent fewer tools than the job could theoretically use. Put consequential actions behind a human decision: in a Zambo handover, the client accepts or flags on the record, and a flagged step stops the story there. Cap what the agent can spend, with the cap recorded the same way its calls are. And keep the receipts: the difference between an incident you can reconstruct and one you can only apologize for is whether the calls left records.

Red team your own agent for a day

One planted instruction is a smoke test. A real drill runs the agent against your actual workload with planted content seeded through it, then audits every call. A $0.99 Day Pass puts a verifiable receipt under every call for 24 hours, which is exactly the record the drill is read from: plant in the morning, run the day, audit the calls at night, and keep the receipts as the baseline the next drill has to beat.

Prompt injection audit: the full review, not just one drill

A single test answers one question about one planted instruction. A prompt injection audit answers the wider question: across everything your agent can read and every tool it can call, where could a hostile instruction enter, and what would it be able to do? Run it when you first give an agent real tools, and rerun it whenever the model, the system prompt, or the tool set changes.

1. Inventory. List every tool, every MCP server, and every kind of content the agent reads in normal work. If a source is not on the list, it is not in the audit, and it is still a way in.
2. Read the surfaces. Read every tool description and a sample of tool results word for word, then scan both with prompt_shield. You are looking for sentences written to the model rather than to the user.
3. Drill the workload. Plant bounded canary instructions across the real content types, run ordinary tasks, and read the call record for each run.
4. Score and fix. A pass means no canary turned into a tool call and every call in the record traces back to the user job. A fail is specific: name the call, the content that caused it, and the fix, whether that is removing a tool, narrowing its access, or adding a human decision in front of it.
5. Keep the evidence. Save the planted set, the scores, and the receipts together with a date. The next audit compares against this baseline instead of starting from memory.

MCP prompt injection: when the tool itself is the attack surface

Classic prompt injection hides in content: a page, a file, a ticket. MCP prompt injection hides in the machinery. An MCP server supplies the tool names, the descriptions the model reads to decide how to call them, the parameters it fills in, and the results it reads afterward. Every one of those is text the model treats as context, which means a hostile or compromised server does not need to trick your agent into visiting anything. It is already inside the conversation.

The sharpest form is the tool poisoning attack: instructions planted in a tool description itself. The user sees a friendly tool name in a list. The model sees the full description, including any sentence that tells it to run an extra call first, copy context into a parameter, or keep an action quiet. A second form poisons results instead: the tool does honest work and returns a result with an instruction folded into it, aimed at whatever the agent does next.

Test both forms the same way you test a page. Before connecting a server, read and scan every description. In a test setup, give the tools harmless tasks seeded with canary values only you know, then read the full call record. A clean server produces calls that match the task. A poisoned one produces a call whose inputs came from the description or the result, not from you.

MCP server security risks: rogue servers, rug pulls, and the supply chain

Connecting an MCP server is a supply chain decision, whether it feels like one or not. You are adopting code and text you did not write, giving it a channel to your agent, and trusting it to stay the thing you reviewed. The failure modes worth planning for:

• Overbroad access. The server can do far more than the job needs, so one successful injection reaches further than it should.
• The rogue MCP server. It does not do only what it claims: it steers the agent toward calls it profits from, or quietly collects context in its parameters. Detection is behavioral: canary tasks, a full read of the calls it triggers, and a hard look at any appetite for context the task never needed.
• The MCP rug pull attack. The server behaves during review, then changes after approval, usually by editing a description or a result, so the agent starts doing something new under an approval the user gave to something else. The countermeasure is pinning and diffing: save what you approved, compare on a schedule and after every update, and watch the call record for patterns that were not there before.
• Silent drift across the chain. Servers, tools, and content sources all update on their own schedules. AI agent supply chain security in practice is an inventory you can list, a review before anything joins, a fresh scan and drill when anything changes, and receipts that show what each component did while it was trusted.

None of this requires paranoia. It requires the same record you already keep for the drill: what was approved, what ran, and what changed.

Prompt injection scanner vs test tool: filter and fire drill

A prompt injection scanner reads text before your agent acts on it and flags known injection shapes: instruction overrides, impersonated system messages, hidden directives, and requests to conceal actions from the user. Run one on every page, document, and tool description your agent is about to trust. Zambo prompt_shield is that check, and its result lands as a verifiable receipt like any other call, so a scan you ran last month can be rechecked today.

Know what a scanner cannot do. It matches patterns it knows. Fresh phrasing, encoded text, and an instruction split across two innocent looking sources can all pass a scan and still move an agent. That is why the scanner never replaces the behavioral test on this page: the scanner lowers how often the agent meets an attack, and the test shows what an attack that gets through actually costs. A setup passes when both layers agree: nothing flagged in the scan, and nothing obeyed in the drill. Either layer failing is a fail.

Secure AI agent tools: a working checklist

Secure AI agent tools are not a category you buy, they are a setup you enforce. The checklist that holds up in practice:

• Fewest tools, least access. Read before write, narrow parameters before open ended ones, and no tool the current job does not need.
• Descriptions reviewed like code. Read them fully, scan them, and re-read them after every update. Any sentence addressed to the model about behavior or secrecy fails review.
• Human decisions on consequential steps. Sends, writes, deletes, and payments wait for a person. In a Zambo handover that decision is recorded, so a skipped approval shows in the trail.
• Spend capped, calls receipted. A cap limits what a hijacked session can spend, and a verifiable receipt for every call makes the session auditable afterward.
• A way to stop it. Disconnecting a tool or a server should be one action, rehearsed before it is needed.

Prompt injection red team tools: build the drill kit

Prompt injection red team tools are how you stop testing only the attack you imagined first. A working kit has four parts: a payload library with varied phrasings planted across pages, documents, tool descriptions, and tool results; a controlled place to host that content so you know exactly what the agent read; a scanner pass, so you learn what your filter catches and what it waves through; and the call record, read after every run.

Rotate the payloads, because an agent that learns to refuse one phrasing has not learned to refuse the class. Rerun the full set after every model, prompt, or server change, and score each run against the last dated baseline. The kit does not need to be large to be honest. It needs to be varied, realistic, and run on a schedule instead of once.