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.
Why This Matters for Security Teams
When an AI agent is allowed to run CLI tools inside a shared workflow, the problem is no longer just “who can execute commands.” It becomes “whose identity is the agent borrowing, how far can that session spread, and who can prove what happened afterward?” That is why a CLI-backed agent can look harmless in a single-user developer setup and still become an enterprise control failure in regulated or multi-user environments. Guidance from the OWASP Agentic AI Top 10 and NHI research such as OWASP NHI Top 10 both point to the same issue: autonomous execution collapses the assumptions behind static access and simple attribution.
In practice, the risk is not only command abuse. CLI tools often expose cloud credentials, local config files, shells, package managers, and deployment paths in one trust boundary. Once the agent can chain those tools together, least privilege becomes difficult to state, much less enforce. In the real world, teams usually discover this only after a shared automation path has already performed an action no one can cleanly attribute, revoke, or roll back.
How It Works in Practice
A CLI agent usually inherits the launching user’s session, environment variables, and filesystem context. That is acceptable when one engineer controls the workflow, but it breaks down when the same automation is used by multiple operators, service accounts, or teams. The agent is no longer just “running commands.” It is effectively acting with delegated authority, often without a separate workload identity or an auditable decision point for each tool invocation.
Current guidance suggests treating the agent as an autonomous workload, not a human proxy. That means using workload identity, short-lived credentials, and request-time policy checks rather than one persistent shell session. NIST’s NIST AI Risk Management Framework and the CSA MAESTRO agentic AI threat modeling framework both support this shift toward runtime governance. In practice, security teams should separate:
- human approval of intent from machine execution of commands
- user identity from agent workload identity
- session-based convenience from task-based authorization
- long-lived secrets from JIT credentials with tight TTLs
That architecture also improves attribution. If an agent needs to read a repo, deploy a package, or call a cloud CLI, the system can issue an ephemeral token scoped to that task and revoke it when the task ends. NHIMG’s analysis of Analysis of Claude Code Security and related research on agent tool abuse show why command execution has to be treated as a governed capability, not a shared shell convenience. These controls tend to break down when legacy scripts assume an interactive human session and cannot tolerate per-task identity, short TTLs, or policy evaluation at every command boundary.
Common Variations and Edge Cases
Tighter command control often increases operational overhead, so organisations have to balance speed against auditability, especially in developer-heavy environments where CLI workflows are deeply embedded. There is no universal standard for this yet, but best practice is evolving toward context-aware authorization and ephemeral delegation rather than blanket shell access.
One edge case is the “multi-user service shell,” where several people trigger the same agent through a shared automation account. That pattern can hide ownership entirely unless the workflow preserves user intent separately from execution identity. Another is break-glass access, where administrators need broad CLI control during incidents. Those sessions can be justified, but they should be rare, time-bound, and heavily logged. The same applies to CI/CD runners that invoke agents: if the runner has access to secrets or deployment authority, the agent can inherit privileges far beyond what any one user intended.
Recent NHIMG research, including the LLMjacking: How Attackers Hijack AI Using Compromised NHIs report and the AI Agents: The New Attack Surface report, underscores the same operational lesson: once AI can act through a CLI, exposed credentials, inherited sessions, and weak auditability become attack paths, not just hygiene issues. The practical answer is to design for per-task identity, revocation, and policy checks before the agent ever reaches the shell.
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, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF 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 | A1 | CLI agents inherit broad tool access and can execute unsafe chained actions. |
| CSA MAESTRO | TA-1 | MAESTRO addresses agent threat modeling and runtime control boundaries. |
| NIST AI RMF | AI RMF supports governance, accountability, and risk treatment for agentic systems. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | Inherited sessions and static credentials create NHI exposure in shared workflows. |
| NIST Zero Trust (SP 800-207) | PR.AC-4 | Zero trust requires continuous, context-based authorization for each tool call. |
Restrict agent tool execution with per-command policy and least-privilege scopes.
Related resources from NHI Mgmt Group
- What breaks when AI agent access is inherited directly from the user who triggered the workflow?
- What is the difference between human identity governance and AI agent governance?
- When does AI agent access create more risk than it reduces?
- What is the difference between governing human access and governing AI agent access?
