> ## Content Index
> Fetch the complete content index at: https://insights.securesalt.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Your inbox should not become a queue of investigations
- URL: https://insights.securesalt.com/articles/your-inbox-should-not-become-a-queue-of-investigations/
- Published: 2026-10-25T04:43:41.000Z
- Updated: 2026-10-27T17:26:22.000Z
- Description: The person bearing the consequences should have a say in the evidence required before a message reaches them.
- Author: Chris Econn
- Tags: #needs-refinement, Articles

An email asking for sensitive information can look official and still leave the recipient with the hardest questions: who is asking, and what are they entitled to request?

In September 2026, Revolut said it had disclosed customer information in response to fraudulent requests sent from an account on a legitimate government agency domain. According to company statements reported by [The Block on September 12](https://www.theblock.co/news/business/2026-09-12-revolut-says-customer-kyc-bitcoin-transaction-data-exposed-after-fake-request-from-govt-domain-414516?ref=insights.securesalt.com), its systems and customer funds were unaffected. [ANSA subsequently reported an Italian police investigation](https://www.ansa.it/english/news/2026/09/16/italian-postal-police-probe-revolut-customer-data-breach%5Fd51b059c-3123-4b88-a9b4-2464be379e34.html?ref=insights.securesalt.com).

The distinction matters: a legitimate channel had carried an illegitimate request.

## A familiar address is only the beginning.

We do not have Revolut's internal decision records. We cannot say which checks were performed, how the account came to be used, or which additional control would have changed the outcome.

We can ask what a recipient needs before acting on a consequential request.

Is the account genuine? Who is using it? Did that person approve this request? Are they entitled to ask for this information?

Those are different questions. An answer to the first cannot stand in for all the others.

## Another investigation in the inbox.

The familiar advice is to inspect the sender, examine the links, find another number, and call someone back. Sometimes those checks are necessary. But each one hands more work to the person receiving the message.

That person also has a job to do. A customer needs an answer. A colleague needs help. An official request may carry a deadline. We cannot build useful communication around the assumption that every recipient has the time and expertise to investigate every exchange.

Nor can we tell people to distrust everything. A channel nobody feels able to use has failed in a different way.

## Put the recipient into the assurance process.

This is what we mean by recipient advocacy: the person bearing the consequences should have a say in the evidence required before a message reaches them.

That does not mean giving them a longer checklist. The system should obtain the evidence, evaluate it against their requirements, and make the result understandable.

Verification of a person is one part of that work. Approval of a particular message is another. Authority to request sensitive records is another still. The evidence should match the decision being asked of the recipient.Salt Mail’s approach is to bring recipient-defined assurance into the exchange. Our objective is greater confidence with less investigative work. That is a design responsibility, not a claim that Salt Mail would have prevented this incident.

## Where we can step in.

Our controlled Microsoft probe demonstrated a useful boundary: an existing authenticated session need not be enough to complete a new request. With the intended API and authentication requirement in place, the request stopped and required the user's passkey again.

That is a concrete mechanism to build on. A system can require fresh proof before allowing a request to proceed. Our method tested both the ordinary session-reuse path and the stricter requirement, then checked the intended resource and policy evidence. The distinction is between assuming assurance and establishing that the requirement was met.For Salt Mail, the next step is to connect that mechanism to the recipient's requirements and the particular message awaiting delivery. The probe established the authentication boundary; message approval and authority remain distinct requirements.

The [companion research note](https://insights.securesalt.com/research/session-authority-and-recipient-assurance-research-notes/) explains the method, the results, and the remaining delivery validation. It examines a control we can build on, rather than reconstructing how Revolut's incident occurred.

People should exercise judgment. They should also be able to expect the systems carrying their communications to do more of the verification work.

A worthwhile inbox should help people act with confidence. It should not become a queue of investigations.