Governing n8n AI agents: sovereignty and audit evidence
Self-hosting n8n keeps the automation engine in your jurisdiction. It says nothing about the jurisdiction of the services it calls — and that is exactly where the transfer happens.
n8n is often chosen for one precise reason: keeping automation in-house. A server in your own country, data that does not pass through a third-party service, full control over the code. That is a serious sovereignty posture, with real benefits.
But it also creates a blind spot. Hosting the engine in your jurisdiction says nothing about the jurisdiction of the services it calls. A self-hosted n8n workflow in Europe that enriches a customer record through a US API, then writes to a tool hosted somewhere else again, performs exactly the transfers self-hosting was meant to avoid — simply one link further down the chain.
The integration scenario
n8n is the simplest ground in this wiki: an HTTP request node before the sensitive node, and a conditional node routing on the decision. And because n8n runs your code, you can make the behaviour strict — failing closed on irreversible actions — without depending on anyone.
- 1
Generate your organization's profile
The free assessment (start here) establishes your jurisdictions, sector and data categories. That profile makes every decision specific to your deployment.
- 2
Map the nodes that reach out
In each workflow, list the nodes sending personal data to an external service, and note where that service hosts. It is a few hours of work that holds for all your workflows.
- 3
Insert the decision node
An HTTP node to the decision endpoint, carrying the next node's metadata. Then a conditional node routing on the answer.
curl -X POST https://structureclerk.ca/api/v1/authority/decide \ -H 'Authorization: Bearer $API_KEY' \ -H 'Content-Type: application/json' \ -d '{"agent":{"id":"n8n-enrichment-agent","autonomy_level":3},"action":{"type":"share.customer_record","data_categories":["personal"],"destination_jurisdiction":"US_FED"},"context":{"jurisdictions":["FR"],"sector":"health"}}' - 4
Choose your failure posture
You run the workflow, so you decide: fail closed (do not call the external service if the decision is unavailable) for sensitive data, fail open for the rest. That is a self-hosting advantage — the policy really is yours.
The decision contract
POST https://structureclerk.ca/api/v1/authority/decide
{
"agent": { "id": "n8n-enrichment-agent", "autonomy_level": 3 },
"action": {
"type": "share.customer_record",
"data_categories": ["personal"],
"destination_jurisdiction": "US_FED"
},
"context": { "jurisdictions": ["FR"], "sector": "health" }
}
// →
{
"decision": "DENY",
"reason": "sensitive_data_regulated_sector",
"confidence": 0.96,
"evidence_id": "ev_0d18…bb45"
}The decision is advisory — StructureClerk decides, your infrastructure enforces. In a self-hosted deployment that separation is an asset: the authority engine never sees your data, and your workflow never depends on its availability.
| Decision | Effect in the workflow |
|---|---|
| ALLOW | The next node runs, evidence is recorded |
| APPROVE | Branch to a human validation wait |
| DENY | The workflow stops, the reason is logged |
| ESCALATE | The owner is notified, the flow waits |
Sovereignty, proven rather than claimed
Self-hosting is an argument many teams make to their customers. Signed evidence makes it demonstrable: every authority decision leaves an Ed25519-chained trace, verifiable on our verification page without an account, showing which data was authorized to leave, toward which jurisdiction, and on what basis.
That is the difference between we host in Europe — a claim — and a chain of decisions a customer checks themselves. The second survives a vendor questionnaire; the first answers it poorly.
+Isn't self-hosting enough for compliance?
It settles where the engine runs, not where the calls go. A self-hosted workflow calling a third-party API hosted abroad performs a transfer — self-hosting merely moved it one link along. The authority decision assesses each call's real destination.
+Do we need to expose our n8n instance to the internet?
No. Your instance calls our endpoint outbound, not the reverse: no inbound port to open, no incoming webhook to expose. The authority layer never connects to your infrastructure.
+Can we fail the workflow when the decision is unavailable?
Yes, and it is recommended for irreversible actions or sensitive data. You run the workflow: the unavailable-decision behaviour is one more conditional node, entirely under your control.
+What data leaves our infrastructure?
Only the action's metadata: type, data categories, jurisdictions, sector, autonomy level. No personal data, no content — that is a design choice, not a configuration option.
Start with the profile
The assessment is what personalizes the decisions your agents receive. It is free, and only needs your website address.