Getting an AI agent to do what you want is not a prompting problem

You have to turn intent into a system: specification, architecture, authority, validation, testing, human oversight, monitoring, intervention and accountability.

And then you need evidence that those things actually work when the agent is running.

We wanted to make that practical.

Not another set of principles. Not another maturity model. Actual controls that can be applied to a specific agentic system and tested.

So we built a catalogue of 113 controls across 16 control families, covering the lifecycle from purpose and specification through architecture, tools, runtime behaviour, testing, human oversight, security, monitoring, recovery and governance.

The underlying ideas are deliberately not ours.

The catalogue consolidates existing work from NIST, ISO, the EU AI Act, Cloud Security Alliance, OWASP and the major cloud and model providers. It also references regional instruments from Singapore, South Korea, Japan and China.

It also gives specific treatment to the EU AI Act, rather than treating it as just another source in the bibliography.

The work was in turning that scattered material into something operational.

Every control answers essentially the same questions

• What are we trying to control?
• How should it be implemented?
• How do we test it?
• What evidence proves it?
• What does it not protect against?
• What other controls does it depend on?

Sheet 07 · Principles §6 Overarching Principles

Principles of effective agent control

The catalogue contains individual mechanisms. These are how you combine them into something that holds.

Read the fifteen principles as text

Defence in depthDo not depend on one prompt, one guardrail, one reviewer or one policy.

Hard boundaries need hard enforcementIf an outcome absolutely must not occur, enforce it in permissions, not in wording.

Authority proportional to consequenceThe more consequential the action, the stronger the permission and the review.

Least privilege by defaultOnly the access required for the current task, for the agent and every delegated identity.

Separate generation from verificationDo not let one probabilistic path be the only judge of its own output.

Make uncertainty actionableDefine when uncertainty triggers clarification, abstention or escalation.

Fail safely, prefer reversible actionsDesign for deny, queue, draft, stage, pause, rollback or compensate.

Make important behaviour observableA control that cannot be evidenced or reconstructed is hard to rely on.

Test controls, not only agentsVerify the mechanism itself blocks, detects or recovers from what it claims to.

Assume correlated failureTwo agents, two prompts or two model judges may share one blind spot.

Human oversight must be meaningfulApproval is weak if the reviewer lacks the time, information, expertise or authority to disagree.

More autonomy requires more assuranceFreedom, permissions, persistence and delegation all raise the bar.

Conventional security still appliesAgent controls add to identity, network and vulnerability management — they do not replace them.

Change can invalidate prior assuranceModel, prompt, policy, tool, data and vendor changes all alter behaviour.

Treat the framework as livingNew architectures, failures, attacks and regulatory readings will keep arriving.

Then something interesting happened

We realised we had designed it for the wrong reader.

We had been writing a control framework for a person with a PDF.

But the characteristics that made the catalogue useful — stable control IDs, a fixed schema, applicability metadata, explicit tests and evidence requirements — also made it machine-executable.

So perhaps the best way to use the control framework isn’t to read it.

Give it to an agent.

The design we’re now building around it is effectively a Chief Risk Officer agent.

Describe the system, its purpose, data, architecture, tools and degree of autonomy.

The CRO agent determines which controls apply to that particular system.

It then assesses them:

• What’s in place?
• What’s missing?
• Where is the evidence?
• Which tests have passed?
• What residual risk remains?

Instead of a control framework sitting in a folder, it becomes something that can actively assess the system it governs.

That also changes the role of governance documentation.

Things like control applicability, delivery stage, autonomy level, assessment intake and regulatory mappings stop being appendices nobody wants to read.

They become inputs to the governance engine.

But I think there is an interesting shift here:

AI governance may increasingly be performed by AI — with humans governing the governance.

And then we asked the obvious question:

What happens when we point it at our own agent systems?

That’s the next post.

Take it

The catalogue is published under CC BY. Take it. Adapt it. Use it in your own work. We hope that it will be as valuable to you as we have found it ourselves.

The catalogue is the control detail. For the operating model those controls sit inside — six maturity phases and twelve capability domains — see Enterprise AI at Scale.

For how to compose and run a team of people and agents, see Making Multi-Agent AI Work.

Agentic AI · AI Governance · AI Assurance · EU AI Act

Built from post 01 · docs/89 · 2026-09-15 · catalogue v1.0