RBI’s FREE-AI Framework: What It Means for the Identities Your AI Systems Run On

The RBI FREE-AI framework is the Reserve Bank of India’s set of recommendations for how banks, NBFCs and other regulated entities should adopt and govern artificial intelligence. Among other things, it asks regulated entities to keep an inventory of their AI systems, hold a board-approved AI policy, report AI incidents and stay accountable for every decision an AI system makes.

Most summaries stop at the sutras and pillars. This guide covers the layer they leave out: the cloud identities your AI systems authenticate as, and the evidence a security team needs to show that those identities are inventoried, owned and controlled.

What the RBI FREE-AI framework is

FREE-AI stands for Framework for Responsible and Ethical Enablement of Artificial Intelligence. The RBI constituted the committee in December 2024, chaired by Dr Pushpak Bhattacharyya of IIT Bombay, and published its report on 13 August 2025, announced through an RBI press release.

The RBI FREE-AI framework is a committee report that sets out principles and recommendations for the responsible use of AI in India’s financial sector.

The report is built in three layers. Seven sutras set out the principles: Trust is the Foundation; People First; Innovation over Restraint; Fairness and Equity; Accountability; Understandable by Design; and Safety, Resilience and Sustainability, which asks that AI systems be secure and “resilient to physical, infrastructural, and cyber risks”. Six pillars organise the work into two halves: Infrastructure, Policy and Capacity on the innovation side, and Governance, Protection and Assurance on the risk side. Twenty-six recommendations then assign actions, some to regulated entities, some to the RBI and some to government and industry bodies.

For a security or risk team, the recommendations that matter most sit under Governance, Protection and Assurance. They include a board-approved AI policy covering governance structure, accountability, risk appetite, operational safeguards, auditability and the model lifecycle (Recommendation 14, with the report’s suggested policy outline in Annexure V adding the scope, responsibility and liability of third-party vendors); an internal AI inventory of models, use cases, dependencies and risks, updated at least every six months and available for supervisory inspection (Recommendation 23); AI incident reporting (Recommendation 22); risk-based audits of AI systems (Recommendation 24); and stronger cybersecurity for AI-specific threats (Recommendation 19).

The most direct line for identity teams sits in Annexure IV, where the committee suggests changes to existing RBI rules. Against the Master Direction on Information Technology Governance, Risk, Controls and Assurance Practices (2023), it proposes adding “Access Control measures for the autonomous AI under para 19 (Access Control)”. Elsewhere it notes that existing IT obligations on “access control, audit trails, and vulnerability assessments” may be extended to AI-based systems (paragraph 3.2.3.2). The committee expects access control for AI to run through the same rules banks already follow for every other system.

One point several summaries blur: FREE-AI is a committee report, not a binding circular. It does not by itself create a compliance obligation with a deadline. It does tell regulated entities, clearly, what the RBI’s expert committee thinks good AI governance looks like, and the report itself proposes that the RBI issue consolidated AI guidance as a single point of reference (Recommendation 6). Treating it as optional reading is a poor bet.

The RBI has already moved in this direction. In June 2026 it released a draft Guidance on Regulatory Principles for Model Risk Management, 2026, which applies to all models used by regulated entities, including third-party models and those using AI or machine learning, and asks for an inventory of every active, inactive and decommissioned model. At the time of writing it is still a draft.

Why AI governance lands on the identity team

AI governance usually starts with the model: what it was trained on, whether it is fair, whether a human can override it. FREE-AI covers all of that. But the inventory and accountability recommendations have a second, less discussed consequence, and it lands on the team that runs cloud identity.

The reason is simple. AWS, Azure and Google Cloud have no general concept of an “AI agent”. They see a principal making API calls. A loan-support copilot built on Amazon Bedrock runs as an IAM role. A claims assistant in Azure runs as a managed identity or an app registration. A Vertex AI agent runs as a service account. A notebook in a pilot often runs on a long-lived access key that an engineer created “just to get it working”.

So every AI system in production has at least one cloud identity behind it, and often several. A Bedrock agent, for example, has its own service role, and each action-group Lambda it calls has a separate execution role. One “agent” on the business side is usually three or four identities on the cloud side.

That has two consequences for FREE-AI.

First, an AI inventory that lists models and use cases but not the identities those systems run as is incomplete. It records what the system is for, but not what it can do. The permissions that decide whether an AI system can read a customer table live on the identity, not in the model card. The report already lists “cloud service providers” among the dependencies an AI inventory should record (paragraph 4.4.68). It does not mention identities, but the identities an AI system runs as are the most concrete record of that dependency.

