Because they can chain many tool calls from one user action, turning a simple session into a sequence of access decisions that humans cannot review in time. IAM, IGA, and PAM models built around static accounts do not see the whole chain. The control has to move to tool-call evaluation.
Why the authorization model breaks down for coding agents
AI coding agents do not behave like a single API request or a static service account. One user prompt can expand into a chain of tool invocations, file edits, shell commands, repository reads, CI actions, and external calls. That means authorization is no longer a one-time gate at session start, it becomes a sequence of runtime decisions that must be evaluated in context, as described in AI Agent Authorisation Guide.
The core IAM problem is that the user who initiated the session is not always the right security boundary for every subsequent action. The agent may touch systems the user never directly intended to reach, and the tool chain may cross privilege boundaries faster than a human reviewer can intervene. That is why the practical control point shifts from account-level permissioning to per-action authorization.
This is also why broad access models such as role-based or attribute-based access control need a runtime interpretation for agents. The decision is not just “can this identity log in?”, but “should this specific tool call proceed now, with this context, for this target resource?” That same logic applies to the supporting identity fabric described in Authorisation Models Guide.
Why static IAM, IGA, and PAM controls miss the full chain
Classic IAM and IGA processes were built around relatively stable subjects such as users, groups, roles, entitlements, joiner-mover-leaver events, and periodic review. PAM adds stronger control over privileged sessions, but it still tends to think in terms of standing access, session elevation, and human-operated workflows. Those models are necessary, but they do not naturally see a fast tool sequence as a single security event. IAM and IGA Basics is useful here because it makes the boundary clear: authorization governance must extend beyond account assignment into runtime decision-making.
In practice, the agent may assemble many individually plausible actions that become risky only when combined. A repository read, a config lookup, a secret fetch, and a deployment command may each look acceptable in isolation. The risk appears in the chain, where a tool can inherit assumptions from the previous step and amplify privilege without a human seeing the full path.
That is why a coding agent can create a control gap even when every underlying account appears correctly governed. The failure is not always “too much access on one account”, it is “too many sequential decisions made too quickly for static review to catch the emergent effect.”
What IAM teams need to control at runtime
The practical answer is to treat each tool call as an authorization event with its own policy, scope, and audit trail. For coding agents, the most important control is not just who authenticated the session, but whether the next action is consistent with the declared task, the target environment, and the minimum access needed right now. That includes task-scoped tokens, just-in-time elevation where needed, and explicit approval gates for destructive or cross-boundary actions.
This also means the team needs visibility into the action chain, not just the session outcome. If an agent can read a secret store, modify code, and trigger a pipeline, you need to know which step authorized each move and what evidence was available at the time. The operational lesson is reinforced by the NHI lifecycle perspective in NHI Lifecycle Management Guide, where visibility, rotation, and governance matter because control failures often emerge across time rather than at a single point.
For teams designing policy, the question is not whether to allow coding agents to act. It is how to ensure the agent cannot silently accumulate privilege, cross environments, or repurpose one user’s intent into a broader authority chain. The safest pattern is to make each high-impact action explicit, attributable, and revocable.
Risk and Threat Considerations
The main risk is privilege amplification: a harmless-looking prompt can turn into a multi-step execution path that reaches secrets, production systems, or infrastructure actions the user never directly asked for. If the agent can chain tools without stepwise policy checks, an attacker only needs one weak link, such as poisoned context, a malicious repository, or an over-scoped token, to turn normal automation into unauthorized execution.
Failure mechanism: A static permission model approves the session once, then fails to reassess each downstream tool invocation as the agent branches into new resources, commands, or trust zones.
Impact: The agent can exfiltrate secrets, mutate code, trigger destructive actions, or move from development workflows into production impact before a human can review the sequence.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | AI coding agents create runtime privilege drift through chained tool calls. |
| ASI02 — Tool Misuse | The problem is a tool chain that can cross intended boundaries at runtime. | |
| Recommendation — Enforce per-action authorization and least privilege for every agent tool call. Gate high-impact tools with explicit policy checks and approval. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Agent sessions depend on credentials, tokens, and their controlled use over time. |
| AC-6 — Least Privilege | The answer centers on minimizing what the agent can do at each step. | |
| AC-2 — Account Management | Static account-centric controls are part of the mismatch for agent runtime decisions. | |
| Recommendation — Manage credentials tightly and rotate any secret the agent can reach. Limit agent permissions to the minimum needed for each action. Review which accounts can trigger agent actions and remove unnecessary standing access. | ||
Practitioner Guidance
What to prioritise: Put policy enforcement at the tool boundary first, then decide which actions still need human approval. The highest-risk step is usually not login, it is the first tool call that can read secrets, write code, or invoke infrastructure.
What to verify: Confirm that every agent action is evaluated with task context, target resource, and bounded scope. If your current design only checks the initial user session, it is not sufficient for autonomous coding workflows.
Common mistake: Treating the agent as a normal user with a larger toolbox. That framing underestimates how quickly a chain of individually valid actions can become a materially different authorization event.
Practitioner takeaway: The right control objective is not “trust the agent less”, it is “make every consequential tool call independently justify itself.”