n8n-credentials-and-security-official — Claude Code skill: n8n secrets
A skill that keeps API keys and tokens in n8n's credential system instead of plain text inside workflow nodes.
npx skills add n8n-io/skills --skill n8n-credentials-and-security-official -a claude-codeWhat n8n-credentials-and-security-official does
The skill kicks in whenever auth shows up: API keys, bearer tokens, OAuth, basic auth, Authorization headers. From there the agent follows one hard rule — secrets live in n8n's credential system, through newCredential() or a node's credentials parameter. A Set node with a hardcoded token read via {{$json.token}} is the same string in the workflow JSON with an extra step.
The order matters. Call list_credentials({type}) first, then bind by ID: a two-arg newCredential('Label', 'credId') at create time, or the setNodeCredential op on update_workflow. If several credentials match, ask the user which one. The one-arg newCredential('Label') is only a placeholder, and n8n will silently assign the most recently edited credential of that type. Creating credentials stays with the user — the n8n MCP doesn't expose it, so the agent names the exact credential type for the UI rather than accepting a secret in chat.
Inside you get a decision tree for picking an auth method, the credential model, and an anti-pattern table, plus four reference files: references/CREDENTIAL_SYSTEM.md, references/CUSTOM_CREDENTIALS.md, references/HTTP_REQUEST_WITH_AUTH.md and references/FINDING_API_DOCS.md. If a user pastes a token into the chat anyway, the skill says to treat it as compromised and rotate it once the new credential is set up. That's not paranoia: the value reaches the model provider and lingers in chat history.
What it helps with
- wire an API key into an n8n workflow without leaving it as text in the JSON
- choose between a native node and HTTP Request for a service that needs auth
- bind a node to the right credential when several of the same type exist
- set up auth that needs multiple static headers or a header plus query params
- tell the user which credential type to create in the UI
Example prompts for the agent
- Set up a call to the Acme API with a bearer token through a credential, don't put the token in the node
- Check this workflow: is any secret sitting in a Set node or in $vars?
- The service needs two static headers — which credential type should I use?
How to install n8n-credentials-and-security-official
1Skills CLI (Vercel)
npx skills add n8n-io/skills --skill n8n-credentials-and-security-official -a claude-code2Manually: put the files in place
~/.claude/skills/n8n-credentials-and-security-official/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/n8n-credentials-and-security-official/
1Skills CLI (Vercel)
npx skills add n8n-io/skills --skill n8n-credentials-and-security-official -a codex2Manually: put the files in place
.agents/skills/n8n-credentials-and-security-official/SKILL.mdFor all projects use ~/.agents/skills/
1Skills CLI (Vercel)
npx skills add n8n-io/skills --skill n8n-credentials-and-security-official -a cursor2Manually: put the files in place
.cursor/skills/n8n-credentials-and-security-official/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
1GitHub CLI
gh skill install n8n-io/skills n8n-credentials-and-security-official2Manually: put the files in place
.github/skills/n8n-credentials-and-security-official/SKILL.md1Skills CLI (Vercel)
npx skills add n8n-io/skills --skill n8n-credentials-and-security-official -a gemini-cli2Platform CLI
gemini skills install https://github.com/n8n-io/skills --path skills/n8n-credentials-and-security-officialManually: put the files in place
.devin/skills/n8n-credentials-and-security-official/SKILL.mdThe legacy .windsurf/skills/ path still works
Skills CLI (Vercel)
npx skills add n8n-io/skills --skill n8n-credentials-and-security-official -a opencodeClaude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
Step by step, with commands for each platform: How to install skills in Claude Code: five ways
Questions about n8n-credentials-and-security-official
How do I install n8n-credentials-and-security-official in Claude?
Run npx skills add n8n-io/skills --skill n8n-credentials-and-security-official -a claude-code. The skill lands in ~/.claude/skills/n8n-credentials-and-security-official/SKILL.md.
What does n8n-credentials-and-security-official do?
It gives the agent rules for handling secrets in n8n workflows: keys and tokens go through the credential system, binding happens by ID after list_credentials({type}), and credential creation stays with the user in the UI.
What happens if a user pastes a token into the chat?
The skill says not to move it into a text field even temporarily, to bind an existing credential or ask for a new one, and to treat the pasted token as leaked and rotate it after setup.
Source text
SKILL.md · Apache-2.0
---
name: n8n-credentials-and-security-official
description: Use when handling any auth, API keys, tokens, OAuth, bearer tokens, basic auth, or secret values in n8n workflows. Triggers on "API key", "token", "bearer", "OAuth", "secret", "auth", "credentials", "Authorization header", "x-api-key", or any node configuration that mentions a third-party service.
---
# n8n Credentials and Security
## Non-negotiables
1. **Secrets via the credential system, never in text fields or SDK code.** API keys, bearer tokens, OAuth secrets, passwords: all go through `newCredential()` or the node's `credentials` parameter. A Set node hardcoding a token and read via `{{$json.token}}` is a text field with extra steps.
2. **List credentials, then bind by ID.** Call `list_credentials({type})` before configuring an auth-needing node. One match: bind via 2-arg `newCredential('Label', 'credId')` at create time, or `setNodeCredential` op on `update_workflow`. Multiple matches: ask the user which. The one-arg `newCredential('Label')` is a placeholder; n8n auto-assigns the most recently edited credential of that type and silently picks wrong when the user has multiples.
3. **Credential creation is the user's job, not yours.** The n8n MCP doesn't expose credential creation. Tell the user the exact credential *type* to create in the UI, then reference it by label in your node config. Don't attempt to create credentials programmatically and don't accept secrets in chat to "set up later".
## Strong defaults
- **Use native credentials when available.** Every native node (Slack, Gmail, Postgres, OpenAI, etc.) has a credential type. Don't reach for generic credential types when a native option exists.
- **For multi-header or header-plus-query auth shapes**, use the `httpCustomAuth` credential type. See `references/CUSTOM_CREDENTIALS.md`.
## The credential system
In n8n, credentials are first-class objects:
- Stored encrypted at rest in the n8n database.
- Referenced by ID from nodes that need them.
- Scoped to projects (Cloud & enterprise) or shared globally (some self-hosted setups).
- Identified by a type slug (googleSheetsOAuth2Api, slackApi, httpHeaderAuth). The slug is what nodes reference and what determines which auth fields the credential collects.
A node that needs auth has a `credentials` parameter pointing to a credential ID + type. Secret values never appear in workflow JSON. Exporting a workflow leaks the *reference*, not the secret.
For the full model (SDK resolution, rotation, project scoping), see `references/CREDENTIAL_SYSTEM.md`.
## Decision tree: how to authenticate this thing
```
Need to call an external service?
├── Native credential exists (Slack, Gmail, OpenAI, Postgres, ...)?
│ └── Use the native node + its credential type. Done.
│
├── Service is "standard-shaped" (REST + Bearer/Basic/OAuth)?
│ ├── Configure HTTP Request with one of the built-in auth types:
│ │ - Generic OAuth2
│ │ - Header Auth
| | - Bearer Auth (same as header auth but with only field being for actual token)
│ │ - Basic Auth
│ │ - Custom Auth
│ └── See references/HTTP_REQUEST_WITH_AUTH.md
│
└── Service needs multiple static headers, or headers plus query params?
└── Use the httpCustomAuth credential type.
See references/CUSTOM_CREDENTIALS.md
```
## When the user pastes a secret into a chat
This happens. The user types something like:
> "Set up a workflow to call Acme API with bearer `sk-abc123def456`"
What to do:
1. **Don't put the token in a text field, even temporarily.** A Set node that hardcodes the value and is referenced via `{{$json.token}}` is a text field with extra steps.
2. **Bind to an existing credential if possible.** `list_credentials({type})` first; if a match exists, bind via `setNodeCredential` and tell the user which one you used. If none exists, tell them to create one in the UI (Bearer Auth for bearer tokens, Header Auth for custom headers, etc.). Credential creation is still UI-only.
3. **Treat the pasted secret as compromised, and tell the user to rotate it.** Don't soften this. The token has been transmitted to the LLM provider, may persist in chat history, transcripts, and cache layers. Tell them: "Rotate this token as soon as the new credential is set up. Treat it as leaked."
## When no native node exists
Common case: the user wants a service n8n has no node for. Use HTTP Request with appropriate auth.
- `references/FINDING_API_DOCS.md`: discovering auth scheme, base URL, common shapes.
- `references/HTTP_REQUEST_WITH_AUTH.md`: wiring HTTP Request to a credential.
- `references/CUSTOM_CREDENTIALS.md`: when built-in auth types don't fit.
## Reference files
| File | Read when |
|---|---|
| `references/CREDENTIAL_SYSTEM.md` | You need to understand how credentials are stored, referenced, scoped, or rotated |
| `references/CUSTOM_CREDENTIALS.md` | Multi-header / header-plus-query auth in one credential, or per-request signing patterns (HMAC, JWT, webhook validation) |
| `references/HTTP_REQUEST_WITH_AUTH.md` | Configuring HTTP Request with auth: Bearer, Basic, OAuth, Header Auth |
| `references/FINDING_API_DOCS.md` | The user mentioned a service you don't have node-level knowledge of |
## Anti-patterns
| Anti-pattern | What goes wrong | Fix |
|---|---|---|
| Pasting `sk-...` into HTTP Request's `Authorization` header value field | Token in plain text in the workflow JSON, leaks on export, copy, screenshot | Use a credential: `Bearer Auth` for bearer tokens, `Header Auth` for other custom auth schemes |
| Storing token in a Set node and referencing via expression | Same problem, value lives in workflow JSON | Same fix: credential, not a Set node |
| Storing a secret in `$vars.X` and reading it as the auth value | Not encrypted at rest, leaks in exports, no rotation | Use the right credential type (`httpBearerAuth`, `httpHeaderAuth`, `httpCustomAuth`, or the native one). For inbound webhook auth, use the trigger's `authentication` field, not an IF on `$vars.token` |
| Reaching for `$env.X` to read a secret during custom auth setup | Doesn't work, throws at runtime | Use a credential of the appropriate type |
| Using HTTP Request when a native node exists | Loses auto-refresh on OAuth, loses native error handling, more code | Use the native node |
| Hardcoding credentials in SDK code (`new HttpRequest({ headers: { Authorization: 'Bearer xxx' } })`) | Same leak surface | Use `newCredential()` in SDK code |
| Asking the user to create a credential without naming the credential *type* | User picks the wrong type, auth fails confusingly | Always specify: "create a credential of type `<exact type name>`" |
© n8n-io · Apache-2.0 · n8n-io/skills