Stepthrough Start free

Guardian for n8n: 8 Approval Gate Mistakes to Avoid

Quick answer

A Guardian approval gate in n8n usually fails in one of three ways: the policy never fires because its field name doesn't match the payload, the workflow sends anyway because more than the Allowed output is wired to the send, or an approved email goes out twice because two workflows listen for the same action type. All eight mistakes below are named in the free Guardian approval gate lesson, where you build the policy in the real Guardian app for a made-up firm, Harbor Line Bookkeeping, whose agent drafts about 60 invoice reminders a month.

Last updated

Take the free module →Module 18 of the free n8n Jump Start course, about 14 minutes. No account needed.

Guardiann8nAI agentsTroubleshooting

The goal of the setup is simple: team emails go out alone, client emails wait for a person, and deletes never run. That is human in the loop placed only where it matters.

What are the most common Guardian mistakes?

#MistakeWhat happensFix
1All three outputs wired to the sendDenied and held emails still go outConnect Allowed only
2Rule field name differs from the payloadThe rule silently never firesTest with the real payload
3No project tickedThe policy won't saveTick Default under Apply to Projects
4An allow policy for deletesDeletes can runRely on Deny unmatched actions
5First test against a live sendA real email goes out mid-testDisable the send or use Listen Mode
6Two workflows listening for one action typeAn approved email is sent twiceOne active listener per action type
7Action type typed differently in n8nThe node's request doesn't match the policyUse the same email.send in both
8API key pasted into a chat or shared workflowAnyone can act as your workflowKeep it in the Guardian API credential

Why does the email still send when it needs approval?

1. Wiring every output to the send. The Guardian node has three outputs: Allowed, Denied and Needs Approval. Only Allowed connects to Send an Email. Denied and Needs Approval should each end in a note or a response. If all three feed the send, Guardian's answer makes no difference.

An n8n workflow where the Guardian node's Allowed output goes to Send an Email, and Denied and Needs Approval each end in a response
Only Allowed reaches the send (image from Guardian's n8n guide)

An approved email doesn't come back through that first node. It is sent by a separate approval path: a Guardian Approval Trigger, then a Guardian node set to Enforce, then the send, reading the approved payload.

Why does my Guardian rule never fire?

2. A field name typo. A rule checks a field by name. If the rule checks recipent and the workflow sends recipient, the rule is silently dead. The lesson's knowledge check asks exactly this. The fix is testing: Test This Policy before you save, and the flask icon on the saved policy afterwards. Run one payload that should pass (a team address returns ALLOW) and one that should not (a client address returns REQUIRE APPROVAL). Both are sandbox tests, so nothing is created or logged.

Guardian test result: Guardian would return REQUIRE APPROVAL for an invoice reminder to a client, with the reason Emails to customers wait for a person to approve
A client address falls to Require Approval

7. A different action type in n8n. The policy applies to one action type in lowercase dot notation, email.send. The Guardian node's Action Type must be the same string, and its payload must use the same field names as the rule: recipient, subject and body.

Why won't my policy save?

3. No project. Under Apply to Projects, tick Default. Guardian won't save a policy without a project. While you're on that form: the Manual option builds rules from scratch, and the AI Wizard isn't available yet, so use Manual and build the rules by hand.

Try it free, step by step

Guardian: Make Your n8n AI Agent Ask Before It Emails a Customer. A business case for a small firm whose n8n agent drafts client emails: turn "team emails go out alone, client emails wait for a person, deletes never happen" into a Guardian policy, test it, and see… You do every step yourself in a practice copy of Guardian, it checks your work as you go, and “Do it for me” finishes any step you get stuck on. Free, and nothing touches your real accounts.

Start the free lesson

Or read the full step-by-step guide

How do I stop an agent from deleting records?

4. Writing an allow policy for deletes. You don't need a "never delete" rule at all. Under Settings > Organization, Default Policy Behavior has Deny unmatched actions selected and marked Recommended: any action type without an explicit policy is blocked. If the agent ever asks for record.delete, Guardian answers Denied. The only way to break that is to write an allow policy for it, so don't. (Allow unmatched actions is the wrong default for this job anyway.) This is how a policy engine limits agent permissions: the safe answer is the default one.

How do I test without sending a real email?

5. Testing against a live send step. For the first real run, disable the send node (select it and press D), or turn on Listen Mode under the Organization tab. Listen Mode records every request and what Guardian would have decided, without blocking anything. Read those decisions, then switch it off.

Why did an approved email go out twice?

6. Two listeners. If two active workflows listen for the same action type, both can act on one approval. Keep exactly one active workflow listening for email.send. If you copy a workflow to experiment, deactivate the copy.

Where should the Guardian API key go?

8. Anywhere but the credential. Create the key under Settings > API Keys (Guardian asks you to verify your email first) and add it, with the signing secret and the base URL, to the Guardian API credential in n8n. Don't paste it into a chat, a screenshot or a shared workflow.

What does a working setup look like?

A client reminder arrives in the Approval Inbox marked "Blocked, awaiting human approval" with the reason and an expiry time. Edit Payload & Approve shows the original payload next to the one that will run, so you can fix a wrong amount first. The original stays in the audit trail, and the edited version is checked against the policy again. For all settings on one page, use the Guardian cheat sheet; for the tool listing, see Guardian in the AI tools directory.

Key takeaways

  • Wire only Allowed to the send; approvals use their own trigger path.
  • Test every policy with the real payload, before and after saving.
  • Leave Deny unmatched actions on and never allow deletes.
  • Use Listen Mode or a disabled send for the first run.
  • One active listener per action type, and the key stays in the credential.

Frequently asked questions

Does Guardian send the email for me?

No. Guardian only answers Allowed, Needs approval or Denied and records the decision. n8n does the sending.

What does Guardian return for an email to my own team?

With the lesson's rule, ALLOW, because the address is on the list. Everything else gets REQUIRE APPROVAL.

Can I change a draft before approving it?

Yes, with Edit Payload & Approve. The edited version is checked against the policy again.

How many approvals does one email need?

The lesson leaves Approvals Required at 1.

Where can I read more answers?

See the Guardian for n8n FAQ and Guardian use cases by role.

Free lessons in this post

Plain-English definitions, each with an example from a free lesson.

The full AI glossary

Keep reading

All blog posts · All free tutorials