Frameworks

Every framework here supplies scaffolding, and none supplies a control that stops an agent. They share one blind spot too: the person this wiki is about, a non-engineer deploying an agent without security oversight, is not an actor in any of them.

The short version

Framework	What it gives	Where it stops
ISO/IEC 27001:2022	Management-system machinery, risk treatment, Statement of Applicability, audit cadence	Zero mentions of AI, models, or agents
ISO/IEC 42001:2023	Certifiable AI management system that bolts onto 27001; AI impact assessment	38 management and documentation controls; nothing on egress, sandboxing, identity, injection
NIST AI RMF 1.0	Govern / Map / Measure / Manage, and the trustworthiness vocabulary	Not a security control set; NIST says so itself
NIST COSAIS	The intended 800-53 overlay for AI security	No overlay text yet: an annotated outline for one use case, Jan 2026
OWASP ASI	The threat vocabulary: T1–T17, six playbooks, KC1–KC6 for builders	Governance explicitly out of scope in the builder guide
CSA AICM / MAESTRO	243 control objectives over 18 domains; a seven-layer agent threat model	The citizen developer has no clean actor role
EU AI Act	Transparency duties live now; risk-tiered obligations later	Does not mention agents, tool calling, or multi-agent risk

ISO 27001 and 42001: the pair, and the boundary between them

ISO/IEC 27001:2022 is the third edition, published October 2022. Clauses 4 through 10 cannot be excluded when claiming conformity; the Annex A controls can be tailored, the management system never. Annex A carries 93 controls in four themes (37 organizational, 8 people, 14 physical, 34 technological). §6.1.3 is the mechanism worth knowing: determine the controls the firm needs, compare against Annex A to confirm nothing was omitted, and record inclusions, exclusions and status in a Statement of Applicability. Note 3 says controls may be drawn from any source and that Annex A is explicitly non-exhaustive, the licence for putting agent-specific controls inside a certified ISMS without building a parallel programme.

A case-insensitive search of the whole 27001 text for “artificial intelligence,” “machine learning,” “AI” and “agent” returns nothing: the boundary, mechanically checked.

ISO/IEC 42001:2023 (first edition, December 2023, JTC 1/SC 42) is the AI management system, and its scope sentence matters for a fund: it applies to organizations that provide or use AI systems. Consuming AI puts a firm in scope. It uses the harmonized structure, so it extends a 27001 ISMS rather than duplicating it, and inherits the Statement of Applicability (§3.26).

Its genuinely new requirement is §6.1.4, the AI system impact assessment: a defined process covering consequences for individuals, groups and societies, considering deployment, intended use and foreseeable misuse, feeding into the risk assessment and repeated at planned intervals (§8.4). Nothing in 27001 asks for that.

The important part is what 42001 leaves out. Annex A is 38 controls in nine families, all management and documentation controls. The closest thing to a technical control in the whole annex is A.6.2.8, which requires deciding at which life-cycle phases event logging is enabled. Nothing addresses egress, sandbox isolation, tool permissioning, agent identity or prompt injection. A 42001 certificate evidences that a governance process exists. It stops short of evidencing that any agent is contained. Annex D names finance as a target sector; the bibliography cross-references 23894, 38507, 5338 and NIST AI RMF. Certification itself runs on a three-year cycle with annual surveillance (ISO/IEC 17021-1, verified from a secondary text); a certificate marks a point on that cycle rather than a state.

NIST: a delta on IT security, and an overlay that doesn’t exist yet

NIST’s framing is the useful one: AI systems are predominantly software, and their security is intertwined with the security of the underlying IT infrastructure, so AI security is a delta on IT security rather than a replacement. The corollary, in NIST’s own assumptions, is that every one of its AI efforts presumes an existing baseline programme: access control, account management, identification and authentication, configuration management, incident response. That is a citable authority for the order argued in sequencing: fix identity and incident response before buying anything AI-specific.

AI RMF 1.0 (Govern / Map / Measure / Manage) is the trustworthiness frame; AI 600-1 extends it to generative AI. NIST draws its own line: 800-53 and COSAIS carry the security controls, AI RMF carries trustworthiness (validity, safety, accountability, transparency, explainability, privacy, fairness).

COSAIS, the control overlays for securing AI systems, is where agent-specific security controls are supposed to land, and as of August 2026 they have not. The concept paper is dated 14 August 2025; the latest deliverable is an annotated outline released 8 January 2026 for one of five planned use cases, explicitly a discussion draft. Single-agent and multi-agent systems are separate use cases; the work is worth tracking, but nothing in it can yet be presented as guidance a firm can apply.

OWASP: the vocabulary everyone actually uses

The Agentic Security Initiative’s Agentic AI — Threats and Mitigations is the anchor. v1.0 (February 2025) defined T1–T15; v1.1 (December 2025) adds T16 insecure inter-agent protocol abuse (MCP and A2A) and T17 supply-chain compromise, with six mitigation playbooks. Its companion Securing Agentic Applications Guide v1.0 (July 2025) is builder-facing, uses the KC1–KC6 component taxonomy, and puts governance explicitly out of scope.

