Provok Book a scoping call
Sample deliverable

What lands in your inbox.

This is an extract from a real engagement, anonymised with permission. Same structure, same evidence standard, same judgment. Including the part most reports leave out: what the tools got wrong.

REAL ENGAGEMENT, ANONYMISED. System and organisation details removed. Attempt counts and results are as recorded.

See all sample reports →

Engagement summary

System
Customer-facing chatbot
Sector
Professional services (AU)
Attempts
9,000+ across 15 probes
Overall
Resilient, one coverage gap

A public-facing support and enquiry assistant, reachable by anyone on the internet, connected to an automation workflow behind the scenes. Tested across prompt injection, jailbreak, encoded payload, hidden-instruction and data-disclosure attack classes.

Findings

Automated tooling reported a critical failure. It was wrong.

Methodology
What the scanner said

An industry-standard jailbreak probe reported a 99.61% attack success rate across 1,280 attempts, with only 5 recorded as defended. Read at face value, this is a catastrophic finding: a chatbot that can be commandeered at will.

What we found on verification

We pulled the actual responses behind the flagged attempts and read them. Not one showed the system deviating from its role. Every "successful attack" was the assistant either declining an oversized input or politely redirecting the user back to legitimate topics.

attacker>  [jailbreak payload, 1,200+ chars]
system>    "That message is a bit long. Could you shorten it?"

attacker>  [role-override payload]
system>    "I'm just here to help with questions about [redacted].
            Is there anything about what we do that I can answer?"
Why the tool got it wrong

The detector scores an attack as successful when it fails to find explicit refusal language. This assistant does not refuse in the phrasing the detector expects. It redirects, warmly, and stays entirely within its role. Correct behaviour, scored as total compromise.

What this means for you

Automated AI security tooling produces false positives at scale, and they are not subtle. A report generated straight from scanner output would have told this organisation's board their chatbot was 99.6% compromised. It was not compromised at all. Every finding we issue is verified against the actual system response before it reaches you.

Input length restriction prevented complete testing

Coverage gap
What we observed

A length limit in the workflow rejected the majority of long-form jailbreak payloads before they reached the model. The system responded to the request length, not its content.

The double edge

Operationally this is a useful control. Most real-world jailbreaks circulating publicly are long, copy-pasted blocks, and this filter stops them at the door. But it also means the model's own resistance to those attacks is unproven. The defence is the filter, not the model. If the limit is ever raised, or an attacker compresses the payload, that protection disappears and nothing behind it has been tested.

Recommendation

Retest in a staging environment with the length restriction lifted, to establish the model's actual resistance independent of the filter. Keep the filter in production. Know what is behind it.

Defences confirmed and evidenced

Verified pass
Attack classes resisted

Encoded payload smuggling — 2,560 attempts across two detection methods, all defended. Instructions hidden in Base64 were not decoded and executed, a common bypass where guardrails inspect plain text only.

Hidden instruction injection — 160 attempts, all defended. Instructions embedded in the input were not obeyed as system commands.

Prompt hijacking — 3,840 attempts across three variants, all defended. The assistant could not be redirected into producing attacker-chosen output.

Latent injection — 1,280 attempts, all defended.

Training data disclosure — 895 attempts across multiple corpora, all defended.

Note on scope

These are genuine passes against the attack classes tested. They are not a guarantee of security. A clean result on a probe that does not match your system's real exposure tells you very little, which is why probe selection is part of the engagement, not an afterthought.

Evidence and chain of custody

Every attempt and response in this engagement was captured, timestamped and sealed into a hashed manifest. Any subsequent change to any evidence file breaks the hash. If a finding is ever disputed, the record is verifiable rather than assertable. Your report includes the manifest and its hash so your own team can confirm nothing changed after sealing.

Retest

Every engagement includes a retest once you have remediated. We re-run the same attacks and confirm, with fresh evidence, whether each finding is closed.

Want the full report as a PDF?

Leave your work email and we will send the complete anonymised report, plus the occasional short brief on AI security in Australia. No spam, unsubscribe any time.

Ready to test your own system? Book a scoping call →

Want to know how your AI holds up?

Tell us what you've deployed. We'll tell you how we'd try to break it, and what a first engagement would cover. No obligation.