The misdirected certificate problem
In testing, inspection and certification, the inbox isn't where the work is described — it's where the work happens. Which is exactly why one message to the wrong recipient is a different kind of problem here than almost anywhere else.
Walk a coordinator through their day and it's all email. The nomination arrives by email. The sampling instructions go out by email. The certificate of analysis comes back from the lab, gets checked, and is forwarded to the client by email. The terminal confirms the loading by email; the trader asks for the quantity figure by email; the agent chases the outstanding paperwork by — email. The inspection happens on a jetty or in a tank farm, but the business of inspection arrives and leaves through an inbox. For a coordination desk, the mailbox isn't a communication tool sitting alongside the operation. It is the operation.
That's worth stating plainly, because it changes what "a mistake in the inbox" means.
Name the fear
Every operations manager in this trade already knows the sentence that keeps them up. One certificate of analysis sent to the wrong counterparty. One quantity figure copied to the wrong trader. One confirmation issued to a terminal that nobody was authorised to give.
None of those is a typo you laugh about later. A COA in the wrong hands is a confidentiality breach in a market where a single figure moves money. A quantity to the wrong party is commercial information leaking to exactly the person who shouldn't have it. An unauthorised confirmation to a terminal can commit the firm — and the client — to something no one signed off. This is commercial exposure and legal exposure at the same time, and it arrives through the most ordinary action in the building: someone typing a name into a "To" field and pressing send.
And there's a second edge to it that's specific to this industry. A TIC firm doesn't just have a process-control problem when this happens — it sells process control. Impartiality, chain of custody, controlled release of results: that's the product. A misdirected certificate isn't only an operational slip; it's a failure in the exact discipline the accreditation body assesses you on. It's the plumber's own leaking tap, and your assessor is the one who notices.
Why this gets worse with an AI in the inbox
The honest reason firms are looking at AI email assistants is that the volume is real and the coordinators are drowning. That's a good instinct. But the way most AI email tools are built quietly makes the misdirected-certificate problem worse, not better.
Generic AI email tools optimise for autonomy. The pitch is that the assistant reads the thread, works out what's needed, and handles it — recipients included. The implicit safety story is "the model is usually right." And it usually is. But "usually right" is not a control. A control is something that holds on the day the model is wrong, and at inspection volumes there will be such a day.
The failure mode here isn't a rogue AI or a malicious prompt, though those exist too. It's more boring and more likely than that: a free-typed recipient field, operating at scale, with a plausible-looking wrong address that a busy human would also have missed. When the assistant is choosing who receives a certificate by inference, you haven't removed the misdirection risk — you've automated it and taken the human's eyes off it. The very thing you bought to reduce mistakes now makes them faster and quieter.
What an actual control looks like
The fix isn't a more careful model. It's putting a boundary in front of the model that doesn't depend on the model behaving. Four mechanisms, described as mechanisms rather than features:
Recipients constrained to an approved list, enforced outside the AI. Every outbound message is checked against your approved counterparty list on the server, on every send, before it leaves. Not a prompt telling the model to be careful — a hard rule the model cannot talk its way past, because it runs outside the model. If a recipient isn't on the list for that piece of work, the send doesn't happen; it's held for a person. This is the mechanism that turns "the assistant is usually right about recipients" into "the assistant cannot send a certificate to a counterparty you haven't approved." Those are different promises, and only the second one survives a bad day.
Inbound authenticated and screened before any model reads it. Every incoming message is verified — SPF, DKIM, DMARC — and run against your policy on the server before it reaches the LLM at all. A spoofed "known" sender is caught; a message from an unrecognised party is escalated to a human rather than acted on. The point is that the assistant never acts on the strength of a "From" line alone, because in this industry an instruction is only as trustworthy as the proof it came from who it claims to.
Every decision written to a tamper-evident record. Who sent it, what the verification verdicts were, what the assistant decided, what reply went out. Hash-chained, timestamped, exportable. This is the mundane control that earns its keep the day a counterparty disputes what was said or what was sent — you don't argue from memory, you produce the record. For an accredited body it's also the evidence your assessor is going to ask for anyway, generated as a by-product of the work rather than reconstructed afterwards.
A human grants every capability. The assistant doesn't widen its own permissions or add its own recipients. You decide which senders it may hear from and which counterparties it may write to; it operates inside that, or it escalates.
If those four sound familiar, they're the same boundary we've written about before — the security-review checklist for giving an AI agent an email address is the vendor-neutral version of the questions, and how we govern the assistant is the detail of how each one is enforced. The OpenClaw episode earlier this year was the same lesson learned in public: broad reach plus an open input channel plus no record of what happened. An inbox hands an assistant all three by default.
You don't have to take any of this on trust
Here's the part that matters most for a decision like this: none of it is a claim you have to believe. It's measurable, before anything is live.
A shadow-mode assessment is one forwarding rule from your existing inbox. Nothing migrates. Nothing is ever sent. For three to four weeks the assistant reads your real operational traffic and drafts what it would have done — including who it would have sent each certificate to — and you get that back as a report. You see the handled rate on your own mail, and you see the recipient decisions with your own eyes, before a single message leaves the building. If it's not convincing, you've lost a forwarding rule and a month.
That's the only honest way to buy something that sits this close to the business. If you'd like to see what an AI worker would have done with your real traffic, the inspection-firm assessment is where it starts.