AI governance for Indian financial services: a playbook for chatbots, copilots and agents
Employees already use AI tools, and agents now run commands and edit files on their laptops. Here is what Indian regulators expect, and a seven-step playbook for saying yes to AI without losing control of customer data.
The short version
- Your teams already use AI: chatbots, copilots, browser extensions and, increasingly, agents that run commands and edit files.
- The RBI’s FREE-AI framework (August 2025) asks regulated entities for a board-approved AI policy, risk-based controls, auditability and AI-aware cybersecurity.
- The DPDP Act applies to personal data in prompts and uploads exactly as it applies anywhere else.
- Governance starts with an inventory. You cannot set policy for tools you don’t know exist.
- For agents, the key control is a human approval step before destructive or irreversible actions.
Why AI governance became urgent
Two years ago, “AI risk” in a bank meant model risk: is the credit-scoring model fair, explainable and validated? That still matters. But the faster-moving risk now sits with employees. A collections agent pastes a customer’s loan history into a chatbot to draft a message. An engineer gives a coding agent access to a repository with production credentials in a .env file. A browser extension quietly sends page content, including a customer dashboard, to a third-party model.
None of these are model-risk problems. They are data-handling and access problems, and they happen on laptops, outside the systems your existing controls watch.
Blocking AI outright doesn’t work. People route around it with personal phones and accounts, and you lose both the productivity and the visibility. The goal is the opposite: make it safe to say yes.
What Indian regulators expect
RBI: the FREE-AI framework
In August 2025 the Reserve Bank of India published the report of its committee on a Framework for Responsible and Ethical Enablement of AI (FREE-AI) in the financial sector. It sets out seven guiding principles, or “sutras” — trust, people first, innovation over restraint, fairness and equity, accountability, understandable by design, and safety, resilience and sustainability — and 26 recommendations across six pillars: infrastructure, policy, capacity, governance, protection and assurance.
For a regulated entity, the practical expectations include:
- A board-approved AI policy that defines permitted use cases, risk appetite, governance and accountability.
- Risk-based treatment of AI use: more scrutiny for higher-risk uses.
- AI decisions and operations that are auditable, with testing protocols.
- Disclosure to customers when they interact with AI.
- AI-aware cybersecurity: identifying the security risks AI introduces.
MeitY: India AI Governance Guidelines
In November 2025 MeitY released the India AI Governance Guidelines. They deliberately favour a principles-based approach over a new AI law, relying on existing laws — including the DPDP Act and the IT Act — plus voluntary frameworks and sector regulators. They share the same seven sutras and stress that those who develop and deploy AI should remain visible and accountable.
DPDP: personal data doesn’t stop being personal in a prompt
If an employee pastes a customer’s name, PAN and account balance into an external AI tool without authorisation, that is a disclosure of personal data to a third party. Depending on the circumstances it can be a personal data breach, with the same notification duties and penalties as any other. An agent that reads a KYC folder it never needed is processing personal data beyond its purpose. The DPDP Act doesn’t mention AI by name; it doesn’t need to.
The five risks to govern
| Risk | What it looks like | Control |
|---|---|---|
| Shadow AI | Unapproved chatbots, extensions and desktop assistants in daily use. | Inventory, then sanction, restrict or retire each tool. |
| Data leakage through prompts | Customer records pasted or uploaded to a model you don’t control. | Detect personal data at paste or upload; warn, redact or block. |
| Over-privileged agents | A coding agent that can read secrets, reach production or run any shell command. | Least privilege by default; policy on what agents may access. |
| Irreversible actions | DELETE on a production table, force-pushes, mass file edits. | Human approval before destructive or sensitive actions. |
| No audit trail | Nobody can say what an agent read, ran or changed last Tuesday. | Record sessions and tool calls; keep them as evidence. |
Prompt injection deserves a mention: an agent that reads a malicious web page, email or file can be steered into actions its user never asked for. You can’t fully prevent it at the model layer today, which is exactly why approvals and least privilege at the action layer matter.
A seven-step playbook
1. Build the inventory
List every AI tool and agent in use: web apps, browser extensions, IDE plugins, desktop assistants, command-line agents and internal bots. Record which teams use each, what data it can see and who the vendor is. Discover this from endpoints rather than a survey; surveys miss most of it.
2. Tier by risk
Not every tool needs the same scrutiny. A grammar checker that never sees customer data is low risk. An agent with shell access on a laptop that holds KYC exports is high risk. Tie the tier to two questions: what data can it reach, and what actions can it take.
3. Set data rules for AI
Decide what may go into which tools. A common starting point for financial services:
- Approved enterprise AI tools: internal data allowed; government IDs and account numbers redacted.
- Unapproved public tools: warn on any personal data, block uploads of files containing it.
- Source code and secrets: allowed only in approved coding tools; API keys and credentials always blocked.
4. Put guardrails on agents
Agents are different from chatbots because they act. Give them the minimum access their task needs, and define which actions require a person:
| Agent action | Suggested default |
|---|---|
| Read files in the working project | Allow, log |
| Read files containing personal data or secrets | Warn, log; block for unapproved agents |
| Run tests, linters, builds | Allow, log |
| Delete files, drop tables, force-push, change permissions | Require approval |
Modify sensitive files (.env, CI config, IAM policy) | Require approval |
| Send data to a new external endpoint | Require approval |
Make approvals easy to act on. A reviewer should see a plain-language summary of what the agent wants to do and why it was flagged, not a raw log line. If the developer can’t decide, it should go to an admin and become a ticket rather than stall in a chat window.
5. Log everything that matters
For each agent session, keep who ran it, on which machine, the files read, commands run, tools called, and every approval decision. This is the evidence that makes your AI policy auditable, and the record you will need if an agent is ever involved in a data incident.
6. Connect to incident response
Route critical and high-severity AI events — a blocked exfiltration attempt, a rejected destructive command, a secret sent to an unapproved tool — into the same ticketing and incident process as everything else. AI incidents shouldn’t live in a separate silo.
7. Train and publish the approved list
Most AI data leaks are well-meaning employees trying to work faster. Publish which tools are approved for what, explain why, and use in-the-moment warnings as training: a short message at the point of the paste teaches more than an annual module.
What good looks like in 90 days
- A live inventory of AI tools and agents, by team, updated automatically.
- A board-approved AI policy with risk tiers and data rules that match how tools are really used.
- Personal data and secrets detected at paste and upload, with warn, redact or block in place.
- Approval required for destructive agent actions and sensitive file changes.
- Session and tool-call logs retained, with high-severity events ticketed.
- A monthly report to the risk committee: tools adopted, incidents, approvals, trends.
How Scanyx helps
Scanyx AI Guardian runs on the same laptop agent as our DLP. It builds the AI inventory automatically, catches PAN, Aadhaar and account numbers before they reach an AI tool, records agent sessions and tool calls, and pauses destructive commands or sensitive file changes for a human — approve, reject, or assign to an admin, which opens a ticket. Policies apply by tool, team and data type, and critical events flow into Jira as evidence.
The aim is simple: let your teams use AI, with the controls your board and regulator expect. See AI Guardian in a demo.
This article summarises public frameworks for practitioners and is not legal or regulatory advice. Refer to the RBI’s FREE-AI committee report and MeitY’s India AI Governance Guidelines for the authoritative text.