? What is business email compromise (BEC)?
Business email compromise is a fraud where an attacker uses email — often from a real, compromised, or look-alike account — to socially engineer someone into taking an irreversible action: sending a wire, changing where payments are remitted, approving a purchase, or replying to a stranger with sensitive data. The message is only the delivery vehicle; the loss happens at the moment of the action taken in response, which is why a clean, deliverable email can still cause a large loss.
↳ tl;dr BEC is an irreversible-action problem, not a spam problem.
? How does RadMail stop BEC and wire fraud?
RadMail's firewall removes the dangerous action classes from what an autonomous agent can do at all. Moving money, changing banking or wire instructions, decisions that commit the account, contacting a new third party, and releasing a deliverable are human-only: the firewall will never return an auto-sendable reply for them, at any tenant, at any rollout stage. It refuses the exact action classes that cause the losses rather than trying to score intent more accurately — so a persuasive email cannot talk an agent into the dangerous action, because the agent was never able to perform it.
↳ tl;dr It refuses the irreversible action classes outright — human-only, forever.
? Why can't you just detect BEC with a smarter spam filter?
Because BEC mail is often perfectly deliverable, from a real or look-alike account, and grammatically clean, so a 'is this spam?' score does nothing. The malicious content is the same content the agent is asked to read and reason about, which turns the classic BEC playbook — urgency, authority, a plausible pretext — into a prompt-injection attack against the agent. RadMail's premise is that you cannot make these actions safe by classifying them more accurately; you make them safe by refusing to let an autonomous process perform them.
? What about a changed-banking-details email?
A changed-banking-details request is the single highest-yield BEC pattern — one accepted banking change redirects every future payment to the attacker. RadMail treats any new-banking signal as a permanent hard-stop: the agent will never auto-send a reply that acts on it, and a change-of-bank instruction surfaces to a human to review. This holds even for a well-known, long-trusted sender, because a known counterparty is never a key that unlocks money or banking changes.
↳ tl;dr Changed banking is a permanent hard-stop, even from a trusted sender.
? Can an agent connected to RadMail be tricked into sending money?
No auto-send tool for money exists to be tricked. The safety decision is deterministic — not a confidence threshold and not delegated to a model — and it fails closed: if the risk evaluation was not performed, the answer is hard-stop, not send. Obfuscation such as zero-width characters or base64-encoded payloads is normalized before scanning, so hiding the instruction cannot buy a bypass. A model drafts language; it cannot talk the firewall into sending.
↳ tl;dr The high-risk send is not exposed as a tool at all, and the system fails closed.
? Is RadMail fraud-proof or a guarantee against BEC?
No. RadMail is a tool, not a guarantee. It narrows what an autonomous agent can be tricked into doing by removing the dangerous action classes from its reach; it does not certify that fraud is impossible or claim any detection rate. It does not replace your own controls — bank-side call-back verification for banking changes, dual authorization for wires, SPF/DKIM/DMARC, and human judgment on the surfaced drafts remain your responsibility. Compliance is a shared responsibility, and RadMail is pre-release with its engine live in a two-business test bed.
↳ tl;dr A tool that shrinks the blast radius — not a guarantee, and not a replacement for your controls.