AI risk management frameworks for agentic systems

For agentic systems they matter less as documents to comply with and more as a shared vocabulary that lets security, legal and engineering describe the same control once.

Most agent programmes do not fail because they lack a framework. They fail because four teams each bring a different one and nobody maps them together, so the same control is designed three times and measured never.

Why do AI risk management frameworks matter for agents now?

Agent investment is now decided partly on risk evidence. Gartner expects over 40% of agentic AI projects to be cancelled by the end of 2027 because of escalating costs, unclear business value or inadequate risk controls (Gartner). A framework that produces usable evidence is a delivery tool, not a compliance tax.

Adoption is the reason the evidence has to scale. In the 2026 Stack Overflow survey, 73% of respondents used coding assistants and agents daily and 31% of daily users spent four or more hours a day with them (Stack Overflow Developer Survey 2026). A framework that assumes a review board per system will not cover a fleet that size.

The threat content behind the frameworks has become specific enough to test. In a study of 20 agents and 45 live MCP servers, o1-mini was steered by a poisoned tool 72.8% of the time, and no model refused more than 3% of attacks (MCPTox, arXiv:2508.14925). That is a testable claim, which is what a framework needs to turn into a control.

Regulators are converging on the same artefacts: a register, a risk assessment, logged decisions, human oversight and a monitoring record. An organisation that produces those once can answer NIST, ISO, the EU AI Act and a customer questionnaire from the same source.

How exposed is your setup? Compass gives you a structured read you can use as the first input to any of these frameworks: compass.alyria.ai.

How do the frameworks differ?

They differ in type, scope and what they leave behind. Confusing the types is the most common cause of duplicated work.

Framework	Type	Scope	What it produces	Agent relevance
NIST AI RMF	Voluntary risk framework	AI systems across the lifecycle	Govern, Map, Measure, Manage structure	High: lifecycle and monitoring structure
NIST Generative AI Profile	Voluntary profile	Generative AI risks	Guidance on confabulation, integrity, security, oversight	High: maps to agent failure modes
ISO/IEC 42001	Certifiable management system	Organisation-wide AI management	Documented controls, roles, audit evidence	High: auditability
ISO/IEC 42005	Impact assessment standard	Individual AI system	Structured impact assessment	High: design-stage decision record
ISO/IEC 23894	Risk management guidance	AI risk inside enterprise risk	Risk register integration	Medium: connects to existing process
EU AI Act	Binding regulation	Systems by risk class	Legal obligations, documentation, oversight	High where high-risk applies
OWASP LLM Top 10	Threat taxonomy	LLM applications	Named application risks	Medium: anatomy of injection and excessive agency
OWASP Agentic Top 10	Threat taxonomy	Agentic applications	ASI01 to ASI10	High: the closest threat match
OWASP MCP Top 10	Threat taxonomy, beta	MCP servers and clients	MCP01 to MCP10	High: tool layer risks
MITRE ATLAS	Adversary knowledge base	AI systems	Tactics, techniques and case studies	Medium: detection engineering
SOC 2	Attestation	Controls over a period	Auditor-tested evidence	High: the evidence standard

In practice: One framework structures the work, one standard certifies the management, taxonomies supply the threats and SOC 2 sets the evidence bar. Everything else is a reference.

What does each framework contribute?

NIST AI RMF

The RMF supplies the lifecycle: Govern, Map, Measure, Manage. Its value for agents is that it forces an inventory and a monitoring plan, which are the two things agent programmes most often skip. It is also the vocabulary most US enterprises and their suppliers already share.

Its weakness is specificity. The core framework predates the agent wave, so applying it means interpreting "system context" as a tool list, a credential set and an egress path. That interpretation is work, and it is worth writing down once so the next team does not repeat it.

In practice: Use the RMF to structure the programme and the OWASP lists to fill in what to test.

ISO/IEC 42001, 42005 and 23894

ISO/IEC 42001 is the management-system standard, and it is the one that produces something an auditor can certify. It expects documented roles, an AI system register, supplier controls, impact assessments and continual improvement. For agents, the register and the supplier controls carry most of the weight.