Second, accountability that stops at the application owner cannot be evidenced in a log. When something goes wrong, the cloud audit log will name an identity: a role session, a service principal, a service account. If nobody can say who owns that identity and which AI system it belongs to, the accountability chain breaks at exactly the point an auditor will test it. FREE-AI leaves no room to point at the system instead: “Accountability cannot be delegated to the model and underlying algorithm.”

This is why the identities AI systems authenticate as [/blog/non-human-identity/] belong in the FREE-AI conversation from the start, alongside the model and the use case.

The four questions an auditor will actually ask

Auditors rarely ask whether a bank “has AI governance”. They ask for evidence. For AI systems running in the cloud, that evidence comes down to four questions.

Few regulated entities can answer them today. In the RBI survey behind the report, only 18% of the 127 entities using AI maintained audit logs for it, and only 14% monitored AI performance in real time (paragraph 3.3.13).

1. Which AI systems are running, and which cloud identity does each one use?

This is the inventory question. The answer needs to name the identities, not just the applications: the IAM roles, managed identities, service principals, service accounts and API keys each AI system uses. It should include identities used by tools the agent calls, and by any Model Context Protocol (MCP) server that brokers the agent’s access to cloud or SaaS APIs.

2. Who owns that identity, and is that ownership recorded anywhere a system can read?

A spreadsheet maintained by the AI team is a start, but it goes stale. Ownership recorded as a tag on an AWS role, a label on a GCP service account, or an owner on an Entra object can be checked automatically and flagged when missing. That is the difference between a claim and evidence.

3. What can that identity reach, and does it need all of it?

AI identities tend to be over-permissioned. An agent chooses its tools at run time, so teams grant broad access “so it doesn’t break”. The useful measure is granted access against used access over a period of 30 to 90 days. An identity that can read hundreds of storage buckets but has read one in two months is a finding, whatever the model does.

The report makes the same link. It says autonomous AI systems can “operate with access to real-world customer assets like bank accounts or financial data”, and that regulated entities “must clearly define the tasks AI can perform autonomously” (paragraph 4.4.49). In the cloud, what an AI system can do is defined by the permissions on its identity. The report’s own prompt injection example, a hidden instruction to “authorize a fund transfer” (paragraph 2.2.11), makes the point: an injected instruction can only do what the identity behind the agent is allowed to do.

4. If that identity did something unexpected, would you know, and how quickly?

The answer depends on logging. Several of the logs that show what an AI identity did are switched off by default. AWS CloudTrail data events, which record object reads in S3 and calls such as Bedrock InvokeAgent, need to be enabled and cost extra. Azure resource logs need a diagnostic setting per resource. Most GCP Data Access audit logs are off. If those logs are not on, the answer to this question is “no”, regardless of what the policy document says.

Detection is only part of it. The report says AI systems “should be capable of being terminated instantly if there is a risk of significant harm” (paragraph 4.4.58). For an AI system in the cloud, the fastest reliable off switch is usually disabling or revoking the identity it runs as, so it helps to know in advance which identities to revoke for each system.

Where the evidence actually lives, by cloud

Each of the four questions has a concrete answer in each cloud. The table below maps what a regulated entity needs to evidence to where it can be found.

The identity an AI system runs as. On AWS, a Bedrock agent needs a service role that trusts bedrock.amazonaws.com, and Amazon Bedrock AgentCore Identity adds a dedicated workload identity type. On Azure, Microsoft Entra Agent ID is now generally available and is the first native “this principal is an agent” label on any of the three clouds, but only for agents built on it. On GCP, Agent Identity for Vertex AI Agent Engine gives each deployed agent its own principal. Custom agents on plain roles, service principals or service accounts carry no such label anywhere.

Controlled creation. Creation events are recorded by default on all three clouds: CloudTrail management events on AWS, Entra audit logs on Azure, and Admin Activity audit logs on GCP, which are always on and free. The evidence you want is that AI identities were created by your infrastructure-as-code pipeline, not by a person in the console.

Ownership. None of the three clouds enforces ownership by default. Entra Agent ID has owners and sponsors built in. Everywhere else, ownership is a tagging or labelling discipline, and the control is a check that flags identities without an owner.

Granted versus used. AWS offers IAM Access Analyzer unused access findings and last-accessed data. GCP offers IAM Recommender and Activity Analyzer. Azure is thinner. Microsoft retired the standalone Entra Permissions Management product in 2025, and what remains natively is the CIEM capability in Microsoft Defender for Cloud, which comes with the paid Defender CSPM plan. Without that plan, teams have to reconstruct usage from Activity Log and resource logs.

