n8n Credential Vaulting and Secret Handling Design Prompt

You are a senior ops engineer who has found an API token printed in plaintext in an n8n execution log.

I will provide:
- The n8n deployment (self-hosted, queue mode, version) and how it stores credentials today
- The external systems the workflows authenticate to and the privilege each token holds
- The secret manager available (Vault, AWS/GCP secret manager, etc.) and its access model
- Who can view executions and edit workflows

Your job:

1. **Credential sourcing** — design how workflows pull secrets from [SECRET_MANAGER] at run time (external secrets / expressions) rather than hardcoding them in nodes or env, and how rotation propagates.
2. **Least privilege** — scope each credential to the minimum the workflow needs, separating read-only from write tokens so a misfired node can't do more than its job.
3. **Log and error redaction** — ensure secrets never land in execution data, node output, or error messages; identify which nodes leak (HTTP Request, code nodes) and how to mask them.
4. **Access control** — restrict who can open executions and edit credential-bearing workflows, since editing a workflow can exfiltrate the credentials it uses.
5. **Storage hardening** — set the n8n encryption key from the secret manager (not a default), and define backup/restore that doesn't expose the key.
6. **Audit** — log credential use and changes so a leaked or misused token can be traced and rotated.

Output as: a credential-flow diagram, a per-workflow token/scope table, a redaction checklist by node type, and a rotation procedure.

Test redaction by deliberately erroring a node that holds a secret and confirming the secret is masked in the execution log before going live; in n8n the execution log is the most common leak, because anyone with view access sees node I/O.

Why this prompt works

n8n’s low-code model is its appeal and its hazard: workflows are easy to build, easy to share, and easy to fill with real production credentials that someone pastes directly into a node. The prompt attacks the most frequent leak first — the execution log. In n8n, every node’s input and output is captured and visible to anyone with view access to executions, and view access is almost always broader than edit access. A token that flows through an HTTP Request node, or gets printed in a code node, lands in that log in plaintext. By making redaction-by-node-type a first-class deliverable, the prompt turns a vague “be careful with secrets” into a concrete checklist of which nodes leak and how to mask them.

The prompt also separates two access boundaries that teams conflate. Storing credentials encrypted protects them at rest, but anyone who can edit a credential-bearing workflow can simply add a node that posts the secret somewhere they control. Edit access is therefore equivalent to credential access, and the prompt forces that to be acknowledged and restricted. Sourcing secrets from an external manager at run time, rather than pasting them into node fields, means the workflow definition itself carries no secret and rotation happens in one place instead of across dozens of node parameters.

Least-privilege scoping closes the blast radius. A workflow that only reads should hold a read-only token, so a misfired or compromised node can’t escalate into a write. The model can produce the credential-flow diagram, scope table, and redaction checklist quickly, but you verify the one case that actually bites: deliberately error a node that holds a secret and confirm the secret is masked in the resulting execution log. That error-path test is the difference between a design that looks secure and one that survives the first failed run.