ISO/IEC 42005 gives a method for assessing the impact of a specific AI system, which is the right shape for a pre-deployment decision about an agent's authority. ISO/IEC 23894 connects AI risk to the enterprise risk process, so agent risk lands in the same register as everything else rather than in a parallel spreadsheet.

In practice: If certification is the goal, 42001 sets the documentation bar and 42005 supplies the assessment artefact.

EU AI Act

The Act is binding law with obligations that depend on risk classification. For agents, the relevant duties are risk management, technical documentation, logging, human oversight, accuracy and robustness where the system is high-risk. It also places duties on deployers, not only providers, which catches internal agents built for internal use.

The practical consequence is record-keeping. An organisation that already records per-call decisions, approvals and scope changes has most of what the Act asks for. One that documents intent but not behaviour does not.

In practice: Ask legal to classify, and treat the answer as a design input rather than a label on a slide.

OWASP LLM, Agentic and MCP lists

These are taxonomies rather than processes, and they are the most directly useful material for engineering. OWASP LLM01 places prompt injection first and notes that foolproof prevention is unclear. LLM06 names excessive functionality, excessive permissions and excessive autonomy as the causes of excessive agency. The Agentic list names goal hijack, tool misuse, identity abuse, supply chain, unexpected code execution, memory poisoning, inter-agent communication, cascading failures, human-agent trust exploitation and rogue agents. The MCP list covers the tool layer.

In practice: Use the taxonomies to write test cases. A threat you cannot test is a paragraph.

MITRE ATLAS

ATLAS is an adversary knowledge base: tactics, techniques and case studies drawn from real AI incidents. It is useful for detection engineering, because it describes behaviours rather than risks, and behaviours are what logs contain.

In practice: Map a handful of ATLAS techniques to detection rules before mapping all of them. Coverage breadth is less useful than three rules that fire.

SOC 2

SOC 2 is not an AI framework and it is the framework most enterprises are actually measured against. Its control areas cover access, change management, monitoring and confidentiality, and every one of them now includes non-human actors. An agent on a shared credential with no owner is a finding under access control whether or not the AI policy mentions agents.

In practice: Extend the SOC 2 control set to agents rather than running a parallel AI assurance programme.

What the frameworks do not cover

None of them tells you what your agents actually do. Every framework assumes the organisation can describe its own systems, and agents are the first category of software where that assumption fails routinely, because they are installed by individuals and their capability set changes at runtime.

That gap is why the register has to come from observation as well as submission, and why an attestation built only from interviews tends to collapse at the first technical question. The frameworks supply the questions. The evidence has to come from the estate.

How to combine the frameworks without duplicating work

The principle is one control set with many mappings. Build the controls, then translate.

1. Pick one structuring framework

NIST AI RMF or ISO/IEC 42001, not both as programmes. The choice usually follows whether certification matters. Everything else is mapped to the one you picked.

Tip: Write the choice down with a date and an owner. Ambiguity here is why three teams build three registers.

2. Build four artefacts

A register with owners and tiers, a policy file per agent, a decision record per tool call, and an approval log. These four satisfy the core of every framework on the list.

3. Map once, in one document

A mapping table with a row per framework requirement and a column for the artefact that satisfies it. Two pages is normal. If it grows past five, someone is restating the framework rather than mapping to it.

Tip: Keep the mapping in version control beside the policy. Auditors ask for the mapping, and a stale one is worse than none.

4. Use taxonomies for test content

Write test cases from OWASP and ATLAS against the deployed configuration. Record the result and the date, because a test whose date is unknown cannot support a claim about this quarter.

5. Automate the evidence

Evidence produced by hand decays. Decision records exported from the enforcement point, approval histories from the queue and inventory from the endpoint are the three that stay current without effort.

6. Separate the control from the claim

The control is what you run. The claim is what you tell a customer or auditor, and it should name the control, the period and the evidence. Conflating them is how organisations end up with confident statements and no artefacts.

7. Review the mapping when the framework changes

Standards get revisions and taxonomies get editions. A mapping reviewed annually is enough for most programmes, and it prevents the quiet drift where the policy cites a version nobody uses.

Where risk frameworks apply in the agent lifecycle

