MCP vs CLI for agents: why security changes the answer

At a glance

What this is: This is a comparison of CLI tools, agent Skills, and MCP for AI agent workflows, with the key finding that credential location and governance, not token cost alone, should determine the architecture.

Why it matters: IAM, PAM, and NHI teams need this distinction because the wrong tool boundary can turn a convenient agent workflow into a shared-credential or un-auditable access model.

By the numbers:

• A Scalekit benchmark found CLI costs approximately $3.20 per 10,000 operations for GitHub tasks, versus $55.20 for MCP, a 17x difference.
• Five MCP servers with 20 tools each can inject approximately 80,000 tokens of schema before any task begins.
• Stacklok says on-demand tool discovery can reduce per-request token consumption by 60% to 85% compared with eager loading.

👉 Read Stacklok's comparison of MCP, Skills, and CLI for AI agent workflows

Context

MCP, CLI tools, and agent Skills are often treated as interchangeable ways to let an AI agent work with software, but they solve different problems. The security question is not whether an agent can run a command; it is where the credentials live, who can revoke them, and whether the resulting access is attributable in a multi-user environment.

That distinction matters for NHI governance because the credential boundary changes completely when an agent acts for one developer versus for many users or customers. In the former case, inheriting the user’s session may be acceptable; in the latter, shared credentials, over-broad service accounts, and weak auditability become the real failure modes.

Key questions

Q: What breaks when an AI agent uses CLI tools in a multi-user enterprise workflow?

A: The credential model breaks first. A CLI-backed agent typically inherits the launching user’s session, which is workable for one developer but weak for shared or regulated environments. Once multiple people depend on the same workflow, attribution, revocation, and least privilege become hard to prove or enforce.

Q: Why do MCP-based agent workflows matter for NHI governance?

A: MCP keeps downstream credentials server-side instead of placing them in the agent’s execution environment. That creates a cleaner trust boundary, better auditability, and more practical per-user delegation, which are core requirements when agents operate across teams or production systems.

Q: What do security teams get wrong about agent tool access?

A: They often treat tool connectivity as a simple integration problem. In practice, every API, SaaS connector, and MCP server expands the agent's reachable action set, so each tool must be authorised separately and limited to the minimum actions needed for the approved workflow.

Q: How should organisations decide between CLI and MCP for agent automation?

A: Use CLI when the agent is acting as a single developer and the credentials are intentionally that person’s own. Use MCP when the workflow is shared, customer-facing, or production-bound, because the ability to scope, log, and revoke access becomes more important than raw token efficiency.

Technical breakdown

CLI agents inherit the user’s credential surface

A CLI-based agent executes shell commands in the same environment as the user or pipeline that launched it. That means secrets can sit in environment variables, config files, shell history, or process memory, and the agent may also send command outputs containing sensitive data to the model context. This is workable when the agent truly acts as one person, but it collapses when the workflow crosses a user boundary.

Practical implication: Treat every CLI-backed agent workflow as credential inheritance unless you can prove the permissions are intentionally single-user and revocable.

MCP centralises downstream credentials behind a protocol boundary

MCP changes the access pattern by moving downstream credentials into the MCP server rather than the agent host. The agent calls typed tools, the server authenticates to the target system, and the credential never appears in the agent’s context window or execution environment. That server-side separation is the architectural reason enterprises prefer MCP when a workflow needs auditability, scoped delegation, and shared service access.

Practical implication: Use MCP when the access path must be mediated, logged, and independently revoked from the agent runtime.

Agent Skills govern procedure, not access

Agent Skills are structured instructions for how to perform a task, what to check first, and how to respond to failure. They reduce ambiguity in the workflow layer, but they do not provide system access and they do not solve the credential problem by themselves. A Skills-driven agent still needs either CLI or MCP beneath it, which means the security posture is determined by the tool layer, not the skill document.

Practical implication: Do not treat Skills as a control for access governance; evaluate them separately from the credential-bearing execution path.

NHI Mgmt Group analysis

Credential location, not token count, is the real architectural control point. The Stacklok comparison is useful because it shows why performance debates often hide governance risk. CLI can be cheaper in tokens, but the credential surface moves into the agent execution environment, which changes the access model rather than merely optimising it.

