Are you building n8n workflows where AI agents make financial decisions, issue refunds, or execute payments?
If you are, you know the biggest risk: the auditor question. Six months from now, when compliance asks “Who approved this transfer and why?”, pointing to an expired chat log or a deleted n8n execution history won’t save you.
You need mathematical proof of what the agent decided before the money moves.
Thanks to standard cryptography, fixing this is incredibly easy.
Enter Signatrust.
You no longer have to build custom audit logging databases or rely on fragile execution histories. In just one HTTP Request node, you can seal the AI’s decision into an immutable ledger directly from your n8n workflow.
How it works (3 nodes):
- Hash the payment payload locally (SHA-256 — your data never leaves your server).
- Send it to the Signatrust API (
POST /api/v1/receipts).
- Receive an Ed25519-signed Decision Receipt — tamper-evident, chain-linked, publicly verifiable.
What you get:
- Cryptographic proof of who decided, what was decided, and when
- An append-only hash chain (altering any past receipt breaks every link after it)
- Public verification — anyone can verify a receipt without accessing your systems at Decision Receipt Explorer — Signatrust
- A Trust Score (0-100) for your agent based on its verifiable history
Your n8n workflow becomes:
Agent decides > Signatrust seals the receipt > Only verified actions move to the payment gateway.
Here is a real receipt I just created and verified:
Receipt ID: STR-FDE9ABA14A
Verify it yourself: go to signatrust.net/verify and paste the ID — no account needed.
There is also a verified n8n Community Node (n8n-nodes-signatrust) you can install directly — no HTTP Request node needed.
Stop letting un-auditable AI break your compliance. Start sealing your n8n decisions today.
Docs and npm package available at signatrust.net/docs
1 Like
Signing the decision is the easy half, and worth doing. But a receipt proves the record wasn’t altered, not that the action was authorized or that the money actually matched it. The auditor’s real question is “who approved this and why,” and a signature just seals whatever you fed it, including a decision nobody approved. The harder part is capturing the human approval at the moment of the decision and reconciling the receipt against what the payment gateway actually executed. Otherwise you’ve got tamper-proof evidence of a possibly-wrong call.
Thanks — that’s an important distinction, and I agree.
Signatrust isn’t intended to replace the approval or policy engine. Its role is to create an immutable, independently verifiable receipt of whatever evidence the workflow captures.
In practice, we recommend including the full governance context in the signed receipt:
- Approver identity (who approved and their role)
- Approval reason (why it was approved)
- Policy outcome (which policy was applied)
- Payload hash (what data was sealed)
- Execution metadata (which gateway executed it)
- Final result (what actually happened)
That way the receipt represents the complete decision context — not just the final output.
Here is a live example I just created. This receipt contains the full governance chain: approver ID, policy reference, human approval timestamp, execution gateway, and final outcome — all cryptographically sealed together:
Receipt ID: STR-0FA98ABBB2 — you can verify it on the Verify page linked in the original post above.
The architecture is fully integrated internally — the metadata object accepts any JSON structure, so the workflow designer controls exactly what evidence gets sealed. If someone later alters the approver_id or flips human_approval from true to false, the Ed25519 signature breaks instantly.
Governance decides whether an action should happen; Signatrust proves exactly what evidence existed when it happened.
Thanks for highlighting this — it is the most important distinction in AI governance right now. Appreciate the thoughtful feedback!
