groundy
infrastructure & runtime

Claude Code Permissions vs OS Privilege Isolation: What the Gap Costs

Claude Code's per-tool prompts are consent controls, not isolation. A July 2026 arXiv preprint and MCP's prompt-injection bugs show why agent runtimes need real isolation.

8 min···5 sources ↓

Claude Code gates every tool call behind a per-tool allow or deny prompt. It is a workable, coarse privilege model, and it is not a security boundary. The July 2026 preprint “Privilege and confidentiality in generative AI workflows” (arXiv:2607.05479) makes the underlying gap explicit: without an isolation layer beneath the dialog, a malicious prompt or a compromised tool reaches every capability the agent was granted.

Is an agent’s permission prompt a security boundary?

No. An allow/deny dialog gates whether a specific tool runs on a specific invocation. It does not isolate that tool, or the model driving it, from the rest of the agent’s reach.

Claude Code ships across Free, Pro ($17/month), and Max (from $100/month) tiers (Claude plans), and the Claude desktop app adds an Enterprise deployment surface with desktop extensions that govern which local tools and files Claude can reach (Claude download). That is real configuration surface. The threat model it assumes, though, is the user approving a known action.

It does not model the cases that actually break agent runtimes: the model has been steered by content it read into honoring a call the user would never approve, or one connected tool has been poisoned to exfiltrate through another. The prompt answers “did the user consent to this call,” not “is this call confined from everything else the agent can do.” Consent and confinement are different problems, and only one of them is solved by a dialog.

What does the arXiv preprint actually model?

arXiv:2607.05479, “Privilege and confidentiality in generative AI workflows,” authored by Thomas Melham and colleagues and posted July 6, 2026, argues that GenAI systems hold client data in three distinct modes, each with different and “often counter-intuitive” risks to confidentiality and privilege (arXiv:2607.05479).

The three modes:

  1. Model parameters, data absorbed through training and memorization.
  2. The context window, the live session state.
  3. Knowledge databases, the retrieval-augmented generation (RAG) stores.

The paper is a legal analysis, not a systems paper. It reads the first English and American decisions to address privilege and GenAI, UK and Munir v Secretary of State for the Home Department and United States v Heppner, against orthodox privilege doctrine and the SRA framework governing solicitors in England and Wales, and it argues the standard for “effective information governance” against which negligence and misconduct will be measured is moving (arXiv:2607.05479). The audience is lawyers.

The transferable claim is that confidentiality is a property of the storage mode, not of the system as a whole. Two of those modes, the context window and the knowledge database, are exactly the channels an agent runtime mixes together when it runs a tool and feeds the result back to the model. That is the bridge from a legal-privilege paper to a runtime-isolation problem.

What security gaps does MCP expose?

The Model Context Protocol, which Anthropic introduced in November 2024 to standardize how LLMs reach external tools and data sources, has documented prompt-injection and poisoned-tool vulnerabilities that let an attacker exfiltrate data through other connected tools (Wikipedia: Model Context Protocol).

The architecture explains why. MCP distinguishes a host (the AI agent that needs services), a client (one per server, typically on the same machine as the host), and servers that provide tools or resources (Wikipedia: Model Context Protocol). The server advertises its tools to the model; when the model wants one, the host tells the client to call it; the result is injected back into the LLM conversation.

That return path is the soft spot. Output from one tool becomes part of the context the model reasons over, where it can steer a call to a different tool. There is no per-tool confidentiality boundary in that flow. The context window is a shared channel, and the protocol was designed for integration breadth, with Anthropic pitching it as solving an “N×M” connector problem (Anthropic’s MCP announcement), not for compartmentalization.

The protocol’s reach widened quickly, which widened the attack surface for exactly this class of bug. Major AI providers, including OpenAI and Google DeepMind, adopted MCP during 2025 (Wikipedia: Model Context Protocol). In December 2025, Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded with Block and OpenAI. The protocol was created at Anthropic by engineers David Soria Parra and Justin Spahr-Summers; it now routes context between products built by its own founders’ competitors.

Why is an allow/deny dialog not a separation kernel?

A separation kernel enforces isolation between compartments such that code in one cannot read or affect another except through an explicit, mediated channel. An agent permission dialog enforces a user’s yes/no on one call, then hands the result to a process that shares a single context window with every other tool.

This is the structural mismatch. Operating systems spent decades building the guarantees agent runtimes currently ship without: address-space isolation, capability scoping, mandatory access control, and the principle that a principal’s authority is bounded by the kernel rather than by its own good behavior. In the typical MCP deployment the client runs alongside the host on the same machine, the tool’s output re-enters the same conversation, and the model decides what to call next. The dialog sits on top of that flow, not beneath it.

A poisoned tool does not need to defeat the prompt. It needs to shape the context the model reasons over, which the dialog never inspects. The yes/no gate answers the wrong question for a threat that travels through prose.

Where does the least-privilege burden now land?

On the infrastructure that serves the agent, because the agent runtime itself does not enforce isolation between the capabilities it has been granted.

For self-hosted agent stacks that run tool calls inside the model’s own process, this is the live exposure. The enterprise deployment surface Claude desktop ships governs who can deploy what. It does not compartmentalize what a running tool can touch once it has been approved. The three-mode model from arXiv:2607.05479 sharpens why this matters: data in the context window is not isolated from data a tool returns, so a confidentiality classification on one resource does not survive contact with the shared conversation.

The least-privilege work operating systems did at the kernel level has to be re-created, somehow, above the model. The consent layer already exists in every major agent product. The isolation layer beneath it, for the most part, does not.

What should agent runtimes borrow from operating systems?

A tool call should run as a confined principal whose authority the runtime bounds, not as code the model invokes inside its own address space.

That points at OS-derived machinery: capability tokens scoped per tool, mediated channels between compartments, output sanitization before re-injection into the context window, and an isolation boundary the model cannot dissolve by reasoning around it. The arXiv preprint does not prescribe this architecture; it prescribes treating each data mode as a separate confidentiality domain. Translating three confidentiality domains into a running runtime is left to the builders, and the gap between the paper’s model and current MCP hosts is where the engineering work actually sits.

Claude Code, Cursor, and any MCP host that ships a permission UI today is shipping the consent layer without the isolation layer beneath it. A permission dialog is a usable privilege control. It is not, and cannot be, a security boundary on its own. The closer agents get to running real actions on real data, the more expensive that distinction becomes.

Frequently Asked Questions

Does this isolation gap affect only Claude Code, or other agent runtimes too?

It affects any runtime that ships a consent UI without a separation kernel beneath it. Cursor, other MCP hosts, and OpenAI’s ChatGPT MCP integration (added September 2025) all route tool output back into a shared context window. Even Claude desktop’s enterprise controls, which let admins pre-approve local extensions and manage versions, govern deployment and identity, not what a running tool can touch after approval.

How is MCP’s architecture different from an OS-style separation kernel?

A separation kernel enforces isolation between compartments and mediates every cross-boundary access through explicit, kernel-controlled channels. MCP uses JSON-RPC 2.0 between a host, a client on the same machine, and remote or local servers, so a tool’s output re-enters the model’s context as ordinary prose and can steer the next call. The protocol was built to solve the N-by-M integration problem, not to provide address-space isolation, capability scoping, or mandatory access control.

What operational changes should teams make to reduce exposure?

Teams should inventory every MCP server and local extension, classify data by the arXiv paper’s three storage modes, and run tool calls inside sandboxes or separate processes with narrowly scoped capability tokens. They also need to sanitize tool outputs before re-injection, because the context window is a shared channel and one server’s text can manipulate calls to another. That adds latency and infrastructure cost, but it is the only way to turn a consent layer into something closer to a confinement layer.

Can enterprise SSO or pre-approved tool lists remove the risk?

No. SSO, managed-device authentication, and pre-approved extension lists are deployment and identity controls, not runtime isolation. Once a tool is approved and running, a poisoned server or injected prompt can still move data between tools through the shared context window. The English and American privilege cases the arXiv paper cites point toward a legal standard of effective information governance that may outrun whatever consent dialogs the vendor provides.

What would force vendors to close the isolation gap?

Enterprise liability and the moving legal standard for effective information governance are the most likely pressures. The Agentic AI Foundation, which took over MCP in December 2025, could in principle add isolation primitives to the protocol, but its current focus is interoperability across hosts built by competing vendors. Until buyers demand separation-kernel guarantees and regulators measure negligence against them, consent dialogs will remain cheaper to ship than confinement layers.

sources · 5 cited

  1. arXiv:2607.05479arxiv.orgprimaryaccessed 2026-07-09
  2. Claude plansclaude.comvendoraccessed 2026-07-09
  3. Claude downloadclaude.comvendoraccessed 2026-07-09
  4. Wikipedia: Model Context Protocolen.wikipedia.orgprimaryaccessed 2026-07-09
  5. Anthropic's MCP announcementanthropic.comvendoraccessed 2026-07-09