Two traps. T13 “rogue agents” means something other than this wiki’s shadow agents: T13 covers a compromised agent inside a system the firm did sanction, and drift with no attacker is closer to T7. And the ASI Agentic Exploits & Incidents Tracker is a real register of 45 incidents dated February to December 2025, but the “updated weekly” description did not hold at our last check.

CSA, and the actor-role gap

CSA’s AI Controls Matrix (July 2025) is 243 control objectives across 18 domains mapped to five actor roles. MAESTRO (Ken Huang, CSA blog, February 2025) decomposes an AI ecosystem into seven layers with security and compliance as a cross-layer dimension; OWASP’s multi-agent guide is built on it, the strongest evidence in its favour.

The gap is the reason this wiki exists. In AICM a citizen developer falls between “Application Provider” and “AI Customer,” both carrying obligations a business analyst who built something over a weekend cannot meet. NIST’s actor model has no place for them either, and OWASP’s Citizen Development and Low-Code/No-Code Top 10s predate AI-generated applications. No major framework treats the citizen developer as an actor class; CSA’s own fix is to extend AICM with the role rather than mint another framework.

EU AI Act, for a fund

Three facts, the third being the one most write-ups get wrong.

1. The timeline moved. Regulation (EU) 2026/1744, the Digital Omnibus on AI (OJ 24 July 2026, in force 27 July 2026), pushed Annex III standalone high-risk obligations to 2 December 2027 and Annex I embedded high-risk to 2 August 2028. What applied from 2 August 2026 is general application, notably Article 50 transparency. Anything dating high-risk obligations to August 2026 predates the omnibus.
2. Most fund agents fall outside high-risk. Annex III’s eight areas exclude trading, research, portfolio management and operations. The realistic triggers are HR and recruitment agents, consumer credit decisions on natural persons, and life or health insurance pricing.
3. The penalty tiers differ from the ones that circulate. Up to €35M or 7% of worldwide turnover applies to prohibited practices under Article 5. Provider, deployer and transparency breaches, Articles 16, 26 and 50 among them, carry up to €15M or 3%; misleading information, 1%; and SMEs pay the lower of amount or percentage.

What actually binds a US fund

Nothing on this page binds a US fund the way SEC and FINRA rules already do. There is no AI-specific rule; what exists is stronger: Advisers Act Rule 206(4)-7, FINRA Rule 3110, and category-based recordkeeping rules that never mention AI because they never needed to. That said, the voluntary framework a US regulator has visibly gestured at is the NIST AI RMF: FINRA lists it in the resources appended to Regulatory Notice 24-09 (2024-06-27). Listing confers no endorsement and carries no obligation, but it is more than any other framework on this page has. Detail in recordkeeping and compliance gaps. One piece of background worth carrying into an exam: US model-risk expectations descend from SR 11-7 and OCC Bulletin 2011-12, and that is the lineage an examiner will map AI governance onto. What the binding rules actually cost a firm that misses them is regulatory exposure; what a supervisor asks is exam readiness.

The rest of the map, briefly

• Singapore’s IMDA / AI Verify Model Governance Framework for Agentic AI (updated May 2026): the one framework designed for agentic systems, with crosswalks to 42001 and the NIST AI RMF.
• Colorado SB24-205 (May 2024): the domestic counterpart to the EU’s risk-tiered approach.
• Vendor maturity models are adoption instruments rather than standards.
• MITRE ATLAS is the one on this list that has actually kept up with agents, and it is the only entry here we’d tell a security engineer to open first. Verified against MITRE’s own data repository at release v2026.06 (2026-06-30): 16 tactics, 101 techniques with 69 sub-techniques, 35 mitigations and 57 case studies, of which about thirty named objects are agent-specific: AI Agent Context Poisoning, Poisoned AI Agent Tool, Exfiltration via AI Agent Tool Invocation, Agentic Resource Consumption. It is a technique catalog, not a governance framework, so it names what to defend against and nothing about who signs off. Two cautions: the published counts in circulating summaries are stale by roughly a year, and the release tags moved to a date scheme while the data file still reports version: 5.6.0 internally, so cite the tag and the date.
• Google SAIF (introduced 2023-06-08 with six core elements) is now a risk-and-control map over four components (data, infrastructure, model, application) split by whether the firm builds models or consumes them, with a self-assessment questionnaire and a separate agent-specific diagram and assessment. Useful as a checklist against a firm’s own architecture; it is a vendor’s framing rather than a standard, and nothing binds anyone to it.

See also

• Crosswalk — concern → dimension → control → gate, generated from page links.
• Bibliography — which of these to read in full, and in what order.
• Governance — using a framework without building a parallel organization to hold it.
• Open questions — including the actor-class gap.