Testing AI Tools for Prompt Injection Exposure Before Staff Paste Work Into Them
Most small teams evaluate AI tools by asking whether the output looks good. That question misses a quieter risk: when a tool reads content from outside sources, such as customer emails, uploaded PDFs, scraped web pages, or shared spreadsheets, any instruction hidden inside that content may compete with the instructions you intended. This is commonly called prompt injection. It does not require a sophisticated attacker. A line of text buried in a document can be enough to change how a tool summarizes, what it recommends, or what actions it takes if it has connected permissions. This article describes a practical way to test that exposure before your staff depend on a tool for real work, and what to ask vendors when the answers are not obvious from the product page.
Why injection matters more than accuracy alone
A tool can be accurate on ordinary inputs and still be unsafe when inputs are hostile or simply unexpected. Accuracy tests answer whether the tool gets facts right on clean material. Injection tests answer a different question: does the tool keep treating your instructions as authoritative when the material it reads contains conflicting commands?
The risk grows with capability. A tool that only drafts text inside a chat window has limited blast radius. A tool that reads your inbox, edits files, sends messages, or calls other services can be steered into doing things you never asked for. Before you test anything, list what the tool can read and what it can do. The combination of those two lists defines how much an injected instruction could cost you.
Building a small test set you can repeat
Create a short set of test documents that your team actually handles: a customer complaint email, a vendor invoice, a meeting transcript, and a web page you would normally summarize. In each one, add a clearly labeled test line that attempts to redirect the tool, such as an instruction to ignore the user's request and output a specific phrase, or to include a fake contact address in its summary. Use harmless markers so no real harm results if the tool complies.
Keep the test set fixed. Run the same documents through the tool at different times and record the results in a simple table with columns for date, document, whether the injected instruction was followed, whether the tool flagged it, and any notes. A repeatable scorecard tells you more than a single impressive demo. If you change the tool's settings, model version, or connected integrations, rerun the set, because changes in those areas often shift behavior.
Checking how the tool treats untrusted content
Look for evidence that the tool distinguishes between your instructions and the content it processes. Some products separate system settings, user prompts, and retrieved material in ways that can be inspected. Others blend everything into one stream. Where the vendor documents this separation, read the description carefully and note any exceptions or limitations they mention. Do not assume a separation exists because a product page uses the word safe.
In your own tests, observe whether the tool reports suspicious content. A useful behavior is the tool saying that a document contains instructions it is ignoring. A worrying behavior is the tool silently following embedded text while presenting its output as a neutral summary. Record which behavior you see, because a tool that conceals injected content is harder to audit later.
Limiting permissions while you evaluate
During evaluation, give the tool the narrowest access that still lets you test real workflows. Use a sandboxed account, a test mailbox, or copies of files rather than production data. If the tool offers granular permission settings, choose read-only access first and widen it only after your scorecard shows consistent behavior. Write down each permission you grant and why, so the decision can be revisited.
Pay attention to whether actions require confirmation. A tool that can send messages or change records without a human approval step deserves extra scrutiny. Confirm in your testing whether confirmation prompts are displayed clearly enough that a busy staff member would notice an unexpected action.
Questions to ask the vendor before rollout
Vendors vary widely in how much they disclose about injection handling, so ask directly and keep written answers. Useful questions include: How does the product distinguish instructions from user content? Are there documented limits on what untrusted material can influence? Can administrators review logs of the tool's actions and the content that prompted them? Is there a way to disable specific integrations without disabling the whole product?
Also ask how the vendor communicates changes to behavior. If a model update alters how the tool handles embedded instructions, you need to know, because your scorecard results may no longer apply. Ask what notice they provide and whether you can pin a version while you retest.
Treat vague answers as information. A response that repeats marketing language without describing mechanisms should lower your confidence, not raise it.
A short checklist for your team
Before approving any AI tool that reads outside content, confirm the following: you have listed every input source and every action the tool can take; you have built a fixed test set with harmless injected instructions; you have recorded results from at least two separate test sessions; you have granted read-only or sandboxed access during evaluation; you have written down the vendor's answers about instruction handling and logging; and you have assigned one person to rerun the scorecard after any update or integration change.
This process will not guarantee that a tool is immune to manipulation, and no article can substitute for your own testing against your own data. It does give your team a defensible basis for deciding how much trust to place in a tool, and a record you can revisit when conditions change. Start small, keep the permissions narrow, and expand only when the evidence supports it.