n8n Guardian Gates：審批流程如何避免智能體寄出錯誤發票

An agent that drafts 60 client emails a month will eventually send one with the wrong amount. You cannot unsend an email to a customer. The standard workaround is to check every draft by hand, which turns a 10-minute automation into a 3-hour review session.

The better pattern is a policy gate that separates draft generation from irreversible send actions. Let the agent read data, sort records, and compose text. Block anything that touches a customer or deletes a record until a human approves it. This article shows how to wire that boundary into n8n using Guardian, a third-party approval service, and explains the plumbing: policy rules, payload structure, timeout handling, and failure modes.

The Three-Line Policy Most Offices Already Agree On

When you ask small-office owners where the risk line sits, they usually say:

• Internal team emails can go out automatically.
• Client emails wait for a person to approve.
• Deletes are never allowed.

Guardian turns those three lines into enforceable policy. It sits in front of the step that cannot be undone and returns one of three answers: Allowed, Needs approval, or Denied. Your n8n workflow still does the sending. Guardian just decides whether the workflow reaches the send node.

Wiring the Approval Gate into n8n

The approval gate is a node that sits between draft generation and the send action. Here is the flow:

1. Trigger: Schedule or webhook fires the workflow.
2. Agent drafts: LLM node reads overdue invoices, generates reminder text.
3. Guardian policy check: HTTP request to Guardian API with payload (client name, amount, draft text).
4. Branch on response: If Allowed, continue to send. If Needs approval, pause and send approval link. If Denied, log and stop.
5. Send action: Only reachable if Guardian returned Allowed or approval was granted.

The key is that the workflow does not block. If Guardian says Needs approval, the workflow pauses that branch and exits. A separate webhook receives the approval callback when the human clicks yes or no.

Policy Layer

Guardian policies are JSON rules that match on payload fields. For client emails, the policy might look like this:

{
  "name": "client-email-approval",
  "rules": [
    {
      "condition": "payload.recipient_type == 'client'",
      "action": "needs_approval"
    },
    {
      "condition": "payload.recipient_type == 'internal'",
      "action": "allowed"
    },
    {
      "condition": "payload.action == 'delete'",
      "action": "denied"
    }
  ]
}

The policy runs server-side. Your n8n workflow sends a payload, Guardian evaluates the rules, and returns a decision. You do not write conditional logic in n8n for every risk scenario. You write it once in the policy and let Guardian enforce it.

Payload Structure

The payload you send to Guardian must include everything a human needs to make a decision without re-querying the agent. For an invoice reminder, that means:

• client_name: Who is receiving this email.
• invoice_amount: The dollar figure in the draft.
• draft_text: The full email body.
• recipient_type: client or internal.
• action: send, delete, or update.

If the payload is missing context, the human reviewer will have to open the CRM or accounting system to verify the amount. That defeats the purpose. The approval UI should show all the information inline.

Timeout and Expiration

If an approval request sits unanswered for 24 hours, what happens? Guardian supports expiration policies. You can configure:

• Auto-deny after timeout: The approval link expires and the workflow logs a timeout event.
• Auto-approve after timeout: Risky, but useful for low-stakes actions.
• Escalation: Send a second approval request to a manager if the first reviewer does not respond.

In n8n, you handle expiration by listening for a timeout webhook from Guardian. If the timeout fires, you log the event and optionally retry the approval request with a different reviewer.

Failure Modes

What happens if the agent generates a draft, gets approval, but the send action fails? The approval token should be single-use. If the send fails, the workflow should log the error and not retry without a new approval. Otherwise, you risk sending the same email twice if the failure was transient (network timeout, rate limit).

Guardian tracks approval tokens and marks them as consumed after the first use. If your workflow retries the send step, Guardian will reject the token and force a new approval request. This prevents accidental double-sends.

Orchestration Flow

Here is the full n8n workflow shape:

1. Schedule Trigger: Runs every morning at 9 AM.
2. Google Sheets Node: Reads overdue invoices.
3. Filter Node: Keeps only invoices overdue by more than 7 days.
4. OpenAI Node: Generates reminder email for each invoice.
5. HTTP Request to Guardian: Sends payload with client name, amount, draft text.
6. Switch Node: Branches on Guardian response (allowed, needs_approval, denied).
7. If Allowed: Continue to Gmail send node.
8. If Needs Approval: Send approval link via Slack or email, exit workflow.
9. Approval Webhook: Separate workflow triggered by Guardian callback when human clicks yes or no.
10. If Approved: Resume workflow and send email.
11. If Denied: Log reason and stop.

The approval webhook is a separate n8n workflow because the original workflow has already exited. When the human approves, Guardian calls your webhook with the approval token and original payload. Your webhook workflow validates the token, retrieves the draft, and sends the email.

State Management

The tricky part is state. When the approval workflow exits, where does the draft live? You have three options:

For most use cases, storing the draft in the Guardian payload works. If your drafts are longer than 10 KB, store them in S3 or a database and pass a reference ID in the payload.

Observability

You need to know when approvals are pending, expired, or denied. Guardian provides a dashboard, but you should also log events in your own system. In n8n, add a logging node after every Guardian decision:

• Allowed: Log client name, amount, timestamp.
• Needs approval: Log client name, amount, approval link, expiration time.
• Denied: Log client name, amount, reason.
• Approved: Log client name, amount, approver, timestamp.
• Timeout: Log client name, amount, expiration time.

Send these logs to a monitoring tool (Datadog, Grafana, or even a Google Sheet). You want to answer questions like: How many approvals are pending right now? Which client emails are stuck waiting for review? How often do approvals time out?

Security Boundaries

The approval link is a bearer token. Anyone with the link can approve or deny the action. Guardian mitigates this by:

• Expiring tokens: Links expire after 24 hours by default.
• Single-use tokens: Once approved or denied, the token is invalid.
• IP allowlisting: Optionally restrict approval requests to specific IP ranges.

If you send approval links via Slack, make sure your Slack workspace requires 2FA. If you send them via email, use a secure email provider and avoid forwarding the link.

Deployment Shape

Guardian is a hosted service. You do not run it yourself. Your n8n instance makes HTTP requests to Guardian's API. This means:

• No infrastructure: You do not deploy or maintain Guardian.
• Latency: Every approval check adds a network round trip (usually 50-200 ms).
• Dependency: If Guardian is down, your workflow cannot check policies.

For high-throughput workflows, cache Guardian responses for identical payloads. For example, if 10 internal emails go out in the same run, you can check the policy once and reuse the Allowed response for all 10.

When to Use This Pattern

Use approval gates when:

• The action is irreversible (send email, delete record, charge credit card).
• The cost of a mistake is high (wrong invoice amount, wrong recipient).
• The volume is low enough that human review is feasible (dozens per day, not thousands).

Do not use approval gates when:

• The action is reversible (update a draft, log an event).
• The cost of a mistake is low (internal notification, test email).
• The volume is too high for human review (thousands of emails per day).

For high-volume workflows, use anomaly detection instead. Let the agent send everything, but flag outliers (amount 10x higher than usual, recipient not in CRM) for post-send review.

Technical Verdict

Approval gates are the right pattern for financial agents that touch client data. They separate draft generation from send actions, enforce policy without conditional logic in every workflow, and provide a clear audit trail. Guardian makes this pattern easy to implement in n8n, but you could build the same thing with a custom webhook and a database table for pending approvals.

Use this pattern when the volume is low enough for human review and the cost of a mistake is high. Skip it when the action is reversible or the volume is too high. For high-volume workflows, invest in anomaly detection and post-send review instead.

Source Links

• Original article on dev.to