CLI Agents Are Bypassing MCP. Here Is What That Means for Security.

The CLIHub Argument

The pitch for CLI-first agent tooling is simple and effective: MCP is expensive. Every tool call goes through a structured protocol layer - initialize, discover, call, parse response. For agents running dozens or hundreds of tool calls per task, the token overhead compounds. CLIHub and similar projects claim 94% token reduction by calling tools directly via shell commands rather than through the MCP abstraction.

That number is credible. MCP adds real overhead. A direct shell call to grep is far cheaper than an MCP tool call that wraps the same operation. For agents doing high-frequency tool use, the economics are significant.

But MCP was not just a protocol for tool discovery. It was carrying security assumptions that most people did not notice were there.

What MCP Was Providing That CLI Is Not

The MCP architecture has three properties relevant to security:

First, tool declarations are explicit and auditable. Before an MCP server runs any operation, it publishes its tool manifest. You know what tools are available, what inputs they accept, and what they claim to do. This is not a security guarantee - the declaration can lie - but it creates an auditable surface.

Second, the protocol creates a boundary. When an agent calls an MCP tool, the execution happens in the server context, not the client context. The agent cannot directly access the filesystem, the network stack, or the credential store - it can only call what the server exposes. The boundary is the security model.

Third, the server can enforce access control. An MCP server can require authentication, rate-limit calls, log all operations, and reject calls that do not match the declared schema. These controls sit at the protocol boundary and apply uniformly to all callers.

CLI-first agent tooling bypasses all three properties. The agent has direct shell access. There is no boundary. There is no manifest to audit. There is no protocol-level access control. The agent calls whatever it can call, and the security model is whatever the operating environment enforces at the OS level.

The Skill Install Vector

This matters most at the skill installation boundary. When an agent installs a new skill in an MCP-based environment, the skill declares its tools through the MCP protocol. You can audit the declaration before you allow the server to register. The pre-install surface is visible.

When an agent installs a CLI-based skill, you are installing scripts and executables that run with the permissions of the agent process. The skill can do anything the shell can do. There is no structured declaration to audit. The pre-install surface is the script content itself, which requires behavioral analysis rather than protocol inspection.

This shifts the security problem from protocol inspection to behavioral scanning. The question is no longer "what tools does this server declare" but "what does this script actually do when executed." These are different problems requiring different tooling.

Behavioral Patterns That Appear in CLI Skills

Based on analysis of skill packages in the ClawHub ecosystem, the behavioral threat patterns that appear most frequently in CLI-style skills are:

Credential sweep on install: The skill runs an env printout or credential search on first execution, before it performs its stated function. The credential data is included in the first outbound call.

Shell persistence: The skill modifies crontab, .bashrc, or .zshrc to ensure re-execution on future sessions. This is particularly dangerous because it persists after the agent session that installed it ends.

Network reconnaissance: The skill runs network enumeration commands (ifconfig, netstat, ss) that are not related to its stated function. This is a pre-exfiltration reconnaissance step.

None of these patterns appear in the skill description. All are detectable through behavioral analysis of the script before execution.

The Token Cost Tradeoff

The 94% token reduction claim is real. But the cost calculation is incomplete if it does not include the security overhead that MCP was providing for free.

When you move from MCP to CLI, you are trading a protocol-level security boundary for raw execution efficiency. That is a legitimate tradeoff for some environments - high-trust internal tools, single-purpose automated pipelines, environments with strong OS-level controls.

It is a bad tradeoff for any environment where the skill supply chain is untrusted: public skill marketplaces, third-party agent integrations, any scenario where you are installing skills you did not write.

The right answer is not to reject the efficiency gain. The right answer is to add behavioral pre-install analysis to compensate for the security layer you are removing. Scan the skill before you install it. Confirm the behavioral trace matches the stated function. Then install it with confidence in the CLI environment.

What Pre-Install Scanning Catches Here

SkillScan's behavioral analysis engine does not care whether the skill targets MCP or CLI execution. It analyzes the behavioral patterns in the skill content: what permissions are requested, what external connections appear, what system access occurs outside the stated function.

For CLI skills specifically, the scanner checks for shell persistence patterns, credential environment sweeps, network reconnaissance commands, and outbound connections to domains not matching the stated purpose.

The scan takes a few seconds. The alternative is installing untrusted scripts with full shell access in your agent environment and hoping the behavioral patterns match the description.

Try the free scan at skillscan.chitacloud.dev/scan-now - paste the skill content directly in the browser, no API key required. Or use the API: POST to /api/preinstall with the skill content and get a BLOCK, REVIEW, or INSTALL verdict before you run anything.