Banks and other financial firms have mature processes for onboarding technology, but those processes were not built for generative AI and autonomous agents, and every firm has been writing its own AI risk catalogue from scratch. The FINOS AI Governance Framework (AIGF) is an open, CC BY 4.0 catalogue of AI risks and mitigations written by financial services practitioners under the Fintech Open Source Foundation, with mappings to the EU AI Act, NIST, OWASP, ISO/IEC 42001 and sector regulators. Version 3 was released on 26 October 2026 and now includes a substantial set of agentic AI risks. This guide explains how the catalogue is structured, what the risks and mitigations are, how to run its heuristic assessment, and how to fit it into an existing model risk and technology risk programme. It is written for AI risk, security and model governance teams in banks, asset managers, insurers and fintechs, and for anyone who wants a reusable control library for AI.
Key takeaways
- A shared catalogue, not a standard. AIGF is a practitioner-built list of 24 risks and 25 mitigations, each with its own page, status and cross-references, maintained in the open on GitHub.
- Agents are now first-class. Seven of the risks (ri-24 to ri-30) cover agent authorisation bypass, tool chain manipulation, MCP server compromise, state poisoning, multi-agent trust boundaries, credential harvesting and plugin supply chain.
- Mappings answer three questions. Each reference set has a lens: threat (what is it called elsewhere), obligation (which rule requires it) and control (how to implement and evidence it).
- Start with the heuristic assessment. An eight-step question set (use case, data, model, output impact, regulation, security, controls, decision) selects which catalogue entries matter for a given system.
- Check status before you cite. Most entries are Approved-Specification, but some, including the human-in-the-loop approval gate (mi-24), are still Draft.
What AIGF is and who maintains it
The project README states the goal as a governance framework for onboarding, developing and running AI-based solutions within financial services organisations, built use case by use case through threat modelling. It is published at air-governance-framework.finos.org and in the finos/ai-governance-framework GitHub repository under the FINOS AI Readiness programme. Maintainers listed in the repository come from several banks and technology firms, with a lead maintainer from Scott Logic.
| Item | As checked on 11 November 2026 |
|---|---|
| Current version | v3, release date 26 October 2026 |
| Licence | Creative Commons Attribution 4.0 (CC BY 4.0) |
| Catalogue size | 24 risks (11 Operational, 10 Security, 3 Regulatory and Compliance); 25 mitigations (17 Preventative, 8 Detective) |
| Risk domains | Components, Inputs, Leakage, Accuracy, Alignment, Agency, Vendor, Liability |
| Mitigation domains | Sourcing, Filtering, Data, Access, Evaluation, Oversight, Monitoring |
| Document statuses | Pre-Draft, Draft, Working-Group-Approved, Approved-Specification |
| Use cases | Credit Risk Analysis, Autonomous Wealth Management, Loan Approval, Anti-Financial Crime Investigation (all Draft) |
Identifiers are not continuous: there is no ri-3, ri-11 to ri-13, ri-15 or ri-21 in v3. Keep the identifiers exactly as published when you reference them, and record the version, because numbering and content can change between releases.
The risk catalogue
| Domain | Risks (ID, title, type) |
|---|---|
| Leakage | ri-1 Information Leaked to Hosted Model (RC); ri-2 Information Leaked to Vector Store (SEC); ri-29 Agent-Mediated Credential Discovery and Harvesting (SEC) |
| Inputs | ri-9 Data Poisoning (SEC); ri-10 Prompt Injection (SEC); ri-25 Tool Chain Manipulation and Injection (SEC); ri-27 Agent State Persistence Poisoning (SEC) |
| Components | ri-8 Tampering with the Foundational Model (SEC); ri-26 MCP Server Supply Chain Compromise (SEC); ri-30 Skill/Plugin Supply Chain Compromise (SEC, Draft) |
| Accuracy | ri-4 Hallucination and Inaccurate Outputs; ri-6 Non-Deterministic Behaviour; ri-19 Data Quality and Drift (all OP) |
| Alignment | ri-14 Inadequate System Alignment; ri-16 Bias and Discrimination; ri-17 Lack of Explainability (all OP) |
| Agency | ri-18 Model Overreach / Expanded Use (OP); ri-24 Agent Action Authorization Bypass (SEC); ri-28 Multi-Agent Trust Boundary Violations (OP) |
| Vendor | ri-5 Foundation Model Versioning; ri-7 Availability of Foundational Model (both OP) |
| Liability | ri-20 Reputational Risk (OP); ri-22 Regulatory Compliance and Oversight (RC); ri-23 Intellectual Property and Copyright (RC) |
Two points stand out for security teams. First, ri-1 treats a third-party hosted model as a two-way trust boundary where neither inputs nor outputs can be fully trusted. Second, ri-29 describes agents being manipulated into systematically searching configuration files, environment variables, logs, databases and cloud metadata for credentials: an identity risk as much as an AI one. See the AI Agents in Financial Services Security Guide for the sector context.
The mitigation catalogue
| Domain | Mitigations (ID, title, type) |
|---|---|
| Sourcing | mi-7 Legal and Contractual Frameworks (PREV); mi-10 AI Model Version Pinning (PREV); mi-20 MCP Server Security Governance (PREV); mi-25 Skill/Plugin Integrity and Governance (PREV, Draft) |
| Filtering | mi-2 Data Filtering from External Knowledge Bases; mi-3 User/App/Model Firewalling/Filtering; mi-8 QoS and DDoS Prevention; mi-17 AI Firewall Implementation and Management; mi-19 Tool Chain Validation and Sanitization (all PREV) |
| Data | mi-6 Data Quality and Classification/Sensitivity (PREV); mi-14 Encryption of AI Data at Rest (PREV); mi-16 Preserving Source Data Access Controls (DET) |
| Access | mi-12 Role-Based Access Control for AI Data; mi-18 Agent Authority Least Privilege Framework; mi-22 Multi-Agent Isolation and Segmentation; mi-23 Agentic System Credential Protection Framework (all PREV) |
| Evaluation | mi-5 System Acceptance Testing (PREV); mi-15 LLM-as-a-Judge (DET) |
| Oversight | mi-11 Human Feedback Loop (DET); mi-13 Citations and Source Traceability (DET); mi-24 Human-in-the-Loop Action Approval Gate (PREV, Draft) |
| Monitoring | mi-1 AI Data Leakage Prevention and Detection; mi-4 AI System Observability; mi-9 Alerting and Denial of Wallet Spend Monitoring; mi-21 Agent Decision Audit and Explainability (all DET) |
Agentic mitigations in practice
- mi-18 Agent Authority Least Privilege: agents get access only to the API endpoints and methods their use case needs, enforced at the tool manager and API gateway, with agent identity in every call. It adds contextual limits (transaction value thresholds, customer sensitivity, time and geography), time-bounded privileges, and separation of duties so no single agent completes a high-risk workflow end to end. Privilege matrices are kept under version control. NIST SP 800-53 mappings listed on the entry include AC-6, AC-2, AC-3, AC-5 and CM-7.
- mi-23 Credential Protection: credential-free agent images, no secrets in environment variables or agent-reachable files, a credential broker that issues time-limited, scope-specific credentials, and rotation that runs independently of the agents. See the Secrets Management Guide.
- mi-24 Human-in-the-Loop Approval Gate (Draft): gate the concrete action, not the agent; classify by policy, not by the model's judgement; fail closed when no decision exists; bind approval to a digest of the fully resolved action (final recipient, amount, payload); interrupt before any side effect; keep a tamper-evident record; and name the oversight pattern, from user confirmation to maker-checker. See the Human-in-the-Loop for AI Agents Guide.
- mi-20 MCP Server Security Governance: supply chain verification of MCP providers, authenticated and integrity-protected communication, data validation, isolation between servers, and three implementation tiers starting from a centralised proxy with human-in-the-loop controls. See the MCP Security Guide.
- mi-9 Denial of Wallet: five layers from an enterprise spending cap through real-time budget alerts, billing account limits and infrastructure-as-code quota policy to per-key token and request quotas at the API gateway, with alerts at 50, 75, 90 and 100 percent of budget.
Regulatory and standards mappings
Each risk and mitigation carries references grouped by lens. The reference sets in v3 are listed below.
| Lens (question) | Reference sets | Typical use |
|---|---|---|
| Threat ("What is this called elsewhere?") | OWASP Top 10 for LLM Applications; OWASP Top 10 for Agentic Applications (2026); OWASP ML Security Top 10; NIST AI 600-1; Agent Threat Rules (ATR) | Align AIGF risks with threat models and detection rules your security team already uses |
| Obligation ("Which rule requires me to address it?") | EU AI Act (Regulation (EU) 2024/1689); FFIEC IT Examination Handbook; IOSCO supervisory toolkit for AI in capital markets; SR 11-7 model risk guidance; UK and Canadian financial sector references | Show supervisors which requirement each control answers |
| Control ("How do I implement and evidence it?") | NIST SP 800-53 Rev. 5; ISO/IEC 42001 | Link AIGF mitigations to your existing control framework and AI management system |
The mappings are the project's own and are a strong starting point, but they are not legal advice or a regulator's view. Confirm current regulatory status against the primary text; for the EU AI Act timeline see the EU AI Act Compliance Guide, and for supervisors' expectations see Financial Regulators and AI.
Running the heuristic assessment
AIGF recommends a structured, question-led assessment before deploying any generative AI application. The steps, as published:
- Define the use case and context: function, users, business process affected and its criticality.
- Identify data involved: training data, prompt contents, personal or regulated data, and how outputs are stored.
- Model and technology: hosted, self-hosted or in-house model, testing evidence, explainability features and integration points.
- Output and decision impact: advisory or automated, worst-case bad output, and whether a human fail-safe exists and has time to work.
- Regulatory mapping: which rules apply, explanation duties, privacy consent and likely audit or notification.
- Security considerations: attacker entry points such as prompt injection, unauthorised access, known vulnerabilities and impact of model unavailability.
- Controls and safeguards identification: for each risk found, the controls in place or needed, producing a risk control matrix.
- Decision and documentation: a Low, Medium or High rating after controls, a proceed, adjust or stop decision, a written record and a review interval (the framework gives six months as an example).
For agents, add identity questions at steps 3 and 6: what credentials the agent holds, who owns them, what the agent can do without approval, and how it would be stopped. The Agentic AI Risk Assessment Template covers those in more depth.
How to adopt AIGF
- Pin a version. Record v3 (26 October 2026) as your baseline and assign an owner to review each new release.
- Import the catalogue. Load risk and mitigation IDs, titles, types, domains and statuses into your GRC tool as a reference library. The repository's Markdown front matter makes this straightforward.
- Map to existing controls. Link each mitigation to your current control IDs using the NIST SP 800-53 and ISO/IEC 42001 references, and mark gaps.
- Pilot on one system. Run the heuristic assessment on one live AI use case, ideally an agentic one, and produce the risk control matrix.
- Feed model risk management. Attach the matrix to the model inventory record so model validation, operational risk and security review the same evidence. See the AI Model Risk Management Guide.
- Scale and contribute. Roll out to all AI use cases by risk tier and feed lessons back to the project, which accepts contributions under its DCO process.
Smaller firms can adopt the heuristic assessment and the agentic mitigations (mi-18, mi-23, mi-24) first and skip formal mapping until a supervisor asks. Large banks will get most value from the obligation lens, which shortens the work of evidencing AI controls to several regulators at once.
Detection and measurement
The detective mitigations define what to watch: data leakage indicators (mi-1), system observability (mi-4), spend anomalies (mi-9), preserved source data access controls (mi-16) and agent decision audit trails (mi-21). Useful programme metrics:
- Percentage of production AI systems with a completed heuristic assessment less than six months old.
- Number of applicable AIGF risks per system with no mapped control.
- Percentage of agents whose privileges are defined in a version-controlled privilege matrix (mi-18).
- Agent actions in designated high-risk classes executed without an approval record (target zero, mi-24).
- AI spend alerts by threshold and time to response (mi-9).
Common failure patterns
- Catalogue as checklist: ticking all 24 risks for every system instead of using the heuristic assessment to find the ones that matter.
- Ignoring indirect prompt injection: ri-10 covers instructions hidden in content the model reads, not only what users type. The EchoLeak zero-click prompt injection shows how this exposes enterprise data without any user action.
- Unvetted MCP and tool integrations: adopting MCP servers without the supply chain checks in mi-20. The Amazon Q MCP configuration vulnerability shows how a tool configuration can become a path to cloud credentials.
- Credentials inside the agent's reach: secrets in environment variables or files the agent can read, the exact pattern ri-29 and mi-23 describe.
- Citing Draft entries as settled: using mi-24 or ri-30 wording in policy without noting their Draft status.
- Stale baseline: no owner for new releases, so the internal library falls behind the agentic risks added upstream.
Framework mapping
| AIGF area | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|---|---|
| Heuristic assessment | RA-3 Risk Assessment | ID.RA-03 |
| Access mitigations (mi-12, mi-18, mi-22) | AC-3 Access Enforcement; AC-6 Least Privilege; AC-5 Separation of Duties | PR.AA-05 |
| Vendor and sourcing (ri-5, ri-7, mi-7, mi-10, mi-20) | SA-9 External System Services; SR-3 Supply Chain Controls and Processes | GV.SC-01 |
The AC rows follow the NIST references AIGF itself lists for mi-18; the other rows are NHI Mgmt Group's reading.
Practitioner checklist
- Record AIGF v3 as the baseline and name an owner for release reviews.
- Load all 24 risks and 25 mitigations, with status, into the GRC library.
- Run the eight-step heuristic assessment for every production AI use case.
- Apply mi-18, mi-23 and mi-24 to every agent that can take actions.
- Vet MCP servers and agent plugins against mi-20 and mi-25 before use.
- Set Denial of Wallet controls at more than one level (mi-9).
- Map mitigations to existing NIST SP 800-53 and ISO/IEC 42001 controls.
- Flag Draft entries in internal policy and recheck at each release.
- Review assessments at least every six months or on model change.
Standards and references
- FINOS: AI Governance Framework
- FINOS: AI Governance Framework Repository
- FINOS: A Heuristic Approach to Identifying GenAI Risks
- FINOS: AIGF Risk Definitions
- FINOS: AIGF Mitigation Definitions
- FINOS: AIGF Regulatory and Standards Reference Sets
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: AI Agents in Financial Services Security Guide · Financial Regulators and AI · NIST AI 600-1 Generative AI Profile Guide · ISO/IEC 42001 Guide · Agentic Trust Framework (ATF) Guide