If you’re running AI steps in n8n and need an audit trail, PII masking,
or human approval before sensitive actions execute, this might be useful.
Install: Settings → Community Nodes → n8n-nodes-trustloop
Supports: Intercept, Logs, Stats, Pending approvals, Approve/Deny, Block.
Feedback welcome.
Thanks
TrustLoop.live
This is useful territory. For AI workflows, approval and PII masking solve the immediate governance problem, but the next thing teams usually need is the operating record around the decision.
A few questions I would ask while testing it:
The node-level governance is the right starting point. The value compounds when every approval, denial, and blocked action becomes something the operator can explain after the fact.
Hi Rory,
Approval receipt — yes. Each approval stores who approved it, the decision, the rule that triggered it, and the full argument payload. It sits in the audit trail alongside every other action so you can pull it up by tenant, date, or rule.
Denial records — yes. Denials write to the same audit log as allowed actions, with status DENIED. The record includes what was attempted, which rule matched, and the timestamp.
Linking back to the n8n execution — partial. The tool call is logged with the tool name and arguments, but TrustLoop doesn’t currently capture the n8n execution ID natively. You’d have to correlate by timestamp for now. That’s a real gap and worth flagging.
Approval aging — covered. Pending approvals auto-expire after 24 hours, send an alert, and write a denial record automatically. Nobody has to remember to chase it.
Compliance summary — basic. The dashboard gives a breakdown of approvals and denials with CSV export. A formatted report for clients or auditors isn’t there yet — it’s on the roadmap but not built.
Your last point is the right frame for this. Every decision being explainable after the fact is exactly what the blockchain anchoring is for — each record gets a tamper-proof hash so the trail can be verified independently. The log isn’t just a log, it’s evidence.
If you test it and hit the edges, I’d like to know — it helps decide what gets built next.
Thanks!
The audit trail + PII masking combination is what’s missing from most production AI workflows. On the n8n execution ID gap - a quick workaround until it’s natively captured: inject $execution.id as a metadata field in the tool call payload before TrustLoop intercepts it. If the node accepts custom fields alongside the tool arguments, you could store n8n_execution_id directly in the audit log without changing the agent behavior. Would remove the need to correlate by timestamp.
Good shout, didn’t think about injecting $execution.id as a metadata field but that’s actually clean. No behaviour change, lands straight in the audit log, removes the timestamp correlation headache entirely. Will test it and if it holds up we will document it properly so others don’t have to figure it out the hard way. Native capture is on the roadmap but this gets you there today.
Quick update on the execution ID workaround nguyenthieutoan suggested.
Tested it — it works cleanly. Before your TrustLoop intercept node, add a Set node that pulls {{ $execution.id }} and passes it in the arguments object. TrustLoop logs it alongside the tool call, so every audit entry is directly linkable back to the n8n execution that triggered it.
We’ll add this to the setup docs so it’s part of the standard integration guide going forward. Thanks for the suggestion — good shout.
Also for anyone who landed here recently: we published our DPA at trustloop.live/dpa for teams with compliance requirements, and the node is on v1.0.0 at npmjs.com/package/n8n-nodes-trustloop.
Update: execution ID is now built in — v1.0.1
Thanks for flagging this, @Rory_Hayes, and to @nguyenthieutoan for the Set node workaround.
I’ve now baked it in properly. From v1.0.1, every Intercept call automatically captures n8n’s execution ID and sends it to TrustLoop — no Set node needed.
The audit log entry will now include an n8n_execution_id field, so you can go straight from a flagged or blocked tool call in the TrustLoop dashboard back to the exact n8n run that triggered it.
To update:
# In n8n → Settings → Community Nodes → update n8n-nodes-trustloop
Or reinstall — it should pull 1.0.1 automatically.
If anyone’s hitting other gaps, let me know here.
Native capture is the cleaner path - no Set node needed is a real improvement. One thing worth noting in the docs for teams running n8n in queue mode: the execution ID is unique per run across all workers, so the n8n_execution_id linkage holds without any extra config in distributed setups. Good move shipping this in 1.0.1.
Thanks for flagging. that’s a useful detail we should add to the docs so teams in distributed setups know it works out of the box with no extra config. Appreciate you taking the time to test it and share.
Useful direction, and the audit-receipt questions above are the right ones. I want to raise a structural one that I think matters more than any feature on the list, because it decides whether the guarantee holds at all.
An in-workflow approval node governs the path that runs through it. It cannot govern an agent’s tool calls.
If the sensitive action is a normal node downstream of your Intercept/Approve gate, you’re fine. But the moment the sensitive action is a tool bound to an AI Agent node, the agent invokes it inside its own loop — the tool call never traverses the canvas, so a gate sitting downstream of the agent node never sees it and never fires. The refund already happened; your node approves the summary afterwards. That isn’t a bug, it’s the topology: the workflow graph and the agent’s tool-call graph are two different graphs, and only one of them has your node in it.
So for the agentic case, the governance has to live in the tool, not in the canvas. The tool wrapper calls TrustLoop, blocks, and only then performs the side effect. Same for the kill switch — “Block” only blocks what passes through the node.
Two consequences worth designing for:
Hold the credential, not just the flow. Governance that a workflow author can bypass by simply not adding your node is a convention, not a control. The version of this that’s actually enforceable is the one where the credential for the dangerous action lives behind your wrapper, so the unapproved path can’t authenticate at all. That’s a much stronger sell to the person who has to sign off on this, and it’s the difference between “we have an approval step” and “unapproved actions are impossible.”
Approve the payload, not a description of it. If the human sees an LLM-generated summary of the pending action, then the thing being approved and the thing being executed are two different artifacts — and when the input is attacker-controlled (a support ticket, an inbound email), the summary is exactly where you’d attack. “Refund $5” on the approval card, amount: 500000 in the payload. The receipt should show the exact serialized call that will be executed, hashed, and the executor should refuse anything whose hash doesn’t match what was approved. That single property is what makes the audit trail evidence rather than decoration.
None of this is a criticism of building it — approval and masking are the right primitives, and Rory’s point about durable receipts is the right next one. It’s just that in the agentic case the interesting boundary moved, and the node-in-the-canvas placement is one topology behind where the risk now lives.
This is exactly the right critique and the kind of structural thinking that separates “we have an approval step” from actual enforcement.
You’re correct on the topology — the intercept has to live in the tool, not the canvas, which is what TrustLoop does. The agent calls us before the side effect, not after.
On credential holding: forward_to moves in this direction — TrustLoop makes the real downstream call so the agent never holds the credential directly — but you’re right that full enforcement means the key lives with us, not the agent. That’s on the roadmap.
The payload hash point is the one I want to act on immediately. You’re right that approving a description of a call and approving the call itself are two different things. We’re going to hash the exact serialized arguments at interception time, tie the approval to that hash, and refuse execution if the payload drifts. That closes the $5/$500,000 case cleanly. Will ship it.
Appreciate you laying this out properly — this is the level of rigour the agentic case actually needs.
Very interesting use case.
Governance, approvals and audit trails feel like one of the missing pieces for AI-heavy workflows as they move closer to production environments.
The ability to intercept actions, introduce human approval points and maintain execution visibility becomes increasingly important once workflows start interacting with customer data, external APIs or operational systems.
Curious to see how you approached approvals across more complex workflow topologies and whether you’re persisting that state inside n8n or externally.
Thanks for sharing.
Thanks Kostas — you have put your finger on exactly the right question.
State lives entirely outside n8n in TrustLoop’s database, not inside the workflow. When the n8n node calls /api/intercept and gets a PENDING response, it receives an approval ID and a payload hash. The approval record sits in TrustLoop’s Postgres, tied to the exact arguments that were submitted. n8n handles the orchestration, TrustLoop handles the governance state — they stay cleanly separated.
The honest answer on complex topologies: the current gap is that when a workflow gets a PENDING response, the retry logic has to be built manually by the developer — a separate polling workflow or a wait node wired up themselves. That is more friction than it should be. We are working on a proper webhook-based resume so TrustLoop calls back into n8n when an approval is decided, and the workflow picks up exactly where it left off.
The payload hash piece does handle branching correctly today — each tool call gets its own approval record tied to its specific arguments, so parallel branches and loops each govern independently.
Happy to go deeper on any of this.