To protect your bank from AI-led cyber threats, you need to reduce what attackers can reach. That means fewer systems open to the internet, tighter checks on third-party tools, faster patching, and keeping key defences inside your own network. India’s banking working group recommends the same three things: shrink your attack surface, use defensive AI agents, and fix your patching.
This is urgent now. RBI says AI-enabled cyber threats are the biggest systemic risk to India’s financial sector. Banks must finish a board-approved gap check and action plan by the end of June 2026.
Contents
What Indian Banks Are Doing Right Now
This is no longer just talk. India’s banks have picked 25 OEMs, whose tools are already used across the sector, to work with on AI risk.
At the same time, a working group led by State Bank of India is building a wider framework. Its job is to help lenders find gaps and weak spots before attackers do.
This is a serious group. It includes nine banks, the finance ministry, RBI, NPCI, and CERT-In.
Their plan has three parts. Reduce the network attack surface. Deploy defensive AI agents. Improve patch management. This guide follows that plan.
What RBI Is Asking For
RBI has told banks and regulated entities to run a board-approved gap check on AI risks. The action plan is due by the end of June 2026.
You need to do three things. Set up a proper cybersecurity framework. Run AI-led tests against your own systems. Find the weak spots you already have.
One thing to note: your Board must sign this off. It is not just a CISO job. RBI has been clear that cybersecurity sits at board level.
Why AI Makes Attacks Worse
The numbers tell the story. Cyber incidents went up to 2.9 million in 2025, from 1.4 million in 2021.
The working group named four main AI threats: deepfakes, synthetic adversarial LLMs, supply chain attacks, and cloud exploitation.
CERT-In warns that AI-assisted attacks find and exploit weak spots much faster. The risky areas are apps facing the internet, APIs, cloud platforms, operational tech, and software supply chains.
A joint report by SISA, CERT-In and CSIRT-Fin calls this “AI asymmetry.” Attackers are getting stronger faster than defences can keep up. The report cites a case from November 2025 where AI did 80 to 90 percent of the work on its own, hitting around 30 targets worldwide including financial firms.
What This Means In Practice
Before, a hacker had to find your weak spot by hand. That took time. That time was your safety margin.
AI removes that margin. What took weeks now takes far less. Anything you leave exposed gets found sooner.
So the rule changes. Reducing what is exposed now matters more than reacting quickly after a hit.
The Third-Party Risk Nobody Talks About
The working group put it plainly: risks can come from third-party vendors. This is the part most banks underestimate.
Here is the hard truth about supply chain flaws. The bug is usually not new. It often sits in the code for years before anyone spots it.
Log4Shell is the classic case. The flaw lived inside a common logging library long before it was made public in December 2021. By then it was inside software all over the world. Banks were not hit by a new bug. They were hit by an old one nobody had found.
That is why third-party and open-source code is risky at scale. One bad shared library can sit quietly inside hundreds of systems. The day it is disclosed, everyone using it is exposed at once.
AI makes this worse in one clear way. Attacks now start faster after a bug is made public. You get less time to patch.
Why Open Source And Third-Party Code Is So Risky
There are four reasons this risk keeps catching banks out.
Nobody owns the fix. With a vendor product, someone is contractually responsible for patching. With an open-source library, it may be maintained by a handful of unpaid volunteers, or nobody at all. If a flaw appears, there is no support contract and no SLA.
You inherit risk you never chose. Your vendor uses a library, that library uses another library, and so on. You did not pick those, you may not know they exist, and you are still exposed to every one of them.
Attackers get the source code too. Open-source code is public. Anyone, including attackers using AI tools, can read it looking for flaws. CERT-In has warned that AI-assisted attacks speed up exactly this kind of discovery.
One flaw hits everyone at once. Because the same libraries are used everywhere, a single disclosure exposes thousands of organisations on the same day. There is no staggered rollout of risk.
None of this means open source is always wrong. It means unmanaged, unaudited, unknown third-party code is wrong, especially in a regulated bank.
What You Can Do
You cannot remove every outside component. But you can know what you are running. That is what an SBOM is for.
An SBOM (Software Bill of Materials) is simply a list of every third-party and open-source part inside a piece of software.
Without it, you cannot answer the one question that matters when a new flaw appears: do we use this, and where?
Ask every vendor for an SBOM before you buy. Since the working group is focused on OEM tools already running across the sector, knowing what is inside those tools is now a board-level issue.
Simple Steps To Cut Your Exposure
These are the practical controls most regulated banks use.
- Zero Trust access. Drop old VPNs. Check every user and device every time, inside or outside your network.
- Micro-segmentation. Keep core banking systems separate from web apps. If one part is breached, the attacker cannot move across.
- Patch faster. The working group named this directly. Unpatched systems are the easiest thing for AI-assisted attackers to find.
- Check third-party code. Audit outside libraries, vendor tools, and AI-written code before you deploy them.
- Lock down your APIs. Limit what faces the internet, use mutual TLS, and block unusual automated traffic.
- Take critical systems offline. If a system does not need the internet, disconnect it. An offline system cannot be reached from outside.
These match what RBI already expects: network segmentation, privileged access control, endpoint protection, and yearly VAPT on internet-facing apps.
Why Keeping Things On-Premise Helps
Cloud exploitation is one of the four named threats. And cloud-based security tools carry their own risk. Your data travels out to an external service, which adds API endpoints, credentials, and another vendor in the path.
On-premise removes that path. Detection and fixes happen inside your network. Your data never leaves.
| Cloud-based defence | On-premise defence | |
|---|---|---|
| Where your data goes | Out to an external service | Stays in your network |
| Attack surface | Cloud APIs and vendor risk | No cloud exposure |
| If internet goes down | Stops working | Keeps working |
| Compliance | Cross-border data questions | Simpler for RBI and DPDP |
This is also where “defensive AI agents” become real rather than a buzzword. An agent running on the endpoint itself can spot problems and fix them without sending your data outside.
No setup removes risk on its own. On-premise cuts your exposure, but you still need the segmentation, access control, and patching above.
How Anakage Helps
If you are working through the RBI gap assessment, here is where Anakage fits against the working group’s three priorities.
It runs fully on-premise. There is no cloud dependency. Detection and remediation happen inside your network, so telemetry and endpoint data never leave your perimeter. That removes the cloud API exposure that comes with cloud-hosted security tools.
It reduces your attack surface. Because nothing calls out to an external cloud service, there is no extra internet-facing path for an attacker to target. For air-gapped and isolated segments, it keeps working where cloud tools simply cannot reach.
It gives you defensive automation on the endpoint. This is the practical version of a defensive agent. It detects issues on the device and fixes them automatically, without shipping your data outside or waiting for a user to raise a ticket.
It supports patch and driver discipline. The working group named patch management as a priority. Anakage detects missing patches and outdated drivers across the fleet and remediates them automatically, using validated OEM catalogs rather than generic packages.
It produces audit evidence. Every action generates execution logs with device details, versions, and outcomes. That is what your IS auditor and your Board will ask for, and it is difficult to produce by hand.
It keeps you in control of your data. For RBI and DPDP obligations, where data sits matters. On-premise means your data stays where you can prove it is.
Anakage is not a replacement for segmentation, Zero Trust, or a security operations centre. It is the endpoint layer: keeping devices patched, compliant, and automatically fixed, with the evidence trail to prove it.
Frequently Asked Questions
Q: What are Indian banks doing about AI-led cyber threats?
A: Banks have picked 25 OEMs whose tools are already widely used, to work with on AI risk. An SBI-led group with nine banks, the finance ministry, RBI, NPCI and CERT-In is also building a wider safeguards framework.
Q: What does RBI want banks to do in 2026?
A: Run a board-approved gap check and produce an action plan by the end of June 2026. This includes setting up a cybersecurity framework, running AI-led tests, and finding existing weak spots.
Q: How much have cyber incidents grown?
A: They rose to 2.9 million in 2025, up from 1.4 million in 2021. RBI now calls AI-enabled cyber threats the top systemic risk to India’s financial sector.
Q: Which AI threats are banks preparing for?
A: Four types: deepfakes, synthetic adversarial LLMs, supply chain attacks, and cloud exploitation. Each one targets a different weak point.
Q: Why is third-party and open-source code risky?
A: One flaw in a shared library can sit unnoticed for years while spreading into many systems. Log4Shell proved it. The bug existed long before it was made public in 2021, and by then it was everywhere.
Q: Does going on-premise really reduce risk?
A: Yes, in one specific way. It removes cloud API exposure and keeps your data inside your network. But it does not replace segmentation, access control, or patching.
Protecting your bank from AI-led threats comes down to exposing less. Fewer systems open to the internet. Fewer unchecked third-party parts. Faster patching. Less data leaving your network. With the June 2026 deadline close, the gap check is the place to start.
If your team is preparing the RBI gap assessment and wants endpoint detection and fixes that run fully on-premise, Anakage offers a compliance-focused demo at https://anakage.com/contact-us.html.
Sources and References
- Banks to Tap 25 OEMs in Battle against AI-led Cybersecurity Threats — Dheeraj Tiwari, The Economic Times
- RBI asks banks to assess AI risk gaps, draw action plan by June-end (Business Standard)
- Govt-backed report on frontier AI models attacking banks (ThePrint)
- Regulatory frameworks for AI-driven cybersecurity — CERT-In data