Incident ResponseThreat IntelligenceAI Security
There is a particular kind of breach notification that offers no comfort at all, because there is nothing in it to patch. No CVE. No misconfigured bucket. No phished admin. Just a description of a process that ran exactly as designed, and a list of what left the building because of it.
Revolut published one this week.
In a notice reported on September 12, 2026, Revolut told a subset of its customers that their personal and financial information had been handed to an unauthorised third party. The company's own description of what happened is the most important sentence in the whole story:
"Revolut recently identified a sophisticated external impersonation scam where an unauthorized third party utilized a legitimate government agency domain email to submit fraudulent requests for information."
The data disclosed, according to BleepingComputer and SecurityWeek, was not a marketing list. It included names, dates of birth, occupations, postal and email addresses and phone numbers; copies of identity documents including passports and driver's licences; the facial verification selfies taken at onboarding; and IBANs, account statements, withdrawal records and full transaction history, Bitcoin activity included.
That is, more or less, everything required to impersonate a person to a bank — plus a photograph of their face and a map of their money. Crypto investigator ZachXBT suggested the requests were aimed at high-net-worth users, which would make the transaction history the point rather than a bonus.
Revolut says its systems and customer funds were unaffected, that it has contacted "the limited number of impacted individuals directly", and that it blocked the sending address and notified the agency concerned, law enforcement, data protection authorities and financial regulators. It has not said how many customers, or which agency.
On the narrow technical question, Revolut is right: nothing was hacked. That is the part worth sitting with.
The load-bearing phrase in Revolut's account, reported by BleepingComputer, is that the message "carried valid domain authentication credentials" and so "was fulfilled under the reasonable belief that it was an authentic government agency request."
Read that as a control statement and it falls apart immediately. SPF, DKIM and DMARC are transport controls. They answer one question — did this message really originate from a server authorised to send for this domain? — and they answer it well. They say nothing whatsoever about whether the human at the keyboard is entitled to the data they are asking for, or whether a legal basis exists, or whether the mailbox is still under its owner's control.
The industry spent fifteen years telling organisations to trust authenticated mail more and unauthenticated mail less, and that advice was correct in its own domain. The failure mode is what happens when a transport check gets quietly promoted into an authorisation decision because it is the only check available at the moment someone has to answer.
Revolut's phrasing — reasonable belief — is honest, and it is also the whole problem. Reasonable belief is what you are left with when your verification process has no independent channel in it. The gap is neatly summarised in AML Intelligence's analysis of the incident: defences here "are built to confirm a server, not a sender."
None of this is novel, which is the uncomfortable part for anyone running a compliance desk.
Fraudulent emergency data requests — EDRs — have been a known criminal technique since at least 2022, and the FBI issued a formal warning in November 2024 about a surge in compromised police and government email accounts being sold and used for exactly this. Criminals phish an officer, buy an already-compromised agency mailbox on a forum, and then submit requests that are indistinguishable from real ones because, at the transport layer, they are real ones. AML Intelligence notes credentials changing hands for as little as $100, against a backdrop of data requests growing roughly 40% year on year — hundreds of thousands of legitimate requests annually, each one creating pressure to answer quickly.
That volume is the attack surface. A fake EDR does not need to beat your controls. It needs to arrive looking like one of the several hundred genuine requests your team will process this quarter, carry enough urgency to discourage a callback, and land on someone whose job performance is measured partly on turnaround time.
Revolut was not the only organisation this month to discover that a message can pass every check and still be a lie.
On September 10, Microsoft published details of an AI-assisted executive impersonation campaign that sent more than a million emails between August 3 and 5, 2026, 87.7% of them to recipients in the United States. The messages impersonated targets' own CEOs, CFOs and presidents alongside ServiceNow branding, and asked accounts payable to process an ACH payment of nearly $50,000 for a supposed annual subscription.
The delivery mechanism is the part that rhymes with Revolut. Rather than spoofing domains, the operators sent through multiple third-party email service accounts — established bulk-delivery platforms whose infrastructure already carries a legitimate sending reputation and passes authentication checks on its own merits. And Microsoft's analysis found the templates themselves bore the marks of generative AI: verbose HTML comments, structured section labelling, uniform construction across samples, consistent narrative scaffolding with only the invoice identifiers varying.
Two incidents, one shape. In both, the receiving organisation's trust signals were not defeated. They were borrowed. And in the second, AI supplied the thing that used to give these campaigns away — fluent, plausible, correctly-formatted English at volume.
Here is where a compliance story becomes an AI security story, and not by analogy.
Financial services firms are actively putting language models into inbound-request handling: triaging law enforcement and regulator correspondence, summarising the ask, pulling the customer file, drafting the response. It is an obvious application. The work is high-volume, text-heavy, deadline-driven and formulaic — exactly the profile that makes automation attractive.
It is also the single worst place to reduce a decision to the evidence contained in the message, for three reasons.
The model can only see what the attacker chose to send. A human analyst can pick up the phone, look up the agency's published contact details independently, and call back. A model working from an inbox has no out-of-band channel at all. Its entire evidence base is the sender domain, the headers, the letterhead, the legal citations and the tone — every one of which the attacker controls or has borrowed.
Urgency is a feature of the request, and models are trained to be helpful. A fake EDR works on humans because it manufactures time pressure. A model has no instinct that a deadline is suspicious, and considerable instinct to comply with a clearly-stated, well-formatted request.
The request is untrusted third-party text entering a prompt. This is the same channel that carries indirect prompt injection — as we covered when hidden instructions were smuggled into email for an AI summariser to obey. A fraudulent request that also contains instructions for whatever assistant reads it is one message, not two, and the customer's passport scan is already in the context window because the assistant fetched it to answer.
At that point, the compliance failure and the AI data-egress failure stop being two problems. They are one event, with one log entry, and most organisations are only instrumented to notice the first half.
The boundary first, because it matters here more than usual: Obiguard cannot tell you whether a government request is genuine. No product can. That verification is a phone call to an independently-sourced number, made by a person, and if your process does not contain one, no amount of AI governance substitutes for it.
What Obichat addresses is the second half of the problem — what happens to the customer's file once a member of staff starts using AI to deal with the request. Under deadline pressure, with a passport scan and a transaction history open on screen, the shortest path to a drafted response is a personal ChatGPT tab. That is the realistic failure, and it converts a disclosure incident into a disclosure incident plus an uncontrolled transfer of identity documents to an endpoint nobody approved.
Three properties are relevant to this specific workflow:
Attribution to a named person. Staff sign in through SAML or OIDC, and each workspace is scoped to the team that needs it. When the question is who handled this request, and what did they do with the customer's documents, the answer is a person, not a shared account — which is precisely the property that was missing on the other side of the Revolut exchange.
Untrusted text gets inspected before it reaches a model. The body of an inbound request is third-party content. Every message in an Obichat workspace passes through the inspection layer under its assigned policy set, where PII and payment data are redacted and jailbreak or prompt-injection attempts are caught — so an instruction buried in a pasted "urgent agency request" does not get a free ride into the prompt along with the text the analyst meant to send.
The record survives the incident. Each workspace keeps an exportable log of conversations and events, mapped to NIST AI RMF and ISO/IEC 42001. Six weeks later, when a regulator asks what your team put in front of a model while handling requests about a specific customer, that is a query rather than an archaeology project. Obichat can run as a private deployment in your own AWS, Azure or GCP tenant if the data cannot leave your perimeter.
Where the handling is automated rather than human — an agent reading the mailbox and drafting replies over an API — the equivalent controls sit in Governance AI: the agent's credential is scoped to approved models and tools by allow-list, policy is resolved server-side so nothing in a request can loosen it, and every prompt, response and policy decision lands in the audit ledger, with anything flagged for human judgement held in the Review Queue rather than sent. An automated desk should not be able to release a passport scan without a person's name attached to that decision.
For two decades, the defensive advice on email has been verify the sender. Organisations did the work — SPF, DKIM, DMARC, BIMI, the lot — and the result is genuinely a better internet.
But the attackers moved to the one position the entire edifice does not cover: standing inside a legitimate domain, asking politely, in correct English, for something the process is designed to give them. Revolut's controls were not bypassed. They were satisfied. And now AI is quietly removing the last informal tell, because the badly-written request that used to trigger a second look is not badly written any more.
So the question is not would our mail gateway have caught that? It almost certainly would not have, because there was nothing to catch.
The question is: when one of your people releases a customer's passport, selfie and full transaction history tomorrow, what independent thing will they have checked first — and will anyone be able to prove afterwards that they checked it?
Explore Obichat or talk to us about keeping a record of what your staff and your assistants do with a customer's file, before someone asks you for one.
Obiguard sits in front of every AI request your organization makes — screening prompts and outputs against the guardrails, compliance frameworks, and audit trails that stories like this one make necessary.
See how it works →