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
2 Likes
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:
- Does an approval create a durable receipt: who approved, what payload summary, what policy, and what action was released?
- Does a denial create a record that can be reviewed later, or is it just a blocked run?
- Can the audit trail link back to the n8n execution and the downstream action that did or did not happen?
- Can pending approvals age into an alert if nobody acts?
- Is there a clean way to summarize approvals/denials for a client or internal compliance report?
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.
1 Like
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!
1 Like
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.
1 Like
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.
1 Like