Break it before someone else does.

Your AI system has been tested by people who wanted it to work. It has not been tested by anyone who wanted it to fail.

In short

AI red teaming is adversarial testing of an AI system. Rather than checking that it does the right thing when used properly, you find out what it does when someone is deliberately trying to make it misbehave: leak records it should not return, follow instructions hidden inside a document, or use a connected tool in a way nobody intended.

We test the deployment rather than the model. The model was tested by the company that made it. What has never been tested is your version of it: your data, your permissions, your connected tools, your customers. Three weeks, from $35,000, and you get the fixes rather than a list of problems.

01 The gap

Two things get called AI security. Neither is this.

A scanner
  • Runs a library of known attacks against your model
  • Finds the ones that are already public and already patched
  • Knows nothing about which of your records it reached
  • Cannot tell you whether a finding matters at your company
  • Sold as a subscription to a dashboard somebody has to watch
An audit
  • Reviews your policies, your documentation and your controls
  • Maps you against a framework and scores you
  • Rarely touches the running system
  • Ends in a report and a set of recommendations
  • Leaves the engineering work to whoever you have spare

Both are useful and neither answers the question a chief executive is actually asking, which is whether this thing can be made to embarrass us. That question is answered by people who build these systems, attacking one they did not build.

02 Method

What we try to make it do.

01 Instructions
from outside

Prompt injection

Your system reads things that other people wrote: support tickets, emails, invoices, CVs, web pages, rows somebody typed into a form. A model has no reliable way to separate the instructions you gave it from instructions buried in the text it is reading.

The version that matters is the indirect one, where nobody at your company typed the payload and nobody at your company will see it. A sentence sitting in a PDF that has been in your document store for a year is enough.

  • Instructions hidden in documents, tickets and email the system ingests
  • Text that is invisible to a human reader but not to the model
  • Payloads that survive summarising, translation and retrieval
  • Attacks that only fire on the second or third turn of a conversation
02 What it
can reach

Data it should not return

Almost every leak we find comes from the same mistake: the system was connected to a data source with wider permissions than the person asking it questions. It works correctly for months, because nobody thought to ask it for somebody else's records.

We ask. We also check what it will reconstruct rather than retrieve, which is the failure people miss, because the answer was never in any single document.

  • Records belonging to other customers, departments or regions
  • Retrieval that ignores the permissions of the person asking
  • Fragments of source data recovered from the way it answers
  • Credentials, keys and internal instructions repeated back on request
03 What it
can do

Tools and agents

The moment a system can act rather than only answer, the question changes. It can send the email, update the record, refund the order, call the API, spend the money. Every tool you connect is a new thing an attacker is trying to reach through the model.

What we are testing is not whether the model is clever. It is whether anything downstream checks. In most deployments we look at, the tool trusts the model completely, because the model is internal and internal things are trusted.

  • Talking the system into calling a tool on somebody else's behalf
  • Chaining permitted actions into one nobody would have permitted
  • Reaching systems the model was never meant to touch
  • Spending money, whether through fraud or simple cost exhaustion
04 What breaks
downstream

Everything that trusts the answer

Model output gets written into databases, rendered in browsers, passed into scripts and read by other systems. Each of those treats it as trusted content, because it came from inside.

This is where an AI problem turns into an ordinary security problem, and it is usually the one with the shortest path to real damage.

  • Output rendered without escaping, in your own staff tools
  • Generated code and queries executed without review
  • Guardrails that pass the test suite and fail a determined person
  • Behaviour that changes the day the vendor updates the model

The structure follows the OWASP Top 10 for Large Language Model Applications and MITRE ATLAS, so findings map onto the frameworks your auditors and your customers already ask about, including NIST AI RMF, ISO/IEC 42001 and the EU AI Act.

03 Deliverable

You get the repairs, not the list.

We do this
  • Attack the system in your own environment, against your own data
  • Write findings your board can read, with what each one would cost you
  • Give reproduction steps, so your team can confirm every claim
  • Build and deploy the fixes, then attack it again to prove they hold
  • Retest whenever the model, the prompts or the connected tools change
We do not
  • Sell you a scanner, a platform or a dashboard subscription
  • Test whether the model vendor built a safe model, which is their job
  • Certify you as compliant, because we are not your auditor
  • Grade your policies without touching the running system
  • Hand over a report and leave the engineering to you
Three weeks One system, start to finish, including the fixes and the retest
From $35,000 Fixed before we start. Continuous testing after that is $12,000 a month
Your systems Tested where it runs, inside your environment and your country
04 Fit

When this is worth doing.

[1]

It talks to customers

Anything a member of the public can type into. The attacker does not need access to your network, only to your product.

[2]

It can act

It sends, books, refunds, updates or spends. Systems that only answer questions are a smaller problem than systems that do things.

[3]

It reads your records

It has been pointed at a document store, a database or a mailbox that holds more than any one user is entitled to see.

[4]

Somebody is asking

A regulator, an enterprise customer's security review, or a board that has read enough news to start asking whether yours is safe.

If none of those describe your system, say so and we will tell you it can wait. We would rather do that than sell you three weeks you did not need.

05 Questions

Before you get in touch.

How is this different from a penetration test?

A penetration test looks for flaws in software that behaves the same way every time you run it. An AI system does not. It can be persuaded, and the same input can produce a different result on a different day, which is why the work is adversarial rather than a checklist. If you have a conventional application around the model, you still want a conventional test of it. This is the layer that one misses.

Are you testing the model or our system?

Your system. Whether the underlying model can be jailbroken in the abstract is a question for the company that trained it, and the answer is usually yes to some degree. What matters is what a jailbreak reaches once it happens inside your deployment, which depends entirely on your data and your connected tools.

What access do you need?

A working account like a normal user has, and a conversation with whoever built or bought the system. More access finds more, so we usually ask for a look at how it is wired together, but we can start from the outside with nothing but the product itself if that is where you would rather begin.

What happens if you find something serious?

You hear about it that day, not in the report. Anything we judge to be live and exploitable is raised immediately with whoever you name at the start, along with what to do in the meantime if the fix is going to take longer than an afternoon.