TL;DR: CLI-based agent workflows work well for individual developers, but enterprise AI agents need protocol-level delegation, policy enforcement, and auditability that CLIs do not provide, especially as access must be scoped across teams and machine-speed operations, according to Kong. Access review processes assume stable privileges and human-paced approval loops; autonomous workflows collapse those assumptions in practice.
NHIMG editorial — based on content published by Kong: The Incessant AI Death Knell, on CLI and MCP governance tradeoffs for enterprise AI agents
Questions worth separating out
Q: How should security teams govern AI agents that act on behalf of multiple users?
A: They should treat the agent as a delegated identity with explicit per-request scope, revocation, and logging.
Q: Why do CLI-based agent workflows become risky at enterprise scale?
A: They become risky because the controls are local, fragmented, and hard to audit across teams.
Q: When does MCP provide a better governance model than CLI for AI agents?
A: MCP is the better governance model when an agent needs delegated access, structured audit data, and centrally enforced policy across multiple systems or users.
Practitioner guidance
- Separate local developer automation from governed enterprise agent access Classify CLI-based agent use cases as personal productivity unless the agent must act for multiple users, teams, or production systems.
- Define per-request delegation boundaries for shared agents Require scoped authorisation for each user and each task when an agent acts on behalf of others.
- Centralise policy enforcement and audit trails before rollout Use a shared gateway or control layer to enforce command-level policy, record structured audit events, and require confirmation for sensitive actions.
What's in the full article
Kong's full blog post covers the architectural detail this post intentionally leaves for the source:
- CLI versus MCP tradeoffs for tool selection accuracy, context bloat, and developer workflow design
- Protocol-level delegation patterns using OAuth 2.1 and enterprise-managed authorisation
- Observability and policy enforcement differences between local prompts and a shared control layer
- Typed schema and runtime error handling examples for enterprise tool execution
👉 Read Kong's analysis of CLI versus MCP tradeoffs for enterprise AI agents →
CLI vs MCP for AI agents: where do enterprise controls break down?
Explore further
CLI-only agent governance is a local convenience pattern, not an enterprise control model. The article is right to separate individual developer workflows from org-wide agent operations. CLI approvals, shell history, and personal tokens can be workable when one person is acting on their own behalf, but they do not create a durable governance plane for delegated access across business units. For NHI and IAM teams, the practitioner conclusion is simple: local control mechanisms do not become enterprise governance just because an agent is using them.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to SailPoint's research.
A question worth separating out:
Q: What should IAM teams evaluate before allowing shared AI agent access?
A: They should evaluate whether the access path can be scoped per user, revoked centrally, and audited in a structured way. If any of those are missing, the organisation will struggle to prove what the agent did, who it acted for, and whether the access remained appropriate.
👉 Read our full editorial: CLI vs MCP for enterprise AI agents: the real governance tradeoffs