Use a newly approved, narrowly scoped OAuth connection for an n8n MCP client, give its user access only to the resources it needs and test a forbidden action directly against an inert canary. A client-side promise to ask before executing is useful, but the server's grant must enforce the boundary.
As of 1 November 2026, advice that n8n MCP has no client-specific action scopes is outdated. n8n added OAuth scope selection and enforcement; existing connections can retain their previous full-access grant. That does not create a different per-client workflow allowlist.
Distinguish three credentials that look similar
Start by identifying the server and credential your assistant actually uses. A third-party MCP bridge, n8n's built-in instance server and an individual workflow's MCP Server Trigger do not share one universal permission model.
| Connection | Authentication and boundary |
|---|---|
| Built-in instance MCP with OAuth | A user approves a client grant. Current versions support action scopes; user access and workflow exposure still apply. |
| Built-in instance MCP personal API token | A bearer token tied to the user. Do not assume it has the narrowed OAuth grant. |
| Public REST API key | Uses X-N8N-API-KEY. Its scope availability depends on the plan and is distinct from MCP OAuth. |
The MCP connection documentation describes the instance-level personal token and OAuth connection. The public API authentication reference says non-Enterprise REST keys have full access to the account's resources and capabilities; Enterprise keys can be scoped. Do not paste a REST key into a different interface and infer that its policy followed it.
For the scoped OAuth implementation, the n8n 2.45.7 scope map distinguishes scope-bearing grants from API keys or legacy delegations. Treat credential choice as part of the security design, not just a setup preference.
Use all three permission layers
1. The authenticated user's resource access
An assistant acting as an instance owner starts with a larger potential reach than one acting as a narrowly assigned user. Where your edition supports the required roles and project assignments, use a dedicated identity and test its actual visibility. Do not invent a project boundary that your installed plan cannot enforce.
Read access can disclose workflow names, business logic, sample data and execution output. Decide whether the assistant needs those details before granting them. A workflow with no execution permission can still reveal confidential information through its definition or stored results.
2. Workflow exposure
Instance-level MCP and individual workflow exposure must be enabled deliberately. However, search_workflows is a documented exception: it can return previews for workflows the user can view even when they are not marked Available in MCP. Hiding a workflow from execution is therefore not a complete confidentiality boundary.
The current connection documentation also says workflow exposure is not a separate allowlist for each client. If two clients use the same user and have the same relevant scope, do not assume you can expose workflow A only to one of them with that toggle. Use a real resource boundary or a deliberately narrow workflow-level tool design when you need that separation.
3. The OAuth grant's action scopes
Start with the smallest useful grant. For a workflow-review assistant, workflow:read is a clearer starting point than a broad read-only preset that might also include execution history or other resources you do not need.
| Need | Relevant current MCP scope | Boundary to test |
|---|---|---|
| Inspect workflows | workflow:read | Search succeeds; execution and editing are unavailable. |
| Run an exposed workflow | workflow:execute | Only the intended user-accessible workflow can run. |
| Build or change workflows | workflow:write | Review editing and publishing reach before granting. |
| Inspect execution data | execution:read | Confirm outputs contain no unnecessary sensitive data. |
The scope map associates execute_workflow, test_workflow and pin-data preparation with execution permission. A tool named “test” is not automatically harmless. The tools reference explains that test workflows can still run credential-free I/O nodes. Keep real shell commands, file writes and external side effects out of a permission canary.
Create a fresh, restricted connection
- Inventory the client. Record its owner, purpose, requested resources and whether it needs to read, edit or execute.
- Check the installed version. Confirm the consent screen offers scope selection. An old full-access connection is not narrowed simply because the instance was upgraded.
- Enable only the required MCP exposure. In Settings, Instance-level MCP, review the workflows exposed to clients before connecting the assistant.
- Choose OAuth. In the current connection dialog, connect the client, review the callback destination and choose Custom scopes for the specific task.
- Record the grant. Save a private record of scope names and the approving person. Exclude tokens, signed URLs and confidential workflow contents.
The current settings layout is documented from n8n 2.33.0; older versions differ. Review connected OAuth clients in that page and revoke obsolete grants. Personal bearer-token clients do not appear in the same OAuth client list. Rotate and inventory those separately rather than treating an empty list as proof that no client has access.
If you are replacing an existing broad connection, create and validate the restricted grant first, then retire the old access intentionally. Changing an assistant's prompt does not remove a credential it already possesses.
Prove an allowed read and a blocked execution
Download the acceptance probe and inert workflow. The example requires Python 3.9 or later and the standard library. Its protocol baseline is n8n 2.45.7; inspect your installed version's schema rather than relying on features documented only for later releases.
Import the canary into a disposable instance. Its only nodes are Manual Trigger and No Operation. Confirm there are no credentials, network requests, file operations or scheduled triggers. Mark it available to MCP, leave it unpublished and record its actual ID.
First, use an authorised test connection to execute that canary in manual mode and confirm completion. This positive control establishes that the workflow and its ID are valid. Without it, a failed execution might simply mean the workflow does not exist or cannot run.
Next, create a separate OAuth connection granting only workflow:read. With that connection:
- List tools and confirm
search_workflowsis present. - Perform the read and confirm it succeeds under the expected identity.
- Confirm execution and mutation tools are absent from the complete, paginated tool list.
- Send a direct
execute_workflowrequest for the known inert canary and require a server-side unregistered-tool rejection. - Check in n8n that no new canary execution was created.
A direct test request has this tool-call shape:
{
"name": "execute_workflow",
"arguments": {
"workflowId": "ACTUAL_DISPOSABLE_CANARY_ID",
"executionMode": "manual"
}
}The downloaded probe performs initialization, tool listing, an allowed read and the denied call. It prompts without echo for a short-lived OAuth access token; obtain that token only through approved client tooling. If your client does not expose it securely, perform the same checks in its MCP inspector instead of copying internal credential files.
python3 probe.py \
--endpoint http://127.0.0.1:5678/mcp-server/http \
--canary-workflow-id ACTUAL_DISPOSABLE_CANARY_ID \
--confirm-disposable-canaryUse loopback HTTP only for the isolated lab; use verified HTTPS elsewhere. The probe does not substitute an unscoped personal token for the OAuth token. It refuses to call if any advertised tool falls outside its pinned workflow:read allowlist. A later version with a different tool set requires review before updating that allowlist.
A timeout, expired token, HTTP 401, malformed request or missing workflow is not evidence of least privilege. The result must identify the forbidden tool boundary, with the successful read as its authentication control. If the boundary fails, the canary might run; never use a production workflow for this check.
Keep the boundary useful over time
Separate a review assistant from a production execution assistant. If a workflow sends email, changes billing or deletes records, its own input validation and approval design still matter after authentication. Scope permission to execute a workflow does not validate every argument or authorise every business action inside it.
Recheck grants after upgrades, role changes and workflow changes. Remove old clients and investigate unexpected tool visibility before relying on the connection. Retain a concise acceptance record containing the version, user role, selected scopes, allowed read, denied action and absence of a new execution.
Plan the operating responsibilities with our managed versus self-hosted guide and n8n deployment guide. If managed hosting fits your team, explore DanubeData n8n hosting; verify the installed version, plan and available permission controls before connecting a client.
Frequently asked questions
Does a read-only prompt stop execution?
It expresses intent to the assistant. A server-enforced OAuth grant and a negative acceptance test establish the technical boundary.
Is the personal MCP API token equivalent to scoped OAuth?
No. Treat it as a separate user delegation. Do not assume it inherits the action restrictions selected for an OAuth client.
Can each client have a different workflow exposure list?
The documented instance-level exposure is not a per-client workflow allowlist. Combine user resource access with action scopes, or design a narrower tool surface and verify it independently.
Is test_workflow a safe substitute for permission testing?
Not for an arbitrary workflow. Its execution can include side effects. Use a deliberately inert canary and test the exact forbidden action.
Sources
MCP connection and exposure; OAuth scoping implementation; 2.45.7 scope map; tool parameters; REST API keys.
