Govern them separately, because they expose different execution patterns. CLI is usually easier to inventory, validate, and retire, while MCP can preserve state across multiple actions and therefore needs tighter session controls. Access reviews should include interface type, exposed tools, and how state is retained or discarded.
Why This Matters for Security Teams
When CLI and MCP both exist, the risk is not just “more access” but different kinds of access. CLI sessions are usually discrete and easier to log, while MCP sessions can keep context alive across multiple tool calls, which makes state retention, privilege chaining, and unintended reuse much harder to spot. That is why agent governance should distinguish interface type, not just account or role. Current guidance from the OWASP Top 10 for Agentic Applications 2026 and CSA MAESTRO agentic AI threat modeling framework is that autonomous workloads need controls that reflect how they actually act, not how humans expect them to behave.
For NHI governance, that means separate inventory, separate review cadence, and separate revocation paths for CLI-driven automation versus MCP-backed agents. It also means tying tool access to the minimum context needed for the current task, rather than giving an agent a standing entitlement because it “might need it later.” The control objective is not just authentication, but limiting what the agent can do once authenticated. In practice, many security teams discover overbroad agent access only after an agent has already chained tools or reused retained context outside the intended workflow.
How It Works in Practice
Start by treating CLI and MCP as two governance surfaces. For CLI, focus on discrete execution: who can launch it, what commands it can invoke, and whether secrets are injected at runtime or stored locally. For MCP, add session-level controls: tool allowlists, request-scoped authorisation, context boundaries, and explicit rules for what state may persist between actions. The best practice is evolving toward intent-based authorisation, where the decision is made at runtime based on what the agent is trying to do, not just on a static role.
This is where JIT credential provisioning becomes important. Instead of long-lived secrets, issue short-lived credentials per task and revoke them automatically on completion. That reduces the blast radius if an agent behaves unexpectedly, which is especially relevant given that Analysis of Claude Code Security and the OWASP NHI Top 10 both emphasise that agentic systems fail when identity, tool scope, and secret handling are blurred together. NIST frames this as a governance problem as much as a technical one in the NIST AI Risk Management Framework.
- Use workload identity for the agent, not shared human credentials.
- Issue ephemeral tokens or certificates with tight TTLs for each task or session.
- Separate CLI command approval from MCP tool approval and session persistence rules.
- Log tool invocation, retained state, and privilege changes as distinct events.
- Revoke access when the task ends, not at the end of the day.
For MCP specifically, review exposed tools as if they were production APIs: each tool should have its own purpose, data boundary, and failure mode. For CLI, retire unused commands quickly and block any path that can silently escalate into broader system control. These controls tend to break down in long-running agent workflows with shared context stores because state reuse makes it difficult to prove which action was authorised and which was merely convenient.
Common Variations and Edge Cases
Tighter control often increases operational overhead, requiring organisations to balance faster agent execution against stronger containment. That tradeoff is unavoidable in mixed CLI and MCP environments, especially where teams want both developer velocity and persistent agent memory. There is no universal standard for this yet, but current guidance suggests keeping the two surfaces separate unless the business case for convergence is explicit and well documented.
One common edge case is a CLI wrapper that silently calls MCP tools underneath. In that pattern, the visible interface looks simple, but the actual behaviour is stateful and much riskier. Another is a shared MCP server used by multiple agents, where one agent inherits context created by another. Those cases should be treated as multi-tenant systems, with explicit workload identity, per-agent scoping, and policy evaluation at request time. The OWASP Non-Human Identity Top 10 and Ultimate Guide to NHIs both reinforce that standing privilege is the wrong default for autonomous systems.
Where agents handle sensitive operations, teams should prefer Zero Trust Architecture, short-lived trust, and explicit revocation triggers. For highly regulated environments, separate approval workflows may be needed for CLI and MCP even when they are used by the same model or application. That distinction matters most when the agent can retain memory, chain tools, or pivot between environments, because those are the situations where static RBAC stops reflecting actual risk.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A3 | Addresses agent tool misuse and uncontrolled actions across interfaces. |
| CSA MAESTRO | M1 | Focuses on agent threat modeling, including stateful tool chains and sessions. |
| NIST AI RMF | Supports governance of autonomous AI behaviour, accountability, and risk treatment. |
Define owner, policy, and monitoring for each agent workflow before granting access.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
