Governance is the product: letting AI send email safely

Most conversations about AI agents stall at the same place. The demo works. The agent drafts a credit-control chase, a tender cover letter, a compliance reminder, and it reads well. Then someone in the room asks the only question that matters: "So it just… sends that? To our actual customers?" And the demo ends, because nobody has a good answer.

That question is not about capability. The model is plenty capable. The question is about consequence — about what happens when an autonomous system acts on the outside world without a person watching each move. For an agent that genuinely runs operations, the thing that makes autonomy switch-on-able is not a better model. It is governance. At Usermode the governance is not a compliance layer bolted on after the fact; it is the product. The controls are what let you turn the agents on and leave them on.

The Real Blocker Is Not Capability

A chatbot that drafts a reply for you to send carries no real risk — you are the safety system. The moment you remove the human from the loop so the agent can send the email itself, every weak control becomes a liability. An agent that can send can also send the wrong thing, to the wrong person, twice, or to a supplier it was never meant to contact.

So the design principle is simple and we hold to it strictly: every autonomous capability is paired with a guardrail that constrains it. The agent does not get a power without also getting the rail that bounds that power. You do not adopt "an AI that sends email." You adopt a credit controller, Sarah, who can chase a specific overdue invoice, with a specific recipient, under an authorisation that expires — and cannot do anything outside that envelope, because the system physically prevents it rather than politely asking the model not to.

The rest of this piece walks the controls in the order they actually fire when an agent goes to send something into the world.

Fail Closed Roles The Default Is No

The first rail is the role itself. Each agent runs under a fail-closed tool policy: a read-only role is technically prevented from mutating systems, not merely instructed to behave. This is the difference between a sign on a door and a lock.

Take Aaron, the management accountant. He needs deep read access — Business Central, the ledgers, the reconciliations. He does not need to send anything to a customer. So the policy denies outbound send tools to his role outright. If a prompt injection buried in an inbound document tries to talk Aaron into emailing a "supplier," there is no send tool in his hands to misuse. The capability is absent, not suppressed.

A permission you never granted cannot be socially engineered out of you.

This matters because the dangerous failure mode for agents is not a refusal — it is a confident, plausible, wrong action. Fail-closed defaults mean the blast radius of any single agent is bounded by what its role can do, and that boundary is enforced at the tool layer where the model's reasoning cannot reach it. When we add a new capability to a role, we are making a deliberate, reviewable decision, and it shows up in CI through automated end-to-end guardrail tests that assert the deny-by-default behaviour still holds.

Every Send Needs A Signed Ticket

Read-only is the easy case. The hard case is the agent that genuinely must send — Sarah chasing debt, Jacob returning a tender, Henry issuing a compliance notice. For those, "you may send email" is far too broad a grant. We narrow it down to a single authorised action at a time.

Every external send requires a signed authorisation that is:

• •Signed with HMAC-SHA256, so it cannot be forged or edited. The agent cannot mint its own permission; the ticket is issued by the governing system and verified at the gateway before anything leaves.
• •Time-limited, so an authorisation that is not used promptly simply expires. A grant created this morning is not a standing licence to send all week.
• •Recipient-bound, so the authorisation is good for one recipient and not another. An approval to chase one client's overdue account is not a key that opens the whole address book.

Think of it as a single-use ticket rather than a season pass. The agent reasons about what to send and to whom, but the act of sending is gated on a cryptographic token that pins down the specifics. If any field drifts — different recipient, expired window, tampered payload — verification fails and the send is refused. This is the control that most directly answers the room's question. The agent does not "just send." It requests authority for a precise action, and only that action can occur.

For the genuinely autonomous patterns — an agent chasing suppliers on a daily schedule without a person triggering each run — the same machinery applies, with the authorisation issued under a standing, operator-approved grant rather than an ad-hoc one. The grant is explicit, scoped, and revocable. Default state is dark: the lane is off until an operator turns it on.

Approval Gates Where A Human Stays In The Loop

Not everything should be fully autonomous, and pretending otherwise is how trust gets burned. Some actions carry enough weight that a human belongs in the path — committing spend, anything touching money beyond a threshold, sensitive external communication. For these we use explicit approval gates.

The pattern is that the agent does all the work right up to the irreversible step, then stops and asks. It assembles the chase, drafts the letter, prepares the tender pack — and presents it for a yes over email, WhatsApp, Teams, or SMS. The human approves on their phone in seconds; the agent then proceeds under a fresh, signed authorisation for exactly the approved action.

This keeps two things true at once. The agent is doing the labour — the research, the drafting, the assembly, the follow-up tracking — so the human is not the bottleneck on volume. But the human still owns the decisions that ought to be owned. Autonomy and oversight are not a dial you slide between; they are layered. The agent is autonomous on the work and gated on the consequences that warrant a person.

The Ledger And Attribution

Controls that fire before an action are only half the story. You also have to be able to prove, afterwards, exactly what happened. Every meaningful action lands in a tamper-evident, append-only audit ledger. Append-only means history cannot be quietly rewritten; tamper-evident means any attempt to alter it is detectable. A run that sends an email leaves a durable record of what was sent, to whom, under which authorisation, and on whose approval.

Attribution runs through the whole stack. Each agent has a stable identity and acts through an OAuth 2.1 gateway on Entra ID, inside its own per-tenant Azure isolation — its own subscription, its own Key Vault, its own container environment. One company's agents cannot see or touch another's. Logs are redacted by default: no PII, no memory contents, no secrets in the trace. You get the forensic record without turning the audit trail into a second data-leak surface.

Inbound is treated as hostile until proven otherwise. Untrusted content — an email body, an attachment, a portal message — is sandboxed against prompt injection, so a malicious instruction hidden in a document cannot quietly promote itself into a real action. Combined with fail-closed roles, this means an attacker has to defeat both the sandbox and the absence of the tool. CI backs all of it with gitleaks and CodeQL, so secrets and known vulnerability classes get caught before they ship.

On certifications we stay honest: the agents inherit Azure's certified infrastructure, and formal certifications such as SOC 2 are on the roadmap rather than in hand. We would rather tell you that plainly than imply a badge we have not earned.

The Delivery Contract Cuts Both Ways

There is a subtle failure that governance has to handle in the other direction too. An over-cautious agent that hits a wall and simply goes quiet is its own kind of risk — the overdue invoice never chased, the compliance deadline never flagged, and nobody told.

So we hold agents to a delivery contract: a run cannot end without a real, logged outbound action. If an agent cannot complete the intended send — a guardrail blocked it, an authorisation could not be obtained, a system was down — it does not silently drop the task. It escalates to a human through whatever channel reaches them, and that escalation is itself logged. The same governance that stops the wrong send also stops the silent non-send. You are never left guessing whether the work happened.

That is what we mean when we say governance is the product. The guardrails are not the price you pay for autonomy. They are the reason you can switch it on — and leave it on — with named AI employees running real operations at Legacie and WH Scott Group today.

If you want to see the controls fire on a live agent, you can book a short walkthrough at /demo.