Stopping an n8n AI agent from emailing clients without principal approval

Where an n8n AI agent can send email without approval

The most direct path is an email node (Gmail, Outlook or SMTP) attached to the AI agent as a tool. The model then chooses the recipient, the body and any attachments, and the send happens in the same step. Nothing in that design gives a principal a chance to review.

There are less obvious paths. A sub-workflow exposed as a tool may contain a send node. An HTTP request tool may call a mail API directly. A mail credential shared across workflows may let any workflow with an email node send as the same identity. A workflow may also be edited later to add a send step. Content the agent reads, such as an inbound message, can try to steer it toward sending something it was never asked to send.

Prompt instructions that say "never send without approval" do not close these paths. NIST AI 600-1 notes that restricting model outputs may still produce harmful results in response to less-explicit, novel prompts. A prompt is a preference, not a barrier. The barrier has to be a capability the agent does not have.

NIST's request for information on AI agent security lists tool restrictions and approvals for consequential actions as distinct control categories. It is a request for information, not a requirement, but it is a useful direction. Client email is a consequential action, so both categories apply.

Implement a draft-then-approve pattern

The pattern relies on n8n's native building blocks: restricting which tools the agent holds, a wait-for-approval step, and separate workflows. Each step below removes a specific way for a send to occur without review.

• 1. Inventory every send path: List each email node, sub-workflow, HTTP request and shared credential that can reach a mail service. Include workflows the agent can call as tools.
• 2. Remove send from the agent: Detach any email send node from the agent. Give it one tool that writes recipients, subject, body and attachment references to a holding record, such as a database row.
• 3. Put the send in a separate workflow: The send workflow is triggered only by an approval outcome. It is not registered as a tool and not callable by the agent workflow.
• 4. Add the approval step: Pause the execution and present the stored draft to the principal. Show the exact recipients and attachments. Resume only on an explicit approve or reject.
• 5. Send the stored message, not regenerated text: The send step reads the approved content by reference. Record a hash at approval and verify it before sending, so edited or regenerated content cannot go out under an old approval.
• 6. Separate the credentials: Use an agent identity distinct from any human principal. Keep the sending mailbox credential available only to the send workflow, with restricted edit rights on that workflow.

What the approval record must show

An approval step that works is not the same as an approval you can prove. A regulated enterprise needs to show that a specific message was authorized by a specific person and that what left the building matches what was approved. NIST SP 800-177r1 describes non-repudiation as establishing that an individual took an action such as sending an email or approving a request. NIST's agent identity tenets add that an agent's actions should trace back to the person or organizational authority that initiated the task.

Do not assume workflow execution history alone will serve as that record. Write the approval record deliberately, as its own artifact, and keep it for the period your obligations require.

• Requester: the person or process that initiated the agent task
• Approver: the named principal who made the decision
• Message content, recipients and attachments as presented for review
• Timestamp of the request, the decision and the send
• Outcome: approved, rejected or expired
• A reference tying the approval to the message actually sent

What workflow-level controls do not guarantee

Everything above depends on construction. A new workflow built without the pattern has no approval step. A sub-workflow with a send node bypasses the one you hardened. A shared credential lets another workflow send without review. A later edit can quietly reconnect the send node. Each control is sound where it exists, but none shows that it exists everywhere.

The approval record also describes what the workflow was designed to do. It does not demonstrate that no other path sent a message. For that you need a control that sits on the send itself rather than on the workflow around it, along with evidence generated at the moment of each decision.

One scope note. Where client messages are commercial, the CAN-SPAM Act requires opt-out requests to be honored within 10 business days, and the opt-out mechanism must keep working for at least 30 days after sending. As of November 2026, the FTC guidance reports no amendment. Whether a given client message is commercial or a transactional or relationship message is a question for legal review, and approval scope should follow a documented risk assessment.

Enforcing policy on the tool call with Trussed

Trussed enforces policy in the execution path, on individual interactions and tool calls across models, agents, tools and MCP servers. For an email tool call, the policy decision is enforced at runtime, not reviewed after the fact. The decision can be to allow, redact or block the call, or to escalate it for human approval. Because the decision sits on the tool call, it applies however the call was reached, rather than depending on how a given workflow was assembled.

Each enforcement decision generates audit-ready evidence, mapped to frameworks including HIPAA, NAIC, NYDFS, the EU AI Act and NIST. That gives a regulated enterprise a record of what the agent was allowed to do and what it did on that call. Trussed can be self-managed in the customer cloud, with configurable retention and data residency.

The scope is the individual interaction or tool call. It complements the draft-then-approve pattern rather than replacing it: keep the separation of drafting and sending in the workflow, and enforce policy on the send as a second layer.