Still in use. Last-used data on AWS roles and access keys, service principal sign-in logs on Azure, and Activity Analyzer on GCP show whether an identity has been active. An identity with no activity for 90 days and standing access is a candidate for removal.

The gap the framework exposes: pilots that never ended

The most common failure behind this table is an ordinary one: an AI pilot that finished while its identities did not.

The pattern is familiar in regulated entities. A bank runs a three-month AI pilot with an external vendor. The vendor’s platform reaches the bank’s cloud through a cross-account role or a multi-tenant app. The bank’s own team wires a CI pipeline to deploy the agent, using a federated identity that trusts GitHub or another CI provider. The pilot ends, the contract lapses and the repository is archived. The identities stay, often with admin-level access, no owner and no activity for months.

Each part of that is a governance failure before it is a security failure. The AI inventory still lists the pilot as closed. Nobody is accountable for the identities because the people who created them have moved on. And there is no leavers process for an AI pilot, the way there is for an employee.

FREE-AI anticipates this. The report warns that limited visibility into vendors’ internal controls weakens due diligence (paragraph 2.2.5), and notes that when a vendor uses AI to deliver an outsourced service, current outsourcing agreements do not explicitly cover AI-specific governance, risk mitigation or data confidentiality (paragraph 3.2.3.1). Its sample AI incident reporting form asks, as a standard field, whether a third-party vendor was involved (Annexure VI).

The combination to look for has three parts:

• Dormancy: no use for more than 90 days.
• Standing privilege: admin-level or wildcard access still attached.
• External trust: a trust relationship to a vendor account, a vendor’s Entra tenant, or a broad OIDC subject such as any repository in the organisation.

Any one of these is a hygiene issue. All three together mean an outside party, or anyone who compromises that party, can walk back in with the pilot’s access. On AWS, the reactivation shows up as AssumeRole from the vendor account or AssumeRoleWithWebIdentity with an unexpected subject. On Azure, it is a sign-in by a dormant service principal. On GCP, it is a token exchange or call from a federated principal never seen before. First activity after long dormancy is one of the highest-signal identity events a team can alert on, because legitimate dormant identities rarely wake up without a change ticket.

Common questions about the RBI FREE-AI framework

What this looks like with a platform

Everything above can be done with native tools and some scripting, and for a small estate that is a reasonable place to start. The difficulty grows with scale: three clouds, dozens of accounts and subscriptions, and AI identities created faster than a spreadsheet can track.

This is the problem Cy5’s ion platform is built around. Its entity graph keeps a live inventory of human and machine identities, workloads, APIs and data stores across AWS, Azure and GCP, with the relationships between them, so the inventory question has a current answer rather than a quarterly one. Its CIEM view compares granted and used permissions per identity across all three clouds in one place, rather than through a different native tool and licence in each cloud.

ion does not decide which identities are AI agents; tagging and naming conventions still do that. The approach is simpler: every agent runs on an identity, and ion governs identities. The same identity records map to evidence for FREE-AI, SEBI’s cybersecurity framework for regulated entities [/blog/sebi-cscrf/], CERT-In directions and the DPDP Act, so one inventory serves several audits. More detail is on the Cy5 India compliance page.

What to do in the next 30 days

Three steps give a security team something concrete to show the board or an auditor:

1. List every AI system in production or pilot, and the cloud identities behind each. Include tool roles, MCP servers and any long-lived keys. Tag each identity with an owner.
2. Check the logs are on. Enable CloudTrail data events for the S3 buckets and Bedrock resources your AI systems touch, diagnostic settings for Entra sign-in logs and key Azure resources, and Data Access audit logs for the GCP services involved.
3. Find the orphans. Pull every identity with no owner, no use in 90 days, and admin-level access or external trust. Remove it or assign an owner.

The evidence also has a regulatory payoff. The committee recommends a graded supervisory approach (Recommendation 8): where an entity has followed safeguards such as incident reporting, root cause analysis, red teaming and independent audits, a first AI failure should not automatically trigger full supervisory action. Customers must still be compensated for any loss, and the leniency does not apply to repeated breaches or gross negligence. Either way, it depends on being able to show the safeguards were in place.

One limitation is worth stating plainly in any board note. Cloud audit logs prove which identity acted, not which model, prompt or user instruction drove it. Proving what an AI system was asked to do needs model invocation logging or agent tracing, such as Bedrock model invocation logging, and those are off by default. Identity evidence answers the accountability question for access; it does not answer it for intent.