A framework for running AI safely
Governance decides what AI should do. Security verifies what it actually does.
Most organisations have the first. Few have the second. That gap is where the failures live.
Control frameworks and crosswalks are point-in-time snapshots; see the date on each. Verify current regulatory requirements against official sources.
Before any of it
A cheaper question comes first: is generative AI even the right tool for this? Point a stochastic model at a task that needed a deterministic one and you take on a class of runtime risk you could have designed out. The most effective control is the one you never had to build.
Should you use AI at all? →The gap
Two different jobs, often mistaken for one.
Governance
Asks: what is this AI allowed to do?
Policies, accountability, and audits set the intent. They decide the rules, but they cannot enforce them in the moment.
Runtime security
Asks: is it doing that, right now?
Live controls catch the prompt injection mid-request, check the output before users see it, and halt the agent that goes out of bounds.
Your policy says the model must not leak data. Runtime security is what actually stops it.
How it works
Three layers a request passes through, and a breaker behind them.
Each control layer works on its own. If one fails, the others still hold, and a circuit breaker contains what gets through. Start in detect-only, then turn on enforcement when you trust it.
01
Guardrails
Fast, fixed boundaries that block the obvious failures at machine speed.
02
Reviewing controls
A second look at the output before it reaches a user, catching the subtle failures guardrails miss.
03
Human oversight
A person in the loop for high-stakes calls. The bigger the consequence, the closer the watch.
Failsafe
Circuit breakers
Containment, not a behavioural layer. Halts the AI and switches to a safe fallback when the three layers are bypassed or overwhelmed.
For your role
Where do you fit in?
Three ways in. Each one starts where your job starts, and tells you what to do first.
Set the strategy
Is the board confident our AI controls actually work?
Security leaders · Risk & governance · Compliance · CIOs
Design & build
Where do the controls go, and what do they cost?
Enterprise architects · AI engineers
Own the product
What do we need in place before we can ship?
Product owners · Business owners · Insider-threat teams
One idea underneath it all
A surprising number of AI attacks are the same event in disguise: untrusted content, tools, memory, or borrowed authority treated as trusted instruction instead of as data to be checked. Hold that line, and a long list of named threats collapses into a handful of problems you can actually get your arms around.
Read the idea in full →Before runtime
Runtime security begins the moment a system goes live, but how safe it can be is largely decided earlier: which model you trust, which platform you build on, how the thing is shipped and governed. That is the other half of the lifecycle, and it has its own companion framework.
AI Secured by Design: securing AI before deployment →Insights & news
The thinking, and what's happening.
Short reads on why runtime security works, and a running record of real incidents mapped back to the framework.
Insights
The evidence behind the framework: why pre-deployment testing isn't enough, why guardrails leak, and what actually holds in production.
Read the insights →News
A biweekly roundup of incidents and research, each item tagged with the AIRS controls, layers, and domains it touches.
See the latest →The Golden Thread
A guided two-hour path from why runtime security? through which controls? to how do they improve over time?
Follow the thread →Ship your first AI feature safely.
Seven controls. One checklist. One decision on whether you need to go deeper.