Who should own coding agent risk, AppSec or IAM?

Both, because the problem spans application workflow and identity governance. AppSec owns the runtime guardrails and detection points, while IAM owns the credential scope, lifecycle, and trust boundary. The article makes clear that coding agents cannot be safely managed by either team in isolation.

Why This Matters for Security Teams

coding agent sit at the junction of source code, secrets, build systems, and production-facing tools, so ownership cannot live neatly inside one control plane. AppSec is closest to prompt injection, insecure code generation, output review, and runtime guardrails. IAM is closest to credential scope, trust boundaries, approval flows, and revocation. The risk grows because agents act with execution authority, not just advisory output, which makes weak boundaries much more consequential than in a standard developer workflow. NHIMG research on agentic risk and the OWASP NHI Top 10 shows why this is now a governance issue, not a tooling debate.

The practical mistake is assuming the question is either AppSec or IAM. In reality, coding agents need both application guardrails and identity discipline because their behavior changes by task, context, and tool access. Current guidance from OWASP Agentic AI Top 10 and NIST AI Risk Management Framework points in the same direction: governance must follow the agent’s runtime behavior, not just its assigned role. In practice, many security teams encounter this only after a coding agent has already been granted broad repo or cloud access and has begun using it in ways no human reviewer anticipated.

How It Works in Practice

The cleanest operating model is shared ownership with a hard split in responsibilities. AppSec should own the agent’s safe-use guardrails: prompt filtering, code review checkpoints, policy enforcement on generated changes, sandboxing, and detection of suspicious tool calls. IAM should own the identity primitive: who or what the agent is, what it can reach, how credentials are issued, how long they live, and how quickly they are revoked. For coding agents, that usually means workload identity rather than a long-lived shared secret, with just-in-time access granted per task and constrained to the minimum repository, package registry, CI job, or cloud scope needed for that action.

This is where runtime policy matters more than static RBAC. A coding agent does not have one stable access pattern, so pre-defined group membership often over-grants or blocks legitimate work. Best practice is evolving toward context-aware authorization, where policy is evaluated at request time using the task, the repository, the environment, and the request origin. Frameworks such as CSA MAESTRO agentic AI threat modeling framework and MITRE ATLAS adversarial AI threat matrix are useful here because they both emphasize attack paths that cross identity and application boundaries.

NHIMG’s coverage of the Amazon Q AI Coding Agent Compromised incident shows why this matters operationally: if an agent can be steered into destructive actions, the issue is not just unsafe code output, but unsafe authority. A useful operating pattern is: AppSec defines what actions are allowed inside the developer workflow, IAM defines what identities may exercise those actions, and both teams review the policy boundary together. These controls tend to break down in monorepos, delegated CI/CD systems, and multi-agent pipelines because tool chaining makes privilege paths hard to predict.

Common Variations and Edge Cases

Tighter control often increases delivery friction, requiring organisations to balance developer velocity against containment. That tradeoff is especially visible in high-trust engineering environments where agents need broad read access but only narrow write or deploy rights. Current guidance suggests separating read-only analysis agents from write-capable coding agents, because the latter introduce materially higher blast radius. Where the answer gets messy is in hybrid setups: an agent may draft code in one environment, open pull requests in another, and trigger deployment workflows through a third system.

There is no universal standard for this yet, but the direction is clear: use ephemeral credentials, explicit approval points for privileged actions, and revocation on task completion. For teams assessing real-world exposure, NHIMG’s State of Secrets in AppSec is a reminder that secret sprawl and delayed remediation remain common failure modes, and the 2024 ESG Report: Managing Non-Human Identities shows how often compromised NHIs translate into repeated incidents. A practical exception is offline or air-gapped build systems, where IAM may appear simpler, but AppSec still has to control code provenance and output validation. The model fails when teams assume a coding agent is “just another developer,” because the agent’s tool access can amplify one bad decision into immediate cross-system impact.

Related resources from NHI Mgmt Group

• Why do AI agents increase non-human identity risk in existing IAM programmes?
• When does AI agent access create more risk than it reduces?
• When do AI agent credentials create more risk than they reduce?
• Why do AI agents create more IAM risk than ordinary developer tools?