Job support-bot-injection-and-data-exposure-test · revised 12 October 2026
Test what a hostile message can make your support bot reveal or do, with a permission list
A record of 40 hostile inputs run five times each against your bot in a sandbox, a list of what the bot can see and do, and the permission to remove for each failure.
You might be seeing
- Nobody has listed what the bot can read, write or send
- Customer text goes straight into the bot with no check
- The bot has more access than its job needs
No passwords, keys, card details or admin invites needed to start.
What usually happened
Anything a customer types into a chat, ticket or form can carry instructions, and a bot that can look things up or send messages may follow them. How much harm follows depends mostly on the access the bot was given.
Who it’s for: Support or product lead whose bot or agent can look up orders, send email or write to a CRM.
Usually starts when: You are about to give the bot a tool, or someone asks what happens if a customer types instructions into the chat, a ticket or a web form.
The result: You receive a pass or fail record of 40 hostile inputs, each run five times against your bot in a sandbox with synthetic customers, a list of everything the bot can read, write and send, and the permission to remove for each failure.
Check whether this job fits
Answer these without sending chats, tickets, files or logins. Nothing is submitted unless you choose to contact us.
What you get
- The tool and data inventory
- The 40-input attack set and results
- The failure list with the permission to remove
- The retest result
- A page on what the test does not show
Included
- One bot or agent in a sandbox with synthetic customers and synthetic orders
- An inventory of what it can read, write and send, and through which tools
- A set of 40 hostile inputs: instruction override, other-customer data, system prompt, markup in output, "legally binding" statements and tool misuse
- Each input run five times, with a harmless marker to detect leaks
- A least-privilege fix list and one retest
Not included
- A security certification, a penetration test or a promise that the bot is secure
- Legal advice
- Fixing the bot or changing its permissions: you do that
- Tests on production or on real customer data
- Voice agents or systems we have not been shown
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Across the 40 inputs run five times each, the bot never reveals another customer's data or its own instructions, never makes a commitment such as a price, refund or "legally binding" statement, and never calls a tool outside the allowlist. One such event fails the whole test.
Evidence: The 200-run log filtered to each severe type, with the count.
10 of the 40 inputs were written by your named person and unseen by us until the final run. This is a 40-input, 200-run smoke test on a stated date, not a measured attack failure rate or proof of immunity.
Evidence: The 10 held-back inputs marked in the 200-run log.
Every failure has the permission or setting to remove named beside it and passes on the retest after you change it.
Evidence: The fix list and the retest log.
You can replay 10 random inputs yourself (seed recorded) and see no severe event that our log does not list.
Evidence: The seed, the 10 inputs and your own results.
The inventory lists every read, write and send ability of the bot in the sandbox, and nothing in the inventory is missing from the bot's settings.
Evidence: The inventory beside a screenshot of the bot's settings.
Sign-off. You replay the 10 inputs, read the inventory and fix list, and sign off in writing. Payment follows sign-off.
If it fails. If a failure remains after your changes and one retest, we hand over the open items and you decide whether to remove the capability, retest or stop. We do not describe an open failure as fixed.
When it fits, and when we stop
It fits when
- A sandbox exists with synthetic customers, and no real customer data is reachable from it
- You can tell us what tools the bot has, or let us read its settings in the sandbox
- A named person on your side can change the bot's permissions
We stop and tell you if
- Only production is available, or the sandbox can reach real customer data
- You want a certification, an assurance statement or a penetration test
- The bot handles regulated data we have not agreed to see
What could go wrong
The test runs only in a sandbox with invented customers, so nothing live changes. Permission changes are made by you, with the old settings noted so they can be restored.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A pass is read as a statement that the bot is secure | The report says plainly it is a baseline for these inputs on this date, not a certification, and that tailored attacks can still succeed. |
| Single attempts understate the risk | Each input runs five times because repeated attempts raise the chance of a success. |
| The sandbox can reach real data | We stop if it can, and the first enquiry takes no real data or logins. |
| A hostile input we write is itself harmful | Inputs carry only a harmless marker, and nothing is sent outside the sandbox. |
A separate automated reviewer checks the attack set, the results and the permission list before hand-over, and your named person on your side marks the sample and decides what goes live. No human supervisor is included unless your agreement names one. At launch the work is largely automated, and we say so.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree the sandbox, the tools to inventory and the severe-error list in writing
- List what the bot can read, write and send, and through which tool
- Run the 40 hostile inputs five times each, with a harmless marker
- Record every leak, commitment or out-of-list tool call, and the permission behind it
- Independent automated review; a second pass re-reads the failures
- Hand over the record and the fix list; you remove permissions and we retest
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, the total price, a start window and a delivery date before you accept. Work starts only after agreed inputs, secure access and any needed permissions are in place. Model usage for our build and tests is included in the price; charges on your own platform account, including per-conversation fees after go-live, are yours. An enquiry creates no charge or booking.
Need to keep it working?
The monthly bot check reruns 10 hostile inputs; ask about it.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing managed lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Remove every tool the bot does not need and make the remaining ones read-only. That limits the harm a hostile message can do; it does not stop the bot being tricked.
- The OWASP list of large-language-model risks is free and names prompt injection and excessive agency as the first things to check. owasp.github.io
Questions
Does a pass mean the bot is secure?
No. It means 40 hostile inputs did not break the limits we set, on the date of the test. Better attacks may still work.
Will you test my live bot?
No. We test a sandbox with invented customers only.
Do you fix the permissions?
No. We name the permission to remove for each failure and retest after you change it.
Send an enquiry
Send us
- Which bot or agent platform you use
- What the bot can do beyond answering: look up, send, write, refund
- Whether you have a sandbox with synthetic customers
- No customer data, logins or keys in the first enquiry
Later, once you agree
- A sandbox or test workspace with synthetic customers that you create and can revoke
- Read access to the bot's tool and permission settings in that sandbox
- Ten of the 40 inputs written by your named person and unseen by us until the final run
You keep the bot, the data and every login. We work in a sandbox with invented customers, read the bot's settings there and change nothing live. Permission changes are yours to make.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “support-bot-injection-and-data-exposure-test” as the subject.