Multi-user delegation is where CLI-based agent governance breaks down. A developer acting for themselves can accept inherited credentials, but an enterprise agent acting for employees or customers needs per-user attribution and revocation. Once the workflow crosses that boundary, shared credentials and ad hoc injection logic become governance liabilities rather than implementation details.

Agent Skills reduce procedural drift, but they do not shrink privilege exposure. Skills may improve consistency in how an agent works, yet the access question remains in the underlying tool layer. That means enterprises should separate workflow standardisation from identity and secret placement, because one does not solve the other.

The right comparison is not CLI versus MCP in the abstract, but trust boundary versus convenience boundary. Token efficiency matters, but it is secondary when the workflow touches production systems, regulated data, or shared identities. Practitioners should evaluate which part of the stack owns the credential, which part can revoke it, and which part can prove who used it.

From our research:

• With 70% of organisations already granting AI systems more access than human employees, the governance gap is structural, not hypothetical, according to the 2026 Infrastructure Identity Survey.
• Only 44% of organisations have implemented policies to govern AI agents, according to AI Agents: The New Attack Surface report.
• For a broader control lens, OWASP Agentic Applications Top 10 is the most useful next step for mapping agent identity and tool misuse risk.

What this signals

Credential placement will become the deciding factor in AI agent governance. As more workflows move from developer convenience to enterprise delegation, the practical question will be who owns the secret, who can revoke it, and whether the access path is independently auditable. That is why the distinction between CLI inheritance and protocol-mediated access will keep widening in importance.

Token optimisation is no longer a sufficient design criterion. If a platform lowers cost but leaves secrets inside the agent runtime, it has improved efficiency while preserving the wrong trust model. Security teams should evaluate the control boundary first and the token bill second, especially where OWASP Agentic AI Top 10 style risks include tool misuse and identity abuse.

For practitioners

• Map the credential boundary for every agent workflow Document where each credential lives, whether it is inherited from a user session, stored in a local host, or held server-side behind MCP. If a workflow crosses from one person to many people, treat that as a governance change, not just an implementation choice.
• Separate single-user automation from shared-access automation Allow CLI-backed workflows only where the agent is acting as one named user and the blast radius is intentionally bounded. Move shared, delegated, or customer-facing workflows to a mediated access pattern with per-user attribution and revocation.
• Require auditability at the tool layer Verify that every sensitive tool invocation can be tied to the human or service identity that authorised it, including the parameters used and the downstream system reached. If you cannot reconstruct that path, the workflow is not ready for regulated or shared use.
• Evaluate Skills separately from access control Use Skills to standardise procedure, but do not let them substitute for secrets management, least privilege, or revocation logic. Review the underlying tool path first, then decide whether CLI or MCP is the safer execution layer.

Key takeaways

• The core issue in CLI versus MCP is governance, not just efficiency, because credential location determines the real attack surface.
• Multi-user and regulated deployments need per-user attribution, server-side credential separation, and revocation that CLI-based inheritance cannot reliably provide.
• Skills can standardise agent behaviour, but only the tool layer decides whether access is safely bounded, auditable, and revocable.

Key terms

• MCP: Model Context Protocol, an open way for AI agents to connect to tools and data sources. It improves interoperability, but it also introduces a shared integration layer that must be governed carefully because the protocol can widen access across many systems at once.
• Credential Surface: The credential surface is the set of places where secrets, tokens, keys, or session material can be exposed, copied, or reused during execution. For agents, that includes environment variables, local files, logs, memory, and any service that proxies access on the agent's behalf.
• Agent Skill: A reusable package of task-specific knowledge and procedures that an autonomous agent can load when needed. In practice, it separates general awareness from operational detail, which makes enterprise context easier to govern than a single oversized prompt.

What's in the full article

Stacklok's full article covers the operational detail this post intentionally leaves for the source:

• A deeper side-by-side breakdown of CLI, Skills, and MCP deployment patterns for developer and enterprise workflows
• Examples of how per-user OAuth and server-side credential storage change audit and revocation handling
• A more detailed decision matrix for choosing between CLI, MCP, and hybrid patterns in production
• Specific token-cost comparisons and benchmark context for schema loading and tool discovery

👉 Stacklok's full post covers the credential model, audit trail, and token-efficiency trade-offs in more detail

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.