Should organisations use CLI instead of MCP for some workflows?

Yes, when the tool is already well understood, the workflow is narrow, and the environment is tightly controlled. CLI can reduce context overhead and simplify execution, but it should not be used to bypass identity, audit, or policy controls that matter in enterprise settings.

Why This Matters for Security Teams

Choosing CLI over MCP is not just a tooling preference. It changes how authority is conveyed, how commands are inspected, and how much execution path can be mediated by policy. In tightly controlled workflows, CLI can be the simpler and safer option because the task is narrow and the operator already understands the exact command surface. The risk is assuming that “simpler” also means “less governed.”

That assumption fails quickly when teams use CLI to avoid identity checks, audit logging, or approval gates that MCP would otherwise make visible. The issue is especially acute in agentic environments, where autonomous systems can chain actions, reuse tokens, or expand scope unexpectedly. NHIMG’s analysis of Analysis of Claude Code Security and the broader OWASP Agentic Applications Top 10 both show that execution convenience becomes a security gap when tool access is not tightly bounded. In practice, many security teams encounter over-privileged command execution only after a workflow has already been reused in a less controlled environment.

How It Works in Practice

CLI is often appropriate when the workflow is deterministic, the operator is trusted, and the environment is tightly scoped. In those cases, a direct command can be easier to validate than an abstraction layer. MCP, by contrast, is better suited when tool discovery, structured context, and policy mediation matter, especially for AI agents that may invoke tools dynamically. The key question is not “which is newer,” but “which path preserves the control points that matter for this workflow.”

For security teams, the practical decision usually comes down to identity, logging, and permission scoping. A CLI can still be acceptable if it is wrapped in the same enterprise controls you would expect from any privileged toolchain: workload identity, short-lived credentials, command allowlisting, and full audit capture. If the workflow is part of an autonomous agent pipeline, current guidance suggests treating the agent as a workload with explicit runtime authorisation rather than assuming a human-like approval model. That aligns with the direction of the OWASP Agentic AI Top 10, where tool misuse and excessive agency are central risks, and with Gemini CLI Breach – Silent Code Execution, which illustrates how command surfaces can be abused when execution trust is too broad.

• Use CLI for narrow, repeatable tasks with known inputs and fixed outputs.
• Use MCP when the workflow needs structured tool governance, context passing, or policy checks.
• Keep identity separate from convenience: every execution path should map to a real workload identity.
• Prefer short-lived tokens and per-task authorisation over shared static credentials.

These controls tend to break down when CLI is introduced into multi-step agent workflows because the command boundary becomes invisible once the agent starts chaining tools.

Common Variations and Edge Cases

Tighter command control often increases operational overhead, requiring organisations to balance developer speed against governance depth. That tradeoff is real in CI/CD, incident response, and local automation, where CLI may be the only practical option. Best practice is evolving, but the current consensus is that CLI should not be treated as a governance shortcut; it is simply a different execution interface.

One edge case is highly regulated environments where an MCP layer adds too much latency or complexity for a one-step administrative task. Another is a local sandbox where the command is low risk and no sensitive secrets are in scope. Even there, the baseline should include logging, identity binding, and least privilege. The most common failure mode is not the tool itself, but the assumption that a manual command is inherently safer than a mediated protocol. That assumption has been challenged repeatedly in agentic systems, including the risks documented in AI Agents: The New Attack Surface report and the OWASP community guidance on OWASP Top 10 for Agentic Applications 2026. The right choice is the one that preserves auditability and bounds execution, not the one that looks simplest on paper.

Related resources from NHI Mgmt Group

• How should organisations decide between CLI and MCP for agent automation?
• How should teams govern AI agents that use MCP?
• When should organisations use AI to help manage NHIs?
• How can organisations govern AI agents that use service accounts and tokens?