Why this matters
An n8n AI agent that reads, sorts and drafts saves real time. The risk starts when it sends: a wrong amount or a clumsy line goes straight to a client, and an email cannot be unsent. So many owners still check every draft by hand, which takes back most of the time the agent saved.
Guardian checks each action before the workflow runs it and answers Allowed, Needs approval or Denied. Write the rule once, and team emails go out alone, client emails wait for one click, and deletes never happen.
Practice
Do every step yourself in a practice copy of the real tool. It checks your work, and “Do it for me” finishes any step you get stuck on.
What you’ll build
You help Maya Chen, who runs Harbor Line Bookkeeping, a made-up firm whose n8n agent drafts about 60 invoice reminders a month.
You create a Guardian policy for email.send, allow only the team addresses, send everything else to Require Approval with a reason, test a team email and a client email, save it and test it again, and check that Deny unmatched actions blocks deletes. Then you see where the Guardian node, its three outputs, its credential and the Approval Inbox fit in n8n. The Guardian screens are the real app; the n8n screens are images from Guardian's own guide.
What you need
- Nothing to start the practiceThe lesson uses screenshots of the real Guardian app and Guardian's n8n guide. Harbor Line Bookkeeping and every address are made up.
- A Guardian account, to do it for realFrom guardian-safety-gate.com, read 19 October 2026: free to start, no credit card, free while it is early. Verify your email before you create an API key.
- An n8n workflow that sends somethingAny workflow with a send, delete or payment step. Guardian's n8n guide shows the node setup.
Concepts
One policy per action type
A Guardian policy applies to one action type, such as email.send, written in lowercase dot notation. Your n8n workflow sends the same action type with a payload, and Guardian checks the payload against that policy.
Only allow specific values is the simplest rule for emails: list your team addresses, and anything else gets Require Approval.
Test with the real payload
Test This Policy runs your rules against a payload before you save, and the flask icon tests a saved policy. Both are sandbox tests: nothing is created or logged.
A rule checks a field by name. If the name differs from the payload, even by a typo, the rule never fires. Test one payload that should pass and one that should not.
Deny by default, approve with one click
Under Settings > Organization, Deny unmatched actions blocks any action type without a policy. So a delete with no allow policy is denied.
In n8n, only the Guardian node's Allowed output connects to the send. Waiting requests show in the Approval Inbox, where a person can edit the payload and approve it.
Do it for real
Now repeat it in your own account. Tick each step as you go.
Quick check
3 questions to check you’ve got it.
1. Your agent emails a client. Under this lesson's policy, what does Guardian answer?
- ALLOW
- REQUIRE APPROVAL
- Nothing, it sends the email itself
Show the answer
REQUIRE APPROVAL. The client address is not on the allow list, so the rule falls to Require Approval. Guardian never sends anything itself.
2. Your rule checks "recipent" but the workflow sends "recipient". What happens?
- Guardian fixes the typo
- The rule never fires
- Every email is denied
Show the answer
The rule never fires. A rule matches a field by name, so a typo makes it silently dead. That is why you test with the real payload.
3. Which Guardian node output should connect to Send an Email?
- All three
- Allowed only
- Needs Approval
Show the answer
Allowed only. Only Allowed reaches the send. Denied and Needs Approval end in a note, and an approved email is sent by the separate approval path.
You reached the end of AI Apps Worth Knowing
You made an AI agent ask before it emails a client. Review the apps you have met in this course and pick one to try on your own work.
Pick your next course →