AI Red Teaming and the UK Code of Practice: What Principle 9 Now Expects You to Test

01 What the UK now expects

That standard turns the Code's 13 principles into 72 trackable provisions across five lifecycle phases, from secure design to end of life [ NCSC 2025 ] . The NCSC and DSIT wrote the precursor guidance the whole standard rests on. So the UK Code is not a local curiosity. It is the reference document that the rest of the world is now building on, which means UK organisations are being measured against a bar they helped set.

02 Principle 9, in plain terms

Principle 9 is titled "Conduct appropriate testing and evaluation". Three of its requirements matter to whoever owns AI risk in your organisation.

Requirement 9.1 is the obligation. Developers shall ensure that all models, applications and systems released to operators or end-users "have been tested as part of a security assessment process" [ DSIT Code of Practice 2025 ] . Not reviewed. Not documented. Tested. Requirement 9.2.1 then names who should do it: "independent security testers with technical skills relevant to their AI systems". Requirement 9.4 adds the model-theft angle: evaluate outputs so users cannot reverse-engineer the non-public parts of the model or its training data.

Read those together and the shape of the expectation is clear. Security test the AI before it ships. Use testers who did not build it. Cover the AI-specific failure modes and the infrastructure they run on. That is a precise description of an AI red team engagement.

03 AI red team vs pen test vs evaluation

Three activities get filed under "we tested the AI", and they are not the same. Buying the wrong one is how organisations end up compliant on paper and exposed in production.

04 Why 'independent' is the word that matters

The Code did not say "test your AI". It said use independent testers. That word is doing real work, and the UK government follows its own advice at the highest level.

The AI Security Institute, the state-backed body set up to evaluate frontier AI, runs a dedicated red team. For over two years it has adversarially tested the misuse safeguards on models from the major labs, deliberately breaking them so the developers can find and fix the flaws, and it does this before those models are deployed [ AI Security Institute ] . The point of that arrangement is independence. The people who build a model cannot be the only ones who decide it is safe, because they share its blind spots.

The same logic applies one level down, to you. Your engineers built your AI feature to work. They tuned the prompts, chose the guardrails, and know what it is supposed to do. That knowledge is exactly what stops them seeing how it breaks. An attacker does not share their assumptions, and neither should the team that tests it. Independent AI red teaming is not a compliance nicety. It is the only version of the test that finds what your own team cannot.

05 What to test this quarter

You do not need a statute to start. If you have shipped an LLM feature, an agent, or an AI copilot, Principle 9 already describes what good looks like. Here is how to meet it.

Start with an inventory of every AI system that touches a customer or a decision, and for each one write down what it can read, what tools it can call, and what it is permitted to do. Then have an independent team attack the one with the most reach: attempt prompt injection through the content it ingests, try to make it misuse its tools, and see whether it will leak data it holds. Fix what opens, and retest.

That is the work we do. We red-team your AI system the way an attacker would, map the exploit paths, and hand you a prioritised fix list your board, your FCA reporting, and your Principle 9 evidence can all stand on. One clear outcome, before an attacker finds the gap first. Get a free audit and see exactly what your AI exposes.