How to adopt an AI security framework that actually changes anything
Choose an AI security framework that fits what you need it to prove, map it against the agents you actually run, and turn it into owned controls rather than a binder.
Before you start
- An agent inventory honest enough to do gap analysis against — aspirational inventories produce aspirational compliance
- A view on who the framework's output is for: your engineers, your auditors, or your regulator
- A sponsor who owns AI risk and can assign control owners
Steps
- 1
Decide what you need the framework to do
Frameworks serve three different masters, and choosing without deciding yours is how binders happen. Engineering teams need threat-shaped guidance they can build against. Auditors need a certifiable management system that produces evidence. Regulators need demonstrable alignment with whatever your jurisdiction requires. Write down which of these is the forcing function — it determines the shortlist, the owners, and what done looks like.
- 2
Shortlist against that purpose, not against popularity
The major candidates split cleanly by purpose. NIST's AI Risk Management Framework structures organisational risk practice. ISO/IEC 42001 defines a certifiable AI management system — the one an auditor can attest. OWASP's LLM Top 10 and its agentic security work give engineers concrete threats and mitigations, and MITRE ATLAS catalogues adversarial techniques for threat modelling. Most organisations end up pairing one organisational framework with one engineering source rather than choosing a single winner.
- 3
Map it against the agents you actually run
Take your agent inventory and walk it through the framework's controls: which are already met, which exist but produce no evidence, which are absent. The unit of analysis is each agent's risk profile — what it can write to, what credentials it holds — not the organisation in the abstract. The gaps that surface against your highest-blast-radius agents are the roadmap; gaps against hypothetical future agents are not.
- 4
Extend it to cover the agentic gap
Most AI security guidance was written for models that produce content, not systems that take actions, so check explicitly whether your chosen framework covers the agent-specific surface: per-agent identity, tool-level permissioning, prompt injection through operational content, runtime gates on consequential actions, and revocation. Where it is silent, write the supplementary controls yourself and version them with the framework mapping — the auditors will ask how you handled what the standard missed.
- 5
Assign every control an owner and a cadence
A control without a named owner and a review date is a sentence in a document. For each control in scope, record who operates it, what evidence it emits, and how often it is checked — then publish the list where the owners can see their names. This step is where adoption either becomes real or quietly dies; treat resistance here as information about which controls are wrong, not just which teams are slow.
- 6
Wire evidence collection into the runtime
The frameworks all eventually converge on the same demand: show us what your agents did and prove the controls operated. If your audit trails, approval gates, and identity logs are designed to emit framework-shaped evidence as a side effect of running, compliance becomes a query rather than a quarterly archaeology project. This is the payoff of doing the security work first and the framework second — the evidence already exists.
Common pitfalls
- Framework-as-binder: adopted at the steering committee, never translated into controls anyone operates. The tell is a framework with no named control owners six months in.
- Choosing the certifiable framework when the actual need was engineering guidance — ISO certification does not stop a prompt injection, and OWASP guidance does not satisfy an auditor. Mismatched purpose wastes a year.
- Assuming LLM-era guidance covers agents. Content-generation risk and action-taking risk are different surfaces; a framework can be fully implemented and still silent on what your agents can write to.
- Gap analysis against the org chart instead of the agent inventory — the controls end up owned by departments while the risks are carried by specific agents nobody mapped.
- Evidence theatre: screenshots assembled the week before the audit. If producing evidence takes effort, the controls are not actually wired into the runtime.