Outbound messages

Check AI-written emails before they’re sent, not after.

Approving every automated email defeats the point of automating. Approving none is how an internal note ends up in a customer’s inbox. Check each email against your rules and only hold the ones that need a person.

Start freeSee an example

Approve the exceptions, not every email

Human approval for every email turns your team into a bottleneck, and people approving dozens of drafts an hour stop reading them. A check before sending lets routine emails go out on their own while the ones that break a rule, or that your policy reserves for a person, wait for approval.

The rule doesn’t care who wrote the draft. The same check works for AI-generated replies, mail-merge templates with a bad variable, and emails written by a new teammate.

Where the check fits

One call between the step that prepares something and the step that sends, publishes, or runs it. Your code applies the decision.

See it decide

The same policy evaluated on three cases. Pick one and run the check to see which evidence it relies on.

Policy

Outgoing customer emails may only reference the recipient’s own orders and the facts in data.facts. Never promise delivery dates or compensation that aren’t in data.facts, and never quote internal notes. Replies to complaints that threaten legal action, or that admit fault on the company’s behalf, need account manager approval in data.approval.

data

{
  "to": {
    "email": "ana@client.com"
  },
  "customerMessage": "Any news on my order?",
  "draft": "Hi Ana, your order #1042 shipped today. Tracking: 1Z999AA1.",
  "facts": {
    "orderId": 1042,
    "status": "shipped",
    "tracking": "1Z999AA1"
  },
  "internalNotes": [
    "Asked twice about tracking"
  ],
  "approval": null
}

Result

violationProbability—
reviewProbability—

Why: Every fact in the email matches data.facts, and nothing from the internal notes appears.

Your code: Send through your email provider.

Response JSON
{
  "decision": "allow",
  "allowed": true,
  "violationProbability": 0.03,
  "reviewProbability": 0.05,
  "policyId": null,
  "policyVersion": null,
  "requestId": "req_7f3a…"
}

Illustrative example. Real probabilities depend on your policy wording and the evidence you send.

allow · Routine update

Every fact in the email matches data.facts, and nothing from the internal notes appears.

deny · Leaked internal note

The draft quotes an internal note and promises Friday, but data.facts has no ETA.

review · Legal threat

The customer mentions lawyers and the draft admits fault for the company. Nothing in it is false, but the policy reserves this reply for the account manager.

Where the check goes

Place it right before the call that sends: your provider’s API (Resend, SendGrid, Postmark, Gmail), a CRM sequence step, or the “send” node in an automation. Include:

  • The exact draft, subject, and recipient.
  • The facts the email is allowed to state: order status, dates, amounts.
  • Internal notes, if they exist, so the check can tell when one leaks into the email.
  • Any approval already recorded for this email.

Set it up

  1. 1

    Describe what an email must not do

    Leaks, invented promises, wrong recipient, missing approval. Plain language is enough.

  2. 2

    Check right before send

    Call Enforly with the draft and the facts. One check per email, even if you evaluate several saved policies.

  3. 3

    Send, hold, or return

    Send on allow. On review, hold it for approval. On deny, return it with the reason.

Before calling your email provider
import { Enforly } from '@enforly/sdk'

const guard = new Enforly({ apiKey: process.env.ENFORLY_API_KEY })

const result = await guard.check({
  policyIds: [EMAIL_POLICY_ID, CUSTOMER_DATA_POLICY_ID],
  data: { to: recipient, subject, draft: body, facts, internalNotes, approval },
})

if (result.allowed) await resend.emails.send({ to: recipient.email, subject, html: body })
else if (result.decision === 'review') await approvalQueue.add({ recipient, subject, body })
else await drafts.return(draftId, result.results)

Full request and response fields are in the API reference. Using a coding agent? Point it to Build with AI.

What Enforly doesn’t do

Enforly evaluates the information you send and returns a decision. It doesn’t run operations, and it doesn’t guarantee safety or compliance on its own.

  • Enforly judges the draft and facts you send; it doesn’t read your inbox or CRM.
  • It doesn’t send, edit, or queue emails. Your code or automation does.
  • Don’t use it as your only control for regulated communications that require recorded human sign-off.

Questions

Does this work for emails not written by AI?

Yes. Templates, mail merges, and manual drafts can all be checked the same way.

How do I check against several rules at once?

Save each rule and pass them with policyIds. It still counts as one check, and results tells you which rule failed.

What about attachments?

Send what matters about them: file names, the fields they contain, or extracted text, within the size limit.

Related

Customer dataCheck messages for customer data before they’re sentRead Support automationPrevent chatbots from promising unauthorized refundsRead n8n workflowsn8n custom guardrails with your own policiesRead

Try this policy on your own data.

Copy the policy above, add your real examples, and see the decision. 200 free checks per month, no credit card.

Start freeBrowse policy templates