On 19 October 2026 the Reserve Bank of India reportedly told banks, payment system operators and other regulated entities to treat their technology environments as compromised after credential exposure or confirmed unauthorised access, until a forensic investigation shows otherwise. Kotak Neo's report is the source we could verify, and it dates the advisory to 19 October. We could not locate the RBI circular itself. The RBI homepage and its notifications list for 9 to 30 October showed no matching item when checked. Everything below about the RBI document is therefore secondhand.
Where the detail actually comes from
The specific controls in the hook are published in a primary document, but a different one. CERT-In's advisory "AI Agents as Attack Vectors," originally issued on 15 October 2026, recommends that organisations "treat the environment as compromised until forensically cleared" after any credential exposure or confirmed access. It also recommends multi-factor authentication for all administrative access, removing management interfaces from the internet, a complete API inventory, and retaining logs for at least 180 days.
The pattern is clear. CERT-In wrote the technical playbook, and the RBI reportedly relayed it to its own regulated entities four days later. That is a sensible division of labour. A sectoral regulator should not reinvent incident-response doctrine. But the source matters for accountability. A bank told to "assume compromise" needs to know whether the instruction is a recommendation, a supervisory expectation or a binding direction. Only the RBI text can say, and it is not public.
The case for the advisory
The strongest argument for a firm stance is speed. CERT-In says agentic tooling has compressed the time between initial access and final impact from days to a few hours. Its reported finding that victims did not detect the intrusions themselves, and learned of them from AI model providers, is a detection failure. The root weaknesses it names are mundane: internet-exposed management interfaces and unpatched middleware with weak credentials or no multi-factor authentication.
In that setting, "assume compromise" is not alarmism. After a credential leak, the dangerous mistake is rotating one password and declaring victory while an attacker keeps a foothold elsewhere. A payments system holds money and personal data, and a failure there reaches ordinary customers. A presumption of compromise, lifted only by forensic evidence, puts the burden of proof on the institution. That is where it belongs.
Where proportionality enters
The measures are mostly good hygiene, which is why they are hard to object to. Three issues deserve attention anyway.
- Logging is not new, but its scope matters. CERT-In's 28 April 2022 Directions under section 70B(6) of the IT Act already require service providers, intermediaries, data centres, body corporate and government organisations to enable logs of all ICT systems and keep them for a rolling 180 days within Indian jurisdiction. The same Directions require reporting of specified incidents within 6 hours. A 180-day recommendation therefore restates an existing duty. Regulators should say so, so that compliance teams do not read it as a fresh obligation.
- "Compromised until cleared" has a cost. Taking a core system offline for forensic clearance is justified when evidence of intrusion exists. Applied reflexively to every low-grade credential exposure, it could cause outages that harm customers more than the exposure would. Smaller cooperative banks and fintech start-ups have thinner forensic capacity than large lenders. The advisory should tie the response to the severity and scope of the exposure, not leave each entity to guess.
- The AI-agent framing is narrower than the headlines suggest. CERT-In describes two problems: agents under evaluation that strayed onto live systems of Indian organisations, and criminals using open-source agentic offensive tools. The cited weaknesses, such as exposed credentials and unpatched middleware, are old. The right response is better basic security, not new restrictions on AI research or on open-source security tools that defenders also use.
What a pro-innovation approach looks like
India's financial sector depends on fast, cheap digital payments. Security rules that are clear, risk-tiered and published support that growth, because they let firms plan. Rules that circulate as reported paraphrase do the opposite. Entities over-comply out of caution, or under-comply out of confusion.
Three changes would improve the framework without weakening it:
- Publish the circular. The RBI should post the advisory on its website with its legal basis and a statement of whether it is binding.
- Separate the recommendation from the mandate. Where a measure restates the 2022 Directions, such as 180-day log retention, the text should say so. Where it is a new supervisory expectation, it should come with a compliance timeline.
- Scale the response. The forensic-clearance expectation should have a proportionality clause, with lighter paths for contained, low-severity exposures.
CERT-In's decision to publish its findings openly is the better model. The advisory is on its site, with its recommendations numbered and its reasoning stated. Sectoral regulators relaying that work should be just as transparent.
Bottom line
The substance here is defensible. Presuming compromise after credential exposure, enforcing multi-factor authentication on administrative access and shutting dormant APIs are low-regret steps. The weakness is procedural. The primary RBI document was not locatable on 3 November, and the advisory's most specific requirements come from CERT-In. Until the RBI publishes its text, readers should treat the RBI-specific details as unverified and the CERT-In details as confirmed.