Design

The impact assessment and the risk tier are decided here. ISO/IEC 42005 and the EU AI Act's risk management duties both point at this stage.

Note: A classification made after the architecture is chosen is a description, not a decision. Classification that could change the design has to precede it.

Development

Taxonomies become test cases, and the control set is implemented rather than described. Policy files are written alongside the agent's code.

Pre-deployment testing

Measurement starts. Attack success against the real configuration, denial behaviour, approval paths and a recorded baseline.

Note: Frameworks expect evidence that a test happened, not that it passed. A failed test with a remediation record is stronger than a clean report with no artefacts.

Deployment

The management system records the approval, the tier and the operational owner. The EU AI Act's logging duties and SOC 2's change controls both land here.

Runtime

Decisions are enforced and recorded. This is where the difference between a documented programme and an operating one is visible.

Continuous monitoring

The framework review cadence follows the tier. Metrics move, drift appears and the register is corrected rather than defended.

Note: Check the register before adding a control. A stale register reads as a missing control in an audit, and keeping it current is the cheapest improvement available.

Decommissioning

Retire the identity, close the register entry and retain the evidence for the period your policy and regulation require.

The takeaway: Frameworks are translation layers over one control set. Build the controls, map the language, automate the evidence.

Worked example: one evidence set, four frameworks

A payments company has a customer support agent, a coding agent and a fraud review agent. It is asked for evidence by an enterprise customer citing ISO/IEC 42001, by its auditor under SOC 2, by legal under the EU AI Act and by its own board using the NIST AI RMF.

The register. One register lists the three agents plus 22 discovered installations, each with an owner, a tier, a tool list, a data scope and an identity. It satisfies the RMF Map function, the ISO system register and the SOC 2 access review.

The policy files. One per agent, in version control, with a change history. These answer the RMF's documented-scope expectation, the ISO control documentation and the Act's technical documentation requirement for the high-risk classification legal assigned to the fraud agent.

The decision record. Tool calls, holds and denials are exported to the SIEM as signed, chained events. This satisfies the Act's logging duty, SOC 2 monitoring, the RMF Measure function and the ISO evidence expectation, from one export.

The approval log. The fraud agent's write actions require a named approver, and each approval is bound to the action. It answers the human oversight duty, SOC 2 change control and the RMF's accountability expectation.

The mapping. A two-page table maps each framework requirement to one of the four artefacts. The customer's 42 questions and the auditor's 30 controls are answered from it, with the artefacts attached as evidence.

The cost. The first mapping took three days. The second review took half a day because the artefacts were already current, which is the difference between a programme and a documents folder.

How standards and regulations influence the choice

Situation	Framework to lead with	Supporting material
Enterprise customer asks for assurance	ISO/IEC 42001 structure	SOC 2 evidence, OWASP taxonomies
US enterprise, no certification goal	NIST AI RMF	Generative AI Profile, OWASP lists
High-risk system in the EU	EU AI Act obligations	ISO/IEC 42005 assessment, RMF structure
Security engineering needs test content	OWASP Agentic and MCP lists	MITRE ATLAS techniques
Sales and security questionnaire	SOC 2 plus a control mapping	Register, policy files, decision exports
Existing enterprise risk process	ISO/IEC 23894	RMF functions as the AI layer

Further reading: NIST AI RMF for AI agents for the deepest single framework, AI TRiSM for agents for the operating model, and Agentic AI governance for ownership.

How Alyria handles it

Alyria produces the four artefacts the frameworks keep asking for, from the endpoint rather than from interviews. Beacon inventories agents, MCP servers, tools, credentials and destinations, so the register is observed and dated. Lyra holds the policy file as enforceable configuration, versioned and evaluated locally before each call.

Spectra exports signed, chained decision records to Alyria Cloud or your own SIEM, which serves the logging, monitoring and evidence expectations at once, and Observatory keeps policy decisions, detections and CVE posture in one plane for review meetings.

Start free at alyria.ai and generate the register and control mapping inputs on one machine: app.alyria.ai/signup.

The free Agent Exposure Report is the read-only entry point, and the docs describe how the modules fit together.