AI Reading Email and Triggering Workflows: How to Prevent Wrong Actions

Keep raw email, HTML, links, and attachments in an untrusted processing zone. Normalize MIME, scan for malware, enforce size limits, remove active content, and send only necessary data to AI. The prompt must state that email content is evidence to analyze, even when it claims to contain administrative instructions.

Require AI output to match a closed JSON Schema with allowed fields, data types, enums, length limits, and missing or ambiguous flags. Reject unknown fields. Never let the model invent tool names, endpoints, SQL, or privileged parameters. Store raw input and structured output separately for investigations, with PII and secrets masked under retention policy.

Read Authentication-Results created by a trusted mail system and evaluate SPF, DKIM, DMARC, and domain alignment. Do not trust self-declared headers. Map the sender to an internal directory, tenant, role, and permitted scope. A real account can still be compromised, so anomalies and sensitive requests must be blocked or escalated.

Reading, tagging, and drafting can be automated when data is complete. Reversible internal updates may run within strict limits. External communication, customer-data changes, bookings, expense approval, permission changes, and irreversible operations need stronger controls.

Create an action registry for every tool: owner, risk tier, required data, value limits, requester role, approver role, rollback capability, TTL, and fail-closed policy. Never select tools dynamically from an action name generated by the model.

Layer one, AI extraction, returns structured data and missing or ambiguous flags. Layer two, the policy engine, runs deterministic schema, identity, tenant, limit, object-state, and business-rule checks. Layer three, the execution gateway, accepts only a signed command or valid approval token.

The approval view should show the verified sender, relevant source evidence, before-and-after changes, target system, expected effect, and escalation reason. Bind the approval token to the payload hash, action, resource, approver, expiry, and one-time use. Any payload change invalidates the approval.

Use maker-checker controls for finance, permissions, deletion, and broad-scope actions. The approver needs authority independent from the requester. If the approval channel fails, identity is uncertain, or policy is unavailable, move the work to manual review instead of allowing it.

Build a stable idempotency key from tenant, message identity, action, and resource. Persist IN_PROGRESS, SUCCEEDED, or FAILED with a unique constraint. Workers must handle concurrency, return the prior successful result for duplicates, and never repeat a completed side effect. Forward the same key when the target API supports idempotency.

Track false-action rate, duplicate-block rate, human-review rate, approval-rejection rate, policy-deny rate, missing-field rate, time to decision, and fail-open events. Fail-open must remain zero for sensitive actions. Test spoofed senders, attachment prompt injection, missing payloads, replay, concurrent delivery, policy timeout, and expired approval.

Choose one mailbox, one email type, one low-risk action, and one owner. Run in shadow mode to compare recommendations with real decisions, then enable draft-only behavior, followed by execution under a small limit. Expand authority only after replay, approval, rollback, tenant-isolation, and audit tests meet defined gates.