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.
At a glance
What this is: Kong’s analysis contrasts CLI-based and MCP-based agent workflows and concludes that enterprise use cases need delegated authorization, centralized controls, and audit trails that shell-first patterns do not natively supply.
Why it matters: It matters because IAM teams cannot govern AI agents with developer-local approvals alone when those agents act on behalf of multiple users, across shared infrastructure, and at machine speed.
Context
CLI-first agent workflows work well when a single developer controls the tools, credentials, and execution context. The governance problem appears when AI agents begin operating across teams, on behalf of multiple users, and inside shared production environments.
This article is about the control gap between local command execution and enterprise delegation. The key question is not which interface is more convenient, but which model can express scoped authorization, centralized policy, and auditable use of enterprise resources.
For IAM, NHI, and platform teams, the issue is whether access is tied to a stable human operator or to a delegated, machine-speed workflow that needs explicit identity, policy, and logging boundaries.
Key questions
A: Enterprises should separate delegation from authority. An agent may gather context, use tools, and carry work across steps, but each action still needs explicit identity, policy, and evidence boundaries. Put model access, tool access, approval points, and downstream business rules under separate controls so the system can act only within a clearly defined operating envelope.
Q: Why do CLI-based agent approvals fail at enterprise scale?
A: CLI approvals fail because they assume slow, human-paced decisions and individually managed permissions. Once agents operate at machine speed, users approve too much, forget context, or create inconsistent local rules. The result is weak oversight and no reliable central view of what agents can do.
Q: What are the signs that an agent workflow needs centralized access control?
A: Look for shared production access, multiple users relying on one agent, manual token swapping, and approvals that live on individual laptops. Those signals show the workflow has outgrown local command approval and now needs governed delegation, consistent policy, and centralized logging.
Q: How do governance needs differ between CLI workflows and MCP-based workflows?
A: CLI workflows are best when one user controls a narrow, local task. MCP-based workflows become necessary when the agent must authenticate per user, use typed tool contracts, and produce a structured audit trail across the enterprise. The difference is not convenience, but governability.
Technical breakdown
Why CLI workflows break at enterprise delegation boundaries
A CLI agent inherits the credentials and context of the current user, which is workable when one person is operating on their own data. Once the agent must act for many users, per-request delegation becomes a custom token-management problem: swapping credentials, refreshing scopes, and enforcing boundaries in application code. That shifts governance out of the protocol and into every implementation. The result is not just more code, but more ways for scope and accountability to drift.
Practical implication: treat per-user delegation as a protocol requirement, not an application-specific add-on.
Why machine-speed approval loops do not scale
CLI agents often depend on human-in-the-loop command approval, but that model assumes slow, deliberate execution. Enterprise agents operate much faster, which creates approval fatigue and encourages auto-approval, especially when the same person is asked to review many routine actions. That reduces the value of the control while leaving the platform team blind to what agents can do. Central policy enforcement matters because the approval point moves from the user prompt to the execution boundary.
Practical implication: move authorization decisions out of ad hoc developer prompts and into centrally enforced policy.
Why structured schemas and logs matter for governance
MCP adds typed tool schemas and structured telemetry, which changes how an agent interacts with enterprise services. Schemas define parameter types and required fields before execution, reducing malformed calls and making error handling consistent. Central logging then turns each action into an auditable event with actor, tool, time, and parameters. For governance, that is the difference between shell history and a controllable access record. It also creates the evidence trail needed for investigation, metering, and review.
Practical implication: require structured tool definitions and execution logs wherever agents touch shared enterprise systems.
Threat narrative
Attacker objective: The objective is unauthorized or poorly governed action at enterprise scale, including changes to infrastructure, data access, or other sensitive workflows without reliable accountability.
- Entry begins when an AI agent uses a CLI credential or locally approved command path to reach enterprise tools on behalf of a user.
- Escalation occurs when that same pattern is stretched across teams and the agent accumulates broad or mis-scoped permissions through ad hoc token handling.
- Impact follows when machine-speed operations and weak central visibility allow production changes or sensitive actions to occur without a governed audit trail.
Breaches seen in the wild
- Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
CLI convenience is not a governance model: The CLI pattern works because it assumes a single operator, a fixed credential set, and a local execution context. That assumption fails once agents act on behalf of many users across shared enterprise resources. The implication is that teams must stop treating developer ergonomics as a proxy for enterprise identity design.
Protocol-level delegation is the real control boundary: Enterprise AI agents need explicit authorization mechanics that travel with the request, not with the machine or the developer session. When delegation is built into the protocol, policy becomes inspectable and revocable rather than implicit. That is why MCP-style governance changes the control plane, not just the tool surface.
Access review and approval cadences were designed for stable privileges: Those controls presume a privilege exists long enough to be reviewed, certified, or revoked after the fact. That assumption fails when agents acquire and discard permissions inside short-lived tasks. The implication is that governance has to move from periodic review to issuance-time control and execution-time policy.
Runtime governance gap: The article exposes a gap between observable command execution and governable enterprise action. CLI workflows give teams visibility into commands, but not into organization-wide intent, delegation, or policy consistency. Practitioners should read this as a sign that the next control layer sits between identity, policy, and tool execution.
Enterprise agent governance will converge on centralized control planes: The direction of travel is away from locally managed approvals and toward policy-enforced, auditable service boundaries for agents. That does not eliminate CLI utility for local work; it does mean enterprise teams should classify where CLI ends and governed delegation begins. The practical conclusion is to design for managed agent access, not informal command execution.
From our research library:
- 76% of organisations cite shadow AI as a definite or probable problem, up from 61% in 2025, according to HiddenLayer's 2026 AI Threat Landscape Report.
- Read next: AI Agent Identity Security Buyer's Guide
What this signals
Runtime delegation is becoming the enterprise control problem: When agents act across teams, the security question shifts from whether a command works to whether the request was authorized for that user, that scope, and that moment. Central policy and identity context have to travel with the action or governance will fragment at the edge.
Access review is losing ground to issuance-time control: Review cycles assume privilege persists long enough to be inspected, but agentic workflows compress that window. Security teams should expect more controls to move upstream into delegation, policy evaluation, and execution logging.
Shell observability is not enough for enterprise AI operations: Developers can inspect stdout and stderr, but platform teams need a complete record of who authorized which action, under what scope, and with what result. That is why structured logs and tool schemas are becoming part of the identity plane, not just the developer experience.
For practitioners
- Define delegation boundaries for every agent workflow Map which users, teams, and services an agent may act for, and require the access scope to be explicit before execution begins. Do not let local credentials become a substitute for enterprise authorization.
- Centralize policy enforcement for agent tool use Move allow, deny, and step-up decisions into a shared control point so agent behavior is governed consistently across teams rather than by local developer prompts.
- Instrument every agent action with structured audit data Capture the acting identity, tool name, parameters, result, and approval state in a central log so security teams can reconstruct what happened without relying on shell history.
- Separate local CLI convenience from enterprise access paths Allow CLI-based workflows for individual developer productivity, but route shared production access through governed delegation, revocation, and review processes.
Key takeaways
- CLI workflows can be effective for individual developers, but they do not provide a durable governance model for enterprise AI agents.
- The control gap appears when agents need delegated access, centralized policy, and auditability across multiple users and teams.
- Practical governance has to move from local approvals to protocol-level authorization and structured execution records.
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 OWASP API Security Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article centers on how agents inherit and misuse delegated access at enterprise scale. |
| Recommendation — Enforce identity-bound authorization so agent actions are scoped, logged, and revocable per request. | ||
| OWASP API Security Top 10 | API10 — Unsafe Consumption of APIs | Enterprise agents consume tool and service interfaces that need controlled, typed, and governed use. |
| Recommendation — Harden agent-facing interfaces so tool consumption stays within verified request and response boundaries. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The core issue is how enterprise permissions are assigned and enforced for AI agents. |
| Recommendation — Apply entitlement controls so agent permissions are centrally defined and consistently enforced. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust principles — Continuous verification | The article highlights the need to verify each delegated action rather than trust a local session. |
| Recommendation — Design agent access so every action is continuously verified instead of assumed from prior login state. | ||
Key terms
- Protocol-level delegation: A governance model where an agent receives permissions through the protocol that carries its requests, rather than inheriting whatever a local user session happens to allow. This matters because enterprise AI agents need revocable, scoped authority that follows the action across teams and services.
- Centralized Policy Enforcement: Centralized policy enforcement is the practice of defining credential rules once and applying them consistently across many storage systems. It does not require one physical vault. It requires one governance model for exposure, rotation, and decommissioning across all places a secret can be used.
- Unified audit trail: A single evidence stream that links identity proofing, authentication, consent, and executed actions across human and non-human actors. It matters because split logs prevent teams from reconstructing what the agent was allowed to do and what it actually did.
- Machine-speed execution: Machine-speed execution is the stage of an intrusion where automation carries out actions faster than a human team can investigate and intervene. It compresses reconnaissance, exploitation, movement, and impact into a short window, making pre-authorised response and orchestration essential.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 23, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org