MCP vs CLI: What happens when your AI agent can’t find the connector

When an AI agent needs to act on a machine, the clean route is the Model Context Protocol (MCP). An MCP server exposes a defined set of tools, the agent calls them, and you can reason about what it’s allowed to do because the list is short and written down. Then the agent needs something with no connector, like an in-house ticketing system or a line-of-business app nobody has touched since 2012, and the story changes. An agent determined to finish its task looks for another door, and that door is almost always the command line.

Most of the MCP vs CLI conversation online centers on token costs, OAuth, and credential handling, which are fair things to argue about. Very little of it asks what the endpoint will actually run once the agent steps off the MCP path, and that’s the part IT admins end up owning.

MCP vs CLI

The two approaches give an agent very different amounts of power. With MCP, the agent gets a defined list of tools and nothing else. With a CLI, the agent drives a shell, and a shell carries every right the logged-in user has. Code mode, the newer pattern covered below, behaves like the CLI side of that line when it runs on a managed desktop, because the agent writes its own program and the machine runs it.

That difference explains why developers like the CLI (it’s light on tokens, and agents are familiar with tools like git and docker) and why security teams like MCP (a short list is easier to audit, and OAuth gives you central authentication). Both camps have a point. What neither camp settles is what stops an agent from running something nobody approved once it leaves the tool list.

Agents fall back to the CLI

Say a developer asks an agent to pull data from that ticketing system. With no connector, the agent writes a script, downloads a helper binary, and strings a few commands together, and nobody approved any of it because your MCP governance never saw it. The agent left the MCP world entirely. It plays like a heist movie in which the security team spent months on the front vault while the crew walked in through the loading dock; the crew here is well-meaning software, and the dock is just as open.

The fallback is also quiet, because an MCP log has no record of a PowerShell command the agent ran on its own.

Code execution with MCP puts agent-written code on your endpoints

MCP itself is changing. Instead of calling one tool at a time and routing every result back through the model, agents are moving to code mode: the agent writes a small program that calls the MCP tools, filters and combines what comes back, and runs the whole thing. Anthropic described this pattern in its engineering blog, and the appeal is easy to see, since one script can make twenty tool calls without passing each result through the model. It saves tokens and makes agents more capable, so it’s gaining ground.

It also puts real, agent-authored code on your endpoints. Code execution with MCP shifts the control question from which tools the agent may call to which programs the endpoint will run, and a program is only as trustworthy as whatever wrote it. Some setups run that code in a sandbox, and a sandbox helps a great deal. A managed Windows or Mac desktop is usually not a sandbox, though, and if the machine executes anything it’s handed, your approved tool list is a suggestion, because the agent’s code can step around the MCP server as easily as through it.

What a rogue shell or agent script can do under local admin

The damage depends on whose rights the agent is borrowing. Under a local administrator, the CLI fallback has full control of the machine, so it can install software or switch off protections without asking anyone. A standard user’s agent can still run an executable nobody reviewed, either because of its own mistake or because a prompt injection hidden in a document it read told it to.

Enforce limits where the code runs

Many teams try to rein in the agent itself with system prompts, guardrails, and plain-English policies. Those help, but they live on the AI side, and an agent can be confused or manipulated. The dependable move is to enforce limits where the code runs, so the outcome stays safe whatever the agent attempts. The endpoint is the part of the stack IT already owns, and it’s where PolicyPak works.

How PolicyPak handles MCP vs CLI: Least privilege and allowlisting

PolicyPak attacks the problem from two directions, and the first is least privilege. PolicyPak Least Privilege Manager removes local administrator rights from users and grants admin rights only to the specific applications and tasks that need them, on Windows and Mac. An agent that falls back to the CLI under a standard user can’t install drivers or tamper with security tools, and the exceptions you did grant stay scoped to the apps you named.

The second is allowlisting. PolicyPak SecureRun works from file ownership: executables introduced by standard users, or by an agent acting as one, don’t run unless a trusted account owns them, such as your software deployment tool or an administrator. That matters for code mode. When an agent writes a script or drops a helper binary, SecureRun doesn’t trust the file and blocks it, which is also why it works as one-click ransomware prevention. You get a blanket allow list without hash-by-hash upkeep and without ripping out the tools you already use.

Agents can keep using MCP wherever a connector exists. Where none does, the CLI fallback lands on a machine where the user has no admin rights and the file the agent just wrote has no trusted owner, and that stays true when code execution with MCP is the norm.