Kobel and n8n
Both speak MCP, which is why people compare them — and why they combine rather well. One builds the automation; the other decides what that automation is allowed to touch.
Last reviewed:
n8n authenticates a connection. Kobel authorises an action. That one sentence covers most of the difference — and explains why the two compose instead of competing.
n8n is workflow automation that can speak MCP in both directions: its MCP Server Trigger turns selected workflows into tools an AI can call, and its MCP Client Tool lets an n8n agent call external MCP servers. The protection on that endpoint is a bearer token or a header token — you either have it or you do not. There is no per-caller identity for MCP, no per-tool policy and no approval step. n8n does have file nodes and its own user RBAC, but those govern n8n's own workflows and n8n's own users, not what an AI assistant may do with the folders on a desktop. Kobel does none of n8n's automation and all of the permission work n8n leaves undone — and because Kobel is itself an MCP server, an n8n agent can be pointed at it and inherit that boundary.
Running both together
This is the part most comparisons miss. There are two ways the pieces fit, and neither is a workaround:
- n8n calls Kobel. n8n's MCP Client Tool lets an AI Agent node consume an external MCP server. A local permission gateway is exactly that — an MCP server — so an n8n agent can be pointed at Kobel and then reaches only the folders and apps that were released, at the level they were released at, with every call written to the local activity log. The automation keeps its logic; the file and app access gains a boundary it did not have.
- Kobel governs n8n. Kobel's app proxy makes local software MCP-capable without modifying it, and the same per-app on/off switch and the same log apply. If n8n runs on the same machine, it can sit behind the same permission layer as everything else.
Both are the normal shape of the pattern: automation on top, authorisation underneath. Check kobel.app for the current setup steps before you build around a specific one.
At a glance
| n8n | Kobel | |
|---|---|---|
| Category | Workflow automation | Permission layer for AI agents |
| Unit of work | A workflow you build | A permission you grant |
| Speaks MCP | Yes — as server and as client | Yes — as a local gateway |
| Auth on its MCP endpoint | Bearer token or header token | Per-resource level, enforced locally |
| Per-caller identity for MCP | No — bearer/header token only (n8n's own RBAC governs n8n users, not MCP callers) | The person at the device |
| Per-tool or per-folder policy | No — you curate which tools are wired up | Five levels per resource |
| File permissions | Reads and writes on the host it runs on; self-hosted installs can restrict paths with N8N_RESTRICT_FILE_ACCESS_TO | Five graded levels per folder on the user's desktop |
| Approval before risky actions | No | Enforced by level; delete unavailable below green |
| Logging | Execution history for debugging | Access log for accountability, not reachable by the AI |
| Runs | n8n cloud or self-hosted server | Windows and macOS desktop |
| Typical user | Automation builder | Anyone who wants to say "not that folder" |
Where they genuinely overlap
The confusion is not unreasonable. Both speak MCP, and both can end up between an AI and a business system:
- n8n's MCP Server Trigger exposes selected tool nodes and custom workflows over SSE or streamable HTTP, so an AI client can call them. Functionally that is the same slot as any tool-supply platform.
- n8n's MCP Client Tool lets an n8n AI Agent node consume external MCP servers — the hook that makes the combination above possible.
- Choosing which nodes get wired to the trigger is a coarse allowlist — a form of curation, if not of policy.
- Self-hosting n8n keeps MCP traffic inside your own infrastructure, which overlaps the "no third-party cloud" pitch.
Where they do not overlap
- There is no permission model on the MCP endpoint. The MCP Server Trigger supports bearer auth or header auth. Authorisation is binary — token or no token. Nothing distinguishes one caller from another, and nothing distinguishes a harmless read from a destructive write. n8n's RBAC governs who may edit workflows in n8n, not what an MCP caller may do.
- The filesystem story is a different one. n8n's Read/Write Files from Disk node touches the disk of
the machine n8n runs on, and self-hosted installs can bound it with
N8N_RESTRICT_FILE_ACCESS_TO. That is a server-side path restriction for workflows you wrote. It says nothing about what an AI assistant on your laptop may read, and it has no read-only versus write-with-backup gradation. - It is not in the traffic path. n8n is an endpoint or a caller, never a mediator. It cannot observe, let alone block, a call it is not part of. If an assistant on your laptop reads a folder directly, n8n never knows.
- Different artefact, different person. n8n's user builds automations. A permission layer's user wants to express one sentence — "not my tax folder" — and then stop thinking about it.
- Logging serves a different purpose. Execution history exists to debug a workflow. An access log exists to answer "what did the AI touch, and when" — and Kobel's is not exposed to the AI through the gateway, so a connected assistant can neither read it nor alter it.
If n8n is what you actually wanted
Some people arrive at this comparison because they want AI to do things in SaaS apps, not because they are worried about files. If that is you, the honest recommendation is not Kobel:
- Zapier MCP — thousands of SaaS actions exposed to AI, with tool-by-tool selection of what the server exposes and account-level app restrictions applied automatically. No terminal required.
- n8n — more control, self-hostable, better for complex branching logic.
- Composio or Arcade — managed tool-calling infrastructure for developers building agents.
Kobel becomes relevant when the resources in question are on your own machine, or when you want one rule set covering files, in-house software and social accounts at once — including as the layer underneath whichever of these you pick.
Kobel's five permission levels
Every folder, app and account gets exactly one of these five levels. You set it by dragging a folder in and picking a colour — there is no configuration file.
- GreenRead and write. The AI may open files and save changes in place.
- TealWrite with automatic backup. Every change is preceded by a backup copy, so a bad edit is always reversible.
- OrangeRead the original, write only to copies. The AI can work with your data but cannot alter the source file.
- YellowRead only. Look, don't touch.
- RedBlocked. The resource is invisible to the AI.
Keep reading
Sources
Try it on one folder
Install Kobel, drag in a single folder, set it to read-only, connect your assistant. Two minutes. Free Basis tier, no account needed.
Download KobelSee featuresFrequently asked questions
Is n8n a competitor to Kobel?
No. n8n is workflow automation that can act as an MCP server or client; Kobel is a permission layer that decides what an AI may access on a specific machine. The one-line summary is that n8n authenticates a connection while Kobel authorises an action against a specific resource.
Can n8n restrict what an AI agent is allowed to do?
Only coarsely. You decide which tool nodes are wired to the MCP Server Trigger, and the endpoint is protected by a bearer or header token. There is no per-caller identity, no per-tool policy and no approval step, so any caller holding the token gets everything that is wired up. n8n's role-based access control governs who may work in n8n, not what an MCP caller may do.
Can n8n control access to files on my computer?
Not in the sense people mean. n8n's Read/Write Files from Disk node accesses the filesystem of the machine n8n itself runs on, and a self-hosted install can bound it with N8N_RESTRICT_FILE_ACCESS_TO. That governs workflows you built on the server; it does not govern what an AI assistant on your own desktop may read, change or delete, and it has no graded levels such as read-only or write-with-backup.
Can I use n8n and Kobel together?
Yes — and they compose in two directions. n8n's MCP Client Tool can point an AI Agent node at an external MCP server, and a local permission gateway is exactly that, so the agent reaches only what was released and every call is logged. In the other direction, Kobel's app proxy can make local software MCP-capable and put it behind the same permission layer. n8n keeps the automation logic; Kobel supplies the authorisation and the audit trail.
What should I use if I want AI to act in SaaS apps rather than files?
Zapier MCP is the most approachable option for non-technical users: you pick tool by tool what the MCP server exposes, and account-level app restrictions apply on top. n8n gives more control and can be self-hosted. Composio and Arcade target developers building agents. Kobel is the right answer when the resources are local.