What n8n AI agents per-user permissions actually mean
n8n AI agents per-user permissions come down to one question. Whose credential does the run hold? n8n's default is a Fixed credential. It is the same account for every execution, manual or scheduled. An agent reaching Salesforce, Jira and Zendesk reaches them as whoever connected those accounts. That holds no matter who started the run. n8n documents this directly. It warns that a Fixed credential can expose one person's access to everyone (docs.n8n.io, checked October 2026).
Elaichi comes at the same question from the other side. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Every company account is connected once, and the tools those accounts expose are served through one organization-wide MCP endpoint at POST https://api.elaichi.ai/mcp. A client signs in there over OAuth and holds a grant, which is the permission one named person gave one named client. That grant carries the person's role, and their restrictions apply on every call. A restriction is a rule naming which connectors and which individual tools a role or a user may reach.
n8n is not on the list of clients Elaichi names as connecting. Nothing here says it connects.
Fixed credentials versus end-user credentials in n8n
n8n has a per-user credential model, and its documented limits decide whether it helps you here. A Fixed credential, the default, resolves to one account for everyone. End-user credentials resolve per user. But n8n currently lists them as Enterprise, in Preview, not for production, OAuth only, and team projects only (docs.n8n.io, checked October 2026).
The supported triggers matter more than the tier:
| Trigger | Resolves credential per user? | Notes |
|---|---|---|
| Manual trigger | Yes | Supported |
| Chat Hub | Yes | Supported |
| MCP Server Trigger | Yes | Supported |
| Form trigger | Yes | With n8n User Auth |
| Chat trigger | Yes | Hosted Chat, with n8n User Auth |
| Schedule Trigger | No | Runs as whatever account the workflow's credential resolves to; no per-run identity |
The Schedule Trigger runs a published workflow on intervals or cron. It is not on n8n's list of triggers compatible with end-user credentials. So a scheduled agent cannot use n8n's native per-user identity today, as of n8n's current docs. Whether an MCP OAuth2 credential can itself be configured as an end-user credential is not documented either way. Treat that as an open question to ask n8n, not an assumption to design around.
Credential sharing sits underneath all of this. Sharing is available on every n8n Cloud plan and on self-hosted Business and Enterprise, and recipients can use a shared credential without seeing its contents. That's convenient, and it's the shared-account problem in another shape: everyone using a shared credential inherits one identity.
Does n8n meet Elaichi's endpoint requirements?
On paper the two lists line up. Verify it in a throwaway workflow before you build on it. Matching documentation is not the same as a working handshake. When the handshake fails, the OAuth error itself names what to fix.
The endpoint requires MCP over Streamable HTTP with JSON-RPC 2.0, stateless, behind OAuth. Clients register themselves through dynamic client registration (RFC 7591), so there's no client ID or secret to paste in manually. PKCE with S256 is required. It proves the software finishing sign-in is the software that started it. A missing code_challenge_method is not assumed to be S256, and plain is refused outright. A resource value, if the client sends one, must be https://api.elaichi.ai, or the token request fails with invalid_target. Scopes are limited to mcp:read, mcp:write, mcp:destructive, mcp:tools, openid and email.
n8n's MCP Client Tool documents Server Transport as HTTP Streamable (the default) or deprecated SSE. It documents authentication as Bearer Auth, Header Auth, MCP OAuth2, Multiple Headers Auth or None. Its MCP OAuth2 credential uses dynamic client registration by default and takes an optional Resource URL. It negotiates PKCE with S256 where the server supports it (docs.n8n.io, checked October 2026).
Two behaviors to check at first sign-in:
- Scope narrowing is possible, widening isn't. A client that requests no scope at all gets read-only access. Connected third-party tools additionally require
mcp:tools(the "Run your connected tools" checkbox). Withoutmcp:destructive, any connected tool whose underlying method is a delete is excluded from both the tool list and the search index. It is not just blocked at call time, but invisible. Consent can only narrow what a client requested. - Rate limiting. The endpoint allows 120 MCP requests per minute per token and returns HTTP 429 with
Retry-After: 60above that. A wide fan-out loop will hit this, for example an agent callingsearch_toolsper item in a batch. Batch or cache tool discovery instead of repeating it per item.
Whose identity does a scheduled run act as?
Through Elaichi, a scheduled run acts as the member whose grant the credential holds. There is no anonymous service identity on the endpoint. The grant is read fresh on every call. So the run gets that member's current reach and nothing wider than it, at the moment the call happens.
Three consequences follow. First, that member's role restrictions apply to the run exactly as if they'd made the call themselves. A role or restriction change reaches the run within about two minutes. Second, each tool-call attempt gets an audit entry, succeeded or failed. It names the member, the surface mcp, the OAuth client it came through, the tool, and the connection actually reached. Third, a call from an MCP client is recorded with actor_kind of user, not as an AI actor. Elaichi's AI marker covers only its in-product Agent, not third-party MCP clients calling in.
The client name on an audit entry is marked verified only where its redirect URIs prove it. This currently covers Claude, ChatGPT and Cursor. Any other client shows the name it registered with, marked unverified. Read that as a label for a human reviewer, not as a security control that blocks anything.
Name the trade-off before you ship it. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change. A SCIM deprovision suspends rather than deletes, with the same effect on grants. A nightly workflow signed in with a departed employee's grant stops running that night, mid-pipeline if it's mid-run. Sometimes that's exactly the behavior you want; sometimes it's an unplanned outage. Decide which, deliberately, before it happens. See offboarding AI access.
Plan for token lifetimes too. An access token lasts an hour, and a refresh token lasts 30 days and rotates on every use. A workflow idle for more than 30 days needs its credential reconnected. Reusing an old refresh token revokes the whole grant, so test what happens when two executions refresh the same credential at once.
Why Tools to Include cannot pick one connected app
It cannot, because connected tools are never advertised one by one. Elaichi lists its own elaichi__ operations individually, plus two generic tools: search_tools and execute_tool. Connected third-party tools (Jira, Zendesk, Salesforce, etc.) are found with search_tools and run with execute_tool, regardless of how many connected tools exist behind them.
n8n's Tools to Include option offers All, Selected or All Except over the tools a server advertises. Against this endpoint, that means picking or excluding execute_tool as a single unit, never Jira's create-issue tool as distinct from Zendesk's. The same ceiling applies to n8n's human-in-the-loop approval for tools. It gates execute_tool as a whole, not the specific operation behind it. execute_tool is also annotated destructive and open-world by design, because its real risk tier isn't knowable before the call resolves. So a client configured to prompt on anything not marked read-only will prompt on every connected call, reads included.
Per-app and per-tool control lives in Elaichi's restriction layer instead, scoped to a role or a user. Blocks beat allows, and a withheld tool is fully invisible. It's absent from the tool list, absent from the search index, and its name never appears on the wire. One caution on allow rules. An allow rule is the target's entire allowlist across every connector. So a role restricted to one app's read tools also needs explicit allow rules naming every other app it uses. Otherwise those calls fail silently from the agent's perspective. Restricting one tool or a whole app walks through the six cases this produces.
What n8n's own logs record, and what they miss
n8n's audit events leave the instance only through Log Streaming, which is Enterprise-tier. Two gaps matter specifically for a scheduled agent. Workflow execution events carry no userId when a Schedule Trigger starts the run. There's no human to attribute it to in n8n's own data model. And n8n's MCP-specific audit events cover its instance-level MCP server, not the MCP Server Trigger used inside workflows (docs.n8n.io, checked October 2026). If a scheduled agent deletes a record, n8n's log alone will not name the human accountable for it. It names only the workflow and the service account it ran under.
Elaichi's audit trail is a different unit of record: per call rather than per workflow execution. Elaichi writes one entry per tool-call attempt, succeeded or failed. The text written to the trail is never derived from the third party's response. So a malformed or hostile error body from, say, Jira cannot inject content into the log pipe. The trail is org-visible, newest-first, and filterable by actor, category, action kind and time. A free read-only Auditor seat lets a compliance reviewer read it without a paid license. It's eventually consistent, so a row may take a moment to appear after the call completes. Forwarding it to your own Datadog comes with the Black plan, launching soon. For what a record needs to contain to actually survive a compliance review, see what an AI agent audit log must capture.
Who should sign the workflow credential in
The person who owns the workflow, using their own grant, under their own role, not a shared admin account. That keeps one accountable name on every run. It also caps the blast radius at one job's worth of access, rather than an administrator's entire reach. Every member holds exactly one role, so a workflow inherits its owner's whole role. If that is wider than the job, have the credential signed in by someone whose role fits the job. One role each covers why a role should be a complete, narrow persona rather than a reused one. Use n8n's end-user credentials only where n8n's documented triggers actually support them. As of this writing, that excludes the Schedule Trigger.
There's a case where none of this is worth doing. Say a workflow touches exactly one app, and n8n already has a native node for it. If a single service account on that one app is an acceptable risk for your org, a control plane buys you an audit trail and restrictions you don't yet need. When you don't need an MCP gateway is the honest version of that decision. Read it before adding infrastructure you won't use.
If you do need per-user control across multiple apps, the shape is simple. One endpoint, one grant per person, no shared bot identity, one role per job. The same endpoint is what people point Claude and ChatGPT at. Elaichi authors and serves the 600+ connectors in its connector catalog directly. So restrictions are defined once at the gateway, rather than re-implemented per downstream server or per workflow tool.
