India's RBI released the Draft Guidance on Model Risk Management on June 24, 2026. Comments closed July 24, 2026. Final guidelines are expected Q4 2026 or Q1 2027. For generative AI governance, MRMF is remarkably specific — more specific than SR 11-7, more specific than the EU AI Act, more specific than any comparable banking regulatory document in calling out hallucination controls, red-teaming, and prompt injection by name.
For agentic AI governance, MRMF says nothing. Not an oversight — the draft was written when Indian banks' agentic AI deployments were in early stages. The final guidelines will likely maintain this gap, because the comment period has closed. The governance question for Indian banks deploying autonomous payment agents, LLM-driven customer service agents, or multi-agent research systems is: how do you satisfy MRMF examination requirements when MRMF doesn't define the requirements for the AI you're deploying?
Six GenAI Provisions MRMF Covers Explicitly
Hallucination Controls — Named and Required
MRMF uses the word "hallucination" explicitly. Requirement: "implement control boundaries through system-level controls or model design features to mitigate hallucination risks — particularly in generative AI models." Five approved mechanisms: restricted knowledge sources (RAG with curated document sets), retrieval from approved repositories only, output verification (post-generation checks), confidence thresholds (suppress outputs below defined confidence), human approval for high-stakes outputs. Banks deploying GenAI customer interfaces must implement at least one of these mechanisms and document which one and why it is adequate for their use case.
Red-Teaming — Mandatory for GenAI
MRMF mandates red-teaming "particularly for models involving customer interaction or generative capabilities." The word "particularly" signals that red-teaming is required for GenAI, whereas traditional statistical models receive standard validation. Red-teaming scope for MRMF compliance: jailbreak attempts (prompt manipulation to bypass guardrails), harmful content generation (BFSI-specific: financial advice violations, mis-selling, discriminatory outputs), prompt injection from external content (malicious content injected through documents or customer inputs), and adversarial probes against the hallucination controls themselves. The FinProof benchmark approach — 14 BFSI-specific test categories — maps directly to what MRMF's red-teaming mandate requires in practice.
Kill Switch — Tested, Not Just Documented
MRMF requires institutions to "maintain tested capabilities to suspend or deactivate AI models operating outside approved risk thresholds." The word "tested" distinguishes MRMF from frameworks that accept a kill switch as documented policy. In MRMF terms: a kill switch that has never been tested does not satisfy the requirement. Banks must document when the kill switch was last tested, what the test scenario was, what the outcome was, and who can activate it. For GenAI systems in customer-facing deployment, kill switch testing should cover both planned suspension (coordinated maintenance window) and emergency suspension (unplanned failure scenario with customer traffic in flight).
Prompt Injection — Named as a Risk
MRMF is the first India banking regulatory document to name "prompt injection attacks" explicitly as a risk category requiring controls. This elevates prompt injection from an AI security concern to a model governance concern: it is not just a cybersecurity team problem (covered by CERT-In Blueprint) but an MRM function problem (covered by MRMF). Banks must document: what prompt injection controls are deployed, how they were tested (adversarial red-teaming against indirect prompt injection, not just direct), and what the residual risk is after controls. RAG-based systems where external documents may contain adversarial content require specific indirect prompt injection testing.
Foundation Model Documentation
MRMF requires documentation of "intended use, operational boundaries and behaviour of foundation models," including input/output restrictions. For third-party LLMs (OpenAI GPT-4, Anthropic Claude, Google Gemini, Azure OpenAI, Indian providers like Sarvam AI, Krutrim, CoRover): the bank must obtain this documentation from the provider and maintain it as part of the model inventory. Provider-driven model updates — a third-party LLM vendor updates their model version — require governance: the bank must detect when the model has changed, assess whether the change affects operational boundaries, and re-validate if needed. MRMF places model change governance responsibility on the deploying bank, not the provider.
Human Escalation for AI Customer Interfaces
MRMF requires "options for customers to choose human assistance if not satisfied with AI responses" — required for AI customer interfaces, not for traditional statistical model outputs. This applies to every LLM-powered customer service chatbot, GenAI advisory tool, or automated complaint resolution system deployed by a MRMF-covered institution. The human escalation path must be functional (not a dead end), clearly presented to the customer, and its usage rate monitored — a very high escalation rate is a signal that the AI interface is not meeting customer needs.
GenAI vs. Traditional Model Governance: The Two-Tier Structure
| Governance Dimension | Traditional Statistical Models | Generative AI / LLM (MRMF) |
|---|---|---|
| Validation approach | Statistical accuracy, prediction error, backtesting, population stability | Above + red-teaming (mandatory), adversarial testing, hallucination rate measurement |
| Explainability | Required — model decision can be explained to affected party | Black-box LLMs: compensating controls required (enhanced validation, usage restrictions, more frequent monitoring) — explainability cannot always be achieved |
| Drift monitoring | Statistical drift (PSI, performance degradation metrics) | Above + concept drift (behavioral, safety, capability drift) + third-party provider update detection |
| Security controls | Standard cybersecurity (CERT-In scope) | Above + prompt injection controls (MRM-level, not just cybersecurity) + AIBOM for LLM components |
| Third-party governance | Vendor due diligence, performance SLAs | Above + model documentation from provider, change notification rights, re-validation on provider updates, audit rights for model behavior |
| Customer interface | No disclosure or escalation requirement | AI disclosure mandatory, human escalation path mandatory, escalation rate monitoring |
| Kill switch | Standard business continuity planning | Tested kill switch capability required — documentation of test date, scenario, outcome, activation authority |
| Agentic AI | Not applicable | NOT COVERED — zero explicit provisions in MRMF June 2026 |
The Agentic AI Gap: Three Dimensions MRMF Does Not Address
Autonomous Execution Authority
Agentic AI executes actions — initiating transactions, sending communications, modifying records — without human review of each step. MRMF's kill switch implicitly acknowledges autonomous systems need intervention capability, but MRMF does not define: what decisions an autonomous agent may make without human approval, what decisions require human approval regardless of automation capability, how to tier agents by decision authority, or what "outside approved risk thresholds" means for an agent that has made three transactions in a row rather than producing a model output. Banks must define this governance tier themselves and document it as an extension to their MRMF model risk classification.
Multi-Agent Orchestration Risk
When an orchestrating LLM delegates tasks to specialist sub-agents (customer data agent, payment execution agent, compliance check agent), emergent failure modes appear: the orchestrating model misroutes a task, a sub-agent succeeds locally but the combined output is harmful, or a prompt injection attack on one agent compromises the orchestration chain. MRMF's model inventory obligation captures individual agents as models. But the orchestration layer — the logic governing how agents interact — has no MRMF framework. The failure surface of a multi-agent system is larger than the sum of its individual agents' failure surfaces, and MRMF validation of individual agents does not certify the orchestration. Banks must extend their validation frameworks to cover orchestration behavior.
Tool Use and External Action Irreversibility
Agentic AI calls external tools — APIs, databases, payment systems, email services. MRMF validation addresses model outputs. An agent that calls a payment API based on an LLM decision has created a financial transaction that model validation cannot reverse. The audit trail requirement (MRMF requires model decision audit trails) captures what the model decided, but does not capture the tool calls triggered by that decision unless the bank extends its audit trail implementation. Banks deploying agentic systems with tool use must: maintain a tool-call audit trail alongside the model output trail, define which tools require pre-authorization, define transaction size limits per agent, and implement reversibility checks (can this action be reversed if the model's decision was incorrect?). None of these extensions are specified in MRMF.
Extend MRMF's GenAI Framework — Don't Wait for a Dedicated Agentic AI Circular
MRMF examination for agentic AI will use the GenAI provisions as the nearest framework, extended by examiner judgment. Banks that have built agentic AI governance documentation aligned with the GenAI provisions — and explicitly extended them for autonomous execution, multi-agent risk, and tool use — will present a coherent governance position. Banks with no agentic AI governance documentation will face a framework-definition conversation with their examiner before the substantive compliance review begins. Four extensions to MRMF's GenAI framework for agentic AI:
- Agentic AI risk tier: Create an explicit risk classification tier above GenAI in the model risk inventory. Classification criteria: does the model execute external actions autonomously? Does it operate as an orchestrator of other AI models? Does it have access to tools with irreversible consequences (payments, account modifications, communications)? Each "yes" answer elevates the risk tier and triggers stricter governance requirements.
- Minimal footprint policy: Document that each agent is granted only the tools and permissions required for its specific task, not a general permission set. This is the agentic AI equivalent of MRMF's model purpose documentation — it defines the operational boundaries of the agent, not just the model. Mapping each agent's tool permissions to its declared task purpose is the governance documentation an examiner will look for.
- Orchestration validation: Extend MRMF's red-teaming requirement to the orchestration layer. Red-team the multi-agent system as a whole, not just individual agents: test for task misrouting, privilege escalation across the agent chain, and adversarial inputs that exploit inter-agent trust. Document the orchestration red-teaming exercise separately from individual agent red-teaming.
- Dual audit trail: MRMF requires model decision audit trails. For agentic systems, extend to tool-call audit trails: log every external API call, database query, and transaction triggered by agent decisions, with timestamps and the agent decision that triggered each action. This satisfies MRMF's audit trail requirement and adds the external action layer needed for agentic accountability.