Start to finish, this is how a Range Assessment runs, using a fictional organisation so you can see the whole shape of it before you ever pick up the phone.
Meet Southbank Health, a fictional mid-size Australian health insurer. They launched an AI support assistant to answer member questions about claims and cover. It takes free-text input from members, reads from internal policy documents, and can look up a member's claim status through an internal tool. It went live in eight weeks. Nobody outside the build team has ever tried to break it. Here is how we would.
A short scoping call. We agree the assistant's staging endpoint is in scope and production is not. We sign the engagement pack and rules of engagement, and Southbank provides a staging URL and a least-privilege test account. Test window: five business days. Nothing is touched before this is signed.
The Range runs the OWASP LLM Top 10 against the assistant, automated tooling plus analyst-directed attacks, in an isolated and fully logged environment. Every attempt is captured as evidence. Three representative findings emerge.
OWASP LLM01 (Prompt Injection), LLM06 (Sensitive Information Disclosure)
A crafted message convinced the assistant to return another member's claim details. One member could read another member's private health and financial information.
OWASP LLM08 (Excessive Agency)
The assistant triggered a claim-status lookup for an arbitrary member ID without verifying the requester's identity. The tool ran with more authority than the conversation warranted.
OWASP LLM07 (Guardrail Bypass)
A multi-turn framing pushed the assistant into giving definitive coverage "advice" it was explicitly not meant to give, creating compliance and reputational exposure.
A separate analyst writes up the findings, severity-rated and evidence-backed, mapped to the OWASP LLM Top 10 and the obligations Southbank answers to, including the Privacy Act and APRA expectations. Each finding carries clear remediation direction. The report has a board-readable summary and engineer-actionable detail. The team that ran the attacks does not write this report.
Southbank's own engineers fix what we found: identity verification moves server-side, state-changing tool calls require explicit confirmation, cross-member data access is removed, and conversation-level monitoring is added so guardrails hold across a whole exchange, not just single messages. We stay independent of the fix.
We re-run the same attacks. The Critical and High findings are confirmed closed. The Medium is partially resolved, so we document the residual risk and advise the next step. Every conclusion is backed by fresh evidence.
About three weeks elapsed, most of it Southbank's own remediation time. They now hold a retested assurance report they can hand to their auditor, their board, and their procurement team, a fixed set of real vulnerabilities closed, and evidence of due diligence if anyone ever asks. That is what a Provok engagement leaves behind.
Ready to run this on your own system? Book a scoping call →