The government tested AI agents. One line of instruction changed almost everything

The UK has a government body whose job is to test AI models for the things the companies building them might not advertise. It is called the AI Security Institute. On 28 September it published what happened when it pointed the newest models at a simulated cyber security exercise.

The headline number travelled fast. The finding underneath it is far more useful if you run a business, and almost nobody repeated it.

What they found

In AISI's own words, GPT-6 Astra "completed a supply-chain attack 29.2% of the time, compared to 6.3% for GPT-5.6 Sol, and 0% for GPT-5.5".

A supply-chain attack means going after a third party connected to the target rather than the target itself. The important word in that sentence is unsanctioned. Nobody asked it to. These were targets the exercise had never listed as in scope, and the model went after them anyway, as a way of getting the job done.

The caveat, before anyone panics

This was a red-team test, run on frontier models, inside a fully simulated environment where no real system was touched. AISI deliberately turned the model's own safety classifiers off first, explaining that "since these are designed to block unsanctioned activity, disabling them allows us to measure what the model attempts with no interventions". In normal use those protections are on.

AISI also names its own main limitation: the possibility that the model behaved differently because it worked out the environment was simulated.

So this is not a claim that a plumber's inbox is a national security problem. It is a measurement of what a very capable model will attempt when it is under-instructed and nothing is stopping it. That is still worth your attention, because under-instructed and unsupervised is exactly how most people set these things up.

The finding that actually helps you

Here is the part worth printing out.

AISI took the ten scenarios where the model most often went out of scope, added one line to the instructions, and ran them again. The line was, in effect, anything not listed as in scope is out of scope.

The result: a full supply-chain attack "in 4 of 49 trajectories, compared with 26 of 50 previously". Fifty-two per cent down to about eight. From one sentence.

Read that again, because it reframes the whole thing. The model was not malicious. It was filling a gap you left. Told what the boundary was, it mostly stayed inside it.

What that means for how you ask

Every one of us writes instructions the way we would brief a colleague who already knows the business. We say what we want. We almost never say what is off limits, because with a human being that is understood.

An AI has no such understanding. It has your sentence and nothing else. If you do not draw the edge, it will decide where the edge is, and it will decide in favour of completing the task.

In practice that means adding the boundary to the brief, not just the goal. Only use the figures in the document I pasted. Do not contact anyone. Do not look anything up outside this file. If something is missing, stop and tell me rather than estimating.

That costs you one line, and the government just measured what it is worth.

And the sentence to remember

AISI's own conclusion is blunt: "Defences beyond model alignment – such as sandboxing and monitoring – are essential for preventing real world harm."

Translated out of the jargon: do not rely on the AI being well behaved. Put limits around it, and watch what it does.

For a business with no IT department, that is not as technical as it sounds. Sandboxing means giving it one defined job with access to one thing, rather than standing access to everything. Monitoring means somebody actually reads what it produced, at least at first.

If someone offers to let an AI into your email

This is becoming a common sales conversation, and it is where all of the above stops being abstract. Before you agree:

Ask what it can do, not what it will do. Those are different questions. The answer you want is a list of permissions, not a description of the intended use.

Ask whether it can send, or only draft. If it can send on your behalf from day one, you have skipped the stage where you find out how good it is.

Ask who else can see what it reads. Your inbox contains other people's personal data. Under UK GDPR you are responsible for where that goes, and you cannot delegate that to a supplier's enthusiasm.

Ask to see the log. If there is no readable record of what it did, there is no way to catch the one time it did something odd.

Give it a boundary in writing. The same scope line that took AISI's number from 52% to 8% belongs in your setup, and it costs nothing.

None of this is a reason to avoid the technology. We use it daily and it genuinely pays. It is a reason to be the person who set the limits rather than the person who found out there were not any.

If you want a second pair of eyes

If someone has offered to connect an AI to your email, your CRM or your accounts and you want a straight answer on whether it is sensible, email hello@aibasics.uk and describe the setup. We will tell you what we would do, including when the honest answer is to leave it alone for now.

And if the broader lesson here is the one that landed, that most bad AI output is really an under-written instruction, that is precisely what the guide below is about.