Some of you argued with me about this in two other threads. Here is the working version, with the files, so you can run it yourself instead of taking my word for it.
The setup is an AI agent that writes and sends customer emails. Normally it just sends. Guardian sits between the agent and the send node: the workflow asks before it acts and gets back ALLOW, DENY or REQUIRE_APPROVAL. Approvals pause on the critical path, before anything leaves. Every decision lands in a hash-chained log.
Video (9 min, unedited): [LOOM LINK]
0:00 The problem
1:09 Building a policy: templates, natural language, or JSON
1:43 Generating test payloads for your own policy
1:59 Rule precedence: deny beats require_approval beats allow
3:03 The agent tool vs the enforcement node, and why the agent
cannot route around the second one
4:31 ALLOW: decided by policy, executed, email arrives
5:45 Original payload vs executable payload. I edit "Test message"
into "$400 refund", give a reason, approve
6:38 Audit log shows the executed payload was the edited one
6:55 What it looks like when the workflow does NOT come back
7:42 DENY
8:59 Why there is a Switch node instead of branching off Guardian's
own outputs
Files:
guardian-demo-workflow_2.json (15.7 KB)
and
guardian-demo-policy.json (509 Bytes)
both attached, paste the policy JSON into the policy builder, in the JSON part…-
Nodes are n8n-nodes-guardian in community nodes. Put your own address in the policy allowlist and it runs.
The part I would steal if I saw it somewhere else. The policy does not try to detect bad content. It allowlists the subjects the agent is allowed to send unsupervised, and anything the agent wrote itself falls through to a human:
json
{
"type": "allowlist",
"fieldPath": "subject",
"allowedValues": ["Order confirmation", "Delivery update"],
"otherwiseDecision": "REQUIRE_APPROVAL"
}
Two lines, and the agent can only act alone inside templates you already approved.
The first hole you will find is that nothing constrains the body. Approved subject, approved recipient, and the agent can write whatever it likes underneath. That is deliberate for the demo. Tell me what rule you would add, because that is the part I keep going back and forth on.
What it does not do yet, so nobody wastes an afternoon finding out:
<No provider receipt on the execution record. Several people in those threads named this independently and they were right. The gate proves the action was permitted. It does not yet prove what the provider did with it.
<No timeout watcher for approved-but-never-confirmed. You can see it in the log at 6:55, but nothing chases it.
<If Guardian is unreachable there is no configurable fallback yet. That is the next build.
Free right now at guardian-safety-gate.com. Free tier runs this whole demo.
Import it, point it at your own policy, and try to get something past it. I would rather hear it here than from a customer.
Good luck!