A supplier's mailbox was hijacked to send real-thread requests — which requests get out-of-band confirmation?

## Start by naming the constraint you cannot move The mailbox is the supplier's. You have no ability to change how it is secured, no visibility into how the access was obtained, and the only lever that reaches it — the contract — moves on a timescale of renewal cycles. Any answer that begins 'we require the provider to enforce stronger authentication' is not wrong as a long-term ask, but it does not answer the question in front of you and an interviewer will push on that. What you do own is the other half of the exchange: what a request arriving in a conversation is permitted to accomplish inside your organisation. That is the surface where the design decision lives. ## Why 'confirm everything' is the wrong answer Blanket confirmation fails in two directions, and being able to articulate both is most of what separates a principal answer from a senior one. It fails commercially. Every confirmation step is somebody's minutes, on both sides, on a request that is almost always genuine. Applied to routine traffic it is a standing tax the business can price, will resent, and will eventually route around. It fails on its own terms, and this is the more interesting failure. A step performed a hundred times a week stops being a check and becomes a ritual. The person completing it develops exactly the habit the fitted request exploits in the first place — the ordinary Thursday action, performed correctly, without deliberation. You have not added judgment; you have added a second routine that can also be satisfied on autopilot. Friction only functions while it is rare enough to feel like an interruption, which means the scope decision is not a compromise with the business, it is a condition for the control working at all. ## The axes worth scoping on **Reversibility.** Can the effect be undone within a day, by someone who is not the requester? A report sent to the wrong address is embarrassing and mostly recoverable; a redirected standing output is not, because you may not learn about it for months. **Standing versus one-off.** A one-off action expends itself. A change to a standing arrangement — where something is delivered, who is on a list, which account holds an access grant — keeps paying the operator after the conversation is forgotten. Fitted requests aim at standing changes for precisely this reason, and the routine ask is often the wrapper around one. **Blast radius.** How many downstream parties inherit the change without ever seeing the request? **Frequency.** If a candidate class fires more than a handful of times a week, either it does not belong in scope or the underlying process needs restructuring so it stops arriving by conversation. Frequency is a design input, not an afterthought. Notice what is not on the list: how urgent the message sounded, whether the sender was external, and whether anything about the wording seemed off. Scoping on message properties reintroduces the judgment that the fitted request already defeated. ## Make the confirmation actually out of band The step is worthless if the operator supplies the channel. Confirmation must use contact details you already hold from a source independent of the message — a record you maintain, not a signature block, not a phone number in the body, not a reply to the thread, which reaches whatever `Reply-To` was set to. This sounds obvious and is the most common way the control is implemented uselessly. Cheap synthetic voice has also made a returned phone call weaker evidence than it was, which argues for confirming through a channel the counterparty must authenticate to rather than one they merely answer. ## The better move, where it is available Confirmation is a compensating step; it accepts that the request can be actioned from the thread and adds a check. The stronger control class removes the dependency. If a standing destination can only be changed by the counterparty themselves, in a system where they authenticate as themselves and the change is visible to both sides, then the authentic thread, the genuine sender and the perfect prose all buy the operator nothing. There is no request to confirm because there is no request — there is a self-service change under the counterparty's own authority. That migration costs real work and cannot be done for every interaction, which is exactly why the friction budget exists: use confirmation for the classes you have not yet migrated, and treat each migration as retiring a line of that budget. ## Owning the decision Be explicit that you are buying down loss magnitude, not likelihood. Nothing here makes the supplier's mailbox safer or the message easier to judge. It caps what a believed message can achieve. Say who owns the list of in-scope request classes, how it gets reviewed when the business adds a new process, and what you will ask of the supplier contractually — prompt notification of mailbox compromise, and a counterparty-authenticated channel for standing changes — while being honest that neither is enforceable in the moment that matters.