AI coding agent model choice is an IAM and governance decision

At a glance

What this is: This is StackHawk’s analysis of how engineers actually use AI coding agents, with the key finding that token cost is often the wrong unit of measure for choosing models.

Why it matters: It matters to IAM and security teams because AI-assisted development creates governance pressure around access, tool choice, and shadow usage, all of which affect identity, privilege, and change control.

By the numbers:

• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.
• 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%).

👉 Read StackHawk's analysis of AI coding agent model choice and engineer time

Context

AI coding agents are changing how engineering work gets done, but the real governance problem is not the model prompt or the autocomplete experience. It is the decision structure around who can use which model, under what conditions, with what visibility, and at what cost to security and delivery.

In practice, that makes this an identity and access question as much as a productivity question. If engineers can route around policy, adopt shadow AI tooling, or use different models without oversight, the organisation loses control over the identities, permissions, and actions behind the work.

The patterns StackHawk describes are typical of early-stage enterprise adoption, where tool choice is left too close to the individual engineer and too far from the governance model.

Key questions

Q: How should security teams govern AI agents that choose tools at runtime?

A: Security teams should treat runtime tool choice as a governed access event, not a normal application call. That means task-scoped credentials, explicit approval boundaries for sensitive actions, and logs that record both the tool selected and the identity used. If the agent can change its plan, the control model must be able to change with it.

Q: Why do cheaper AI coding models often create more risk than they remove?

A: Because token savings can be overwhelmed by correction time, review fatigue, and untracked workarounds. A weak model may look efficient on paper, but if it forces repeated reprompting or produces unsafe output, the organisation pays in engineer hours and control loss. Risk rises when the cheapest option becomes the default for every task.

Q: What breaks when engineers can choose AI models without oversight?

A: Accountability breaks first, then visibility, then policy enforcement. If people can switch models or use personal accounts to get better output, the organisation loses a clean audit trail for who did what, where, and under which controls. That is how shadow AI emerges inside ordinary development work.

Q: When should teams escalate from a cheap model to a stronger one?

A: Escalate when the task is security-sensitive, spans multiple files or systems, or carries a high cost of failure. The right test is not the model’s sticker price but whether repeated correction would consume more value than the stronger model would cost. That is the point where cheap becomes expensive.

Technical breakdown

Why model tiering changes the control plane for AI coding agents

AI coding agents are not just tools that generate text. They sit inside a workflow where model capability, context retention, and task scope determine whether a human can review outputs quickly or spend hours correcting them. In governance terms, the model becomes part of the control plane because it shapes how much friction the engineer encounters, how much context the agent can hold, and how often work escapes the intended process. That creates an access and oversight problem, not merely a budget problem.

Practical implication: treat model selection as a governed workflow decision, not an individual preference.

How correction spirals create hidden operational risk

A correction spiral happens when a lower-capability model completes part of a task, but the engineer must repeatedly reprompt, clarify, and fix the output. The obvious cost is lost time, but the deeper issue is that the agent has already influenced code, logic, or configuration before the human catches up. That makes review quality dependent on attention and patience rather than on a stable control boundary. For security teams, this matters because the more rounds of correction, the more opportunities there are for unsafe changes to slip through.

Practical implication: measure correction cycles and failed prompts as governance signals, not just productivity noise.

Shadow usage and AI agent identity in development workflows

When engineers route around restrictive policies to get access to a better model, the organisation creates shadow AI use. That is an identity problem because the system no longer knows which user, account, key, or context governed the action. In the same way that unmanaged service accounts create audit gaps, unmanaged agent workflows create accountability gaps. The issue is not only that work happens outside policy, but that the organisation loses the ability to attribute, review, and constrain those actions consistently.

Practical implication: bind AI coding access to named identities, approved workspaces, and auditable entitlements.

Threat narrative

Attacker objective: The objective is not classic exfiltration but ungoverned influence over engineering decisions, code changes, and delivery velocity.

1. Entry occurs when an engineer uses an AI coding agent with access that was granted outside a controlled model-selection policy.
2. Escalation happens when repeated correction cycles or shadow usage expand the agent's effective influence over code changes and task execution.
3. Impact is slower delivery, weakened oversight, and a larger surface for unsafe or unauthorised changes to reach production.

NHI Mgmt Group analysis

Model choice is now an access governance issue, not a developer preference. StackHawk's pattern analysis shows that the economic decision about which model to use directly affects who can act, how reliably work is reviewed, and whether policy can be enforced. Once engineers can change model tier outside central oversight, the organisation has created a governance gap that looks operational but behaves like privilege drift. Practitioners should treat AI coding model assignment as a controlled entitlement.

Correction spirals are a form of hidden control failure. When a weak model repeatedly needs human repair, the organisation is not just losing time. It is extending the window in which erroneous or unsafe output can propagate into code, configuration, or security-sensitive changes. That makes the real failure mode detection latency, not token spend. Teams should measure how often the agent needs rescue before they treat the workflow as trustworthy.

Shadow AI in engineering has the same audit problem as unmanaged non-human identities. If people route around policy to get a better model, the organisation loses traceability over the account, workspace, and permissions behind the work. That is an NHI-adjacent governance problem because the system action is no longer cleanly tied to an approved identity and lifecycle. Security leaders should expect agent workflows to produce the same blind spots seen in weak secrets and service account governance.

AI coding governance will converge with secure development controls. The most durable control model is not to ban stronger models or micromanage each prompt, but to align model access, code review, and approval paths with risk level. That is where standards thinking such as NIST AI Risk Management Framework and secure engineering governance start to overlap. Practitioners should expect AI agent oversight to be folded into SDLC controls, not separated from them.

What this signals

Model governance is becoming a control objective, not a usage preference. As coding agents move from experimentation into production work, the programme risk shifts from whether teams use AI to whether the organisation can govern which identities may use which models, where, and for what level of risk. That argues for explicit policy, inventory, and review paths rather than ad hoc enablement.

Correction-heavy workflows will expose hidden productivity loss before they expose security incidents. Teams that measure only token spend will miss the operational signal that matters: repeated human intervention around the agent. The better indicator is whether agent-assisted work is creating measurable review drag, which is the point where delivery and governance start to fail together.

AI coding access should be folded into IAM and secure development controls. The practical next step is to align approved model access with named users, task classes, and change-management boundaries. Where agent use is still informal, the organisation should expect shadow pathways to emerge and make the audit problem harder, not easier.

For practitioners

• Classify model access by task risk Give routine code assistance to lower-risk models only where failure cost is limited, and reserve stronger models for architecture, security-sensitive, or multi-file changes. Tie the choice to approved use cases, not individual preference.
• Track correction cycles as a governance metric Measure how many reprompts, clarifications, and manual fixes each agent-assisted task requires. High correction volume is a signal that the workflow is too costly, too brittle, or too hard to supervise safely.
• Bind AI coding sessions to named identities Require authenticated users, approved workspaces, and auditable keys or tokens for every coding agent session. That makes shadow usage visible and keeps accountability attached to the engineer and the task.
• Move model decisions into policy, not habit Define when teams can use token-free, workhorse, or frontier models, and make escalation criteria explicit for difficult or security-sensitive work. This avoids personal workarounds and keeps cost decisions at the programme level.

Key takeaways

• AI coding agents create a governance problem when model choice is left to individual engineers instead of controlled policy.
• The hidden cost is not only token spend but correction time, review fatigue, and shadow usage that weaken accountability.
• Security teams should govern agent access like an entitlement: named identities, approved workspaces, and explicit escalation rules.

Key terms

• AI Coding Agent Governance: The rules and oversight structures that define what a coding agent may do, why it may do it, and who is accountable for the outcome. It sits above security tooling and focuses on delegation, approval, auditability, and rollback rather than threat prevention alone.
• Correction Spiral: A correction spiral is the pattern where an AI system produces incomplete or flawed output, and the human must repeatedly reprompt, clarify, or fix it. The risk is not only lost time. It also increases the chance that unsafe or inconsistent output makes it further into the delivery process.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.

What's in the full article

StackHawk's full blog covers the operational detail this post intentionally leaves for the source:

• A task-by-task breakdown of when engineers should stay on a cheaper model versus escalate to a stronger one
• The specific workflow patterns the author observed when teams corrected agent output in real engineering work
• The practical cost framing used to compare token spend with engineer time and delivery impact
• The source post's examples of how teams handled model choice across routine and security-sensitive work

👉 The full StackHawk post covers the observed workflow patterns, correction spirals, and cost trade-offs in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and identity lifecycle control. It gives practitioners a practical way to connect access oversight to the broader security programme.