Kobel alternatives

An overview of everything that tries to solve “the AI should reach my files, but not all of them” — including the cases where the right answer is not Kobel.

Last verified: 2026-08-23

The landscape at a glance

For one person, not for a company

Search for “MCP gateway” and you get lists written for platform teams almost exclusively: Kubernetes, SSO, role-based access, multi-tenancy, pricing on request. For one person with a laptop none of that applies — and the question goes unanswered.

For that case the question splits in two, and it pays to answer the halves separately:

• Keep third-party server processes away from the machine. Use containers: Docker MCP Toolkit or ToolHive. An unknown MCP server does not belong on your machine unguarded.
• Grade your own folders and keep a record. That needs a permission layer on the device. This is exactly where Kobel sits: five levels per folder, the same ruleset for every connected AI, and a log the AI cannot reach — no identity provider, no YAML, no server.

No enterprise gateway solves the second half, because none of them can see the local filesystem. And no container solution solves it either, because it ends at the first mounted working folder. If you work alone, you usually do not need what the “best gateway” lists are selling.

The approaches one by one

1. The official MCP filesystem server

The most common answer, and for many people the right one. Open source under MIT, free, runs anywhere Node or Docker runs — including Linux, where Kobel does not exist. It takes a list of allowed directories, either as arguments or through the client's roots protocol.

Where it ends: there is no read-only mode in the server and no activity log. Every tool applies to every allowed directory equally, the writing ones included. Full comparison

2. Docker MCP Toolkit and Gateway

Runs MCP servers in containers. Docker's documentation: “By default, MCP Servers have no access to the host filesystem.” Add catalog images built and signed by Docker with an SBOM, resource limits, secret blocking in tool traffic and per-tool allowlists. For trying out third-party servers this is the best approach on this page.

Where it ends: at the mounted folder — the filesystem server's catalog entry exposes only a path list, no read-only switch. Labelled beta in the docs, and Docker Desktop is paid above 250 employees. Full comparison

3. Windows Sandbox, Hyper-V, VMs

The right answer for software from a doubtful source. Windows Sandbox is ephemeral — everything is discarded on close — and does not run on Windows Home.

Where it ends: at the folder you have to hand in to work on real files. Microsoft itself warns that write changes to mapped folders survive the sandbox. Full comparison

4. OS file permissions or a second user account

Costs nothing and is already there. Run the AI under its own user account and NTFS permissions decide what that account sees.

Where it ends: operating system rights have no notion of “readable, but back it up before every change” or “read the original, write only to copies”. They do not log AI actions as such, and switching accounts makes daily work awkward. The approaches compared

5. Permissions in a text file: Continue and Cursor

Technically the finest-grained models in this list: Continue has three levels (allow, ask, exclude) with glob paths in permissions.yaml, Cursor a permissions.json with server:tool matching and wildcards.

Where it ends: at the person. Someone who does not edit YAML will not set this up — and the permission model that gets used is the one that gets set up.

6. ToolHive

Container isolation plus permission profiles for network and filesystem, Apache 2.0. The most interesting middle ground for technical users who need open source.

7. Enterprise MCP gateways

MintMCP, TrueFoundry, Obot, Pomerium, Kong, Cloudflare, IBM ContextForge, Portkey, agentgateway. They sit in the network in front of remote MCP servers, authenticate against an identity provider and produce audit-grade trails.

Where they end: they cannot see what a local AI client does to the local filesystem. Full comparison

8. Traffic inspectors: Lasso MCP Gateway, MCP Defender

They inspect local MCP traffic for secrets, personal data and prompt injection. Useful — but they do not answer which folder has which rights. A complement, not a replacement.

9. n8n and other automation tools

Often mentioned in the same breath, but solving a different problem: they establish a connection and authenticate it. They do not authorise an individual action on an individual file. Full comparison

And Kobel

A desktop app for Windows and macOS that acts as a local MCP gateway between AI assistants and the folders, apps and accounts of the device. Every resource carries one of five levels; the same ruleset applies to every connected AI. Everything runs on the device, and every action lands in a log the AI cannot reach.

What Kobel cannot do

• No process isolation. Kobel will not contain a malicious server process — use a container for that.
• No provenance checks on third-party MCP servers. Signed images and SBOMs are Docker's department, not this one.
• No per-AI rulesets. An individual AI can be switched on or off, but there is no separate rulebook per assistant.
• No Linux. Windows and macOS, nothing else.
• Not open source. If that is a requirement, Kobel is out.
• No identity provider. No SSO, no SAML, no RBAC through Okta or Entra.
• No control over the AI client's own built-in tools. Kobel's five levels govern what an AI does through Kobel. If the AI client has its own terminal, its own file editor, or a second MCP server configured directly inside it, those calls bypass Kobel entirely and do not appear in its log either. Kobel is a permission layer for the connection it sits in, not an operating-system boundary. For a folder that must be unreachable whatever tool is used, pair red with a Deny permission in the Windows security dialog for the account the AI runs under.

Kobel's five permission levels

Every folder, app and account carries exactly one of these five levels. You set it by dragging a folder in and picking a colour — no configuration file.

• GreenRead and write. The AI may open files and save changes directly.
• TealWrite with an automatic backup. A copy is made before every change, so a bad edit can always be undone.
• OrangeRead the original, write only to copies. The AI can work with the data but cannot alter the source file.
• YellowRead only. Look, don't touch.
• RedBlocked. The resource is invisible to the AI.

Keep reading

Sources