Break it

AI Security

Adversarial testing for language models and the systems that let them act. We assess the whole deployment — the prompt, the index, the tools, and the cloud account underneath — because that is the surface an attacker actually gets.

Scope an engagement

Engagements from £14,000. Or start with a Exposure Review from £4,500.

What an engagement looks like

Scoped as fixed-window work with a written deliverable. No retainers you cannot exit, no findings held back for a follow-on sale.

Method

Single-shot probes prove very little.

Most published jailbreaks are one clever message. Real compromise is rarely one message — it is a position built over a conversation, or planted in a document the model will read next week, or assembled from three tool calls that are each individually permitted.

So testing is chained and stateful by default. We work the system the way someone with a motive and a fortnight would, and we report the path, not just the payload.

  1. Map the input surface

    Every channel that reaches the context window. Filenames, document bodies, tool responses, retrieved chunks, and user text — ranked by how little they are trusted today.

  2. Establish baseline behaviour

    What the system does when nothing is adversarial, so that deviation is measurable rather than anecdotal.

  3. Chain and escalate

    Compose findings. A weak injection plus an over-scoped tool plus a retry loop is a different severity than any of the three alone.

  4. Hand over the harness

    Test cases are delivered as runnable code against your endpoint, so the fix can be verified and the regression caught.

Questions we get asked

How is this different from a standard penetration test?
A conventional pentest treats the application as the system under test and the model as an opaque dependency. We treat the model, its context window, its tools, and its infrastructure as one system — because an attacker does. Findings that only appear when you chain a prompt-level trick to a cloud-level misconfiguration are the ones that get missed by teams that only own one half.
Do you need access to model weights?
No. Most engagements are black- or grey-box against a deployed endpoint, which is the attacker’s actual vantage point. Weight access, training data, or fine-tuning history helps for alignment evaluation and lets us reason about why a behaviour occurs rather than only that it does — but it is never a precondition.
Will testing damage production or pollute our data?
Scope, rate limits, and data handling are agreed in writing before anything runs, and we default to a staging environment mirroring production configuration. Where production is genuinely the only meaningful target, we agree explicit blast-radius limits and a rollback path first. Any data encountered is handled under the engagement’s NDA and destroyed on completion.
What do we actually receive?
A written report with reproducible proof-of-concept for every finding, severity rated against exploitability in your deployment rather than a generic scale, and remediation guidance specific to your stack. Plus the harness — the test cases become yours, so regression testing does not require hiring us again.
Do you publish what you find?
Never client work without written permission, and never with identifying detail. Novel techniques that are not client-specific may be written up generically for the research surface, always after remediation and always with the client’s sign-off on the wording.