Who is accountable when a coding agent makes an unsafe change?

Accountability should sit with the delegating owner of the workflow, the policy administrator who allowed the action, and the platform team that exposed the tool path. If the organisation cannot trace who authorised the task, which tools were available, and why the action was permitted, governance has failed.

Why This Matters for Security Teams

A coding agent can change source, open pull requests, touch infrastructure, and invoke downstream tools faster than a human reviewer can reliably track. That makes “who is accountable?” a governance question, not a blame question. The practical issue is whether the organisation can prove who delegated the task, what the agent was authorised to do, and which guardrails were in force at the moment of execution. NHI Management Group’s research shows the scale of the underlying identity problem: 97% of NHIs carry excessive privileges, which is exactly the kind of overreach that turns an agentic workflow into a high-impact change path. See the Ultimate Guide to NHIs — 2025 Outlook and Predictions for the broader lifecycle context.

This matters because coding agents do not operate like static service accounts. Their actions are contextual, task-driven, and often chained across multiple tools, which is why guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework emphasises governance, traceability, and human accountability. In practice, many security teams encounter unsafe agent changes only after a bad commit, a leaked secret, or an unexpected production modification has already occurred, rather than through intentional control design.

How It Works in Practice

Accountability for a coding agent should be distributed across the control plane, but assigned to named human owners. The workflow owner is accountable for delegating the task; the policy administrator is accountable for defining what the agent may do; and the platform team is accountable for exposing only the tool paths and credentials that were intended. That model aligns with the emerging consensus in agent governance: the agent executes, but people remain responsible for authorisation, oversight, and containment.

Operationally, that means every high-risk coding action should be backed by traceable evidence: task request, approval, policy decision, tool inventory, credential issuance, and audit log. A well-run program also uses short-lived credentials, scoped repository access, and real-time policy evaluation rather than broad standing access. The security objective is to make each change attributable to a specific delegation event, not to a vague standing entitlement. This is consistent with recommendations in the CSA MAESTRO agentic AI threat modeling framework and with the agent-risk patterns documented in Analysis of Claude Code Security.

• Define a named owner for each agentic workflow.
• Issue JIT credentials per task, with tight expiry and automatic revocation.
• Log the policy decision that authorised the action.
• Restrict tool access to the minimum required repository, branch, or environment.
• Preserve immutable evidence for post-change review and incident response.

These controls tend to break down in loosely governed CI/CD environments because the agent inherits broad pipeline permissions that outlive the task itself.

Common Variations and Edge Cases

Tighter agent control often increases friction for developers, requiring organisations to balance delivery speed against auditability and blast-radius reduction. That tradeoff is real, especially when coding agents are used for experimentation, pair-programming, or automated refactoring.

There is no universal standard for this yet, but current guidance suggests that accountability should shift with the level of autonomy. A low-risk assistant that drafts code may be governed like a productivity tool, while an agent that can merge code or modify infrastructure needs stronger approval, richer logging, and stricter separation of duties. The same logic applies to shared agent platforms, where one team may own the model while another owns the deployment path and another owns the secrets vault.

Edge cases matter most when the agent acts across environments. If a coding agent can read from a repo, call an issue tracker, and deploy to production, accountability cannot sit in one team alone. It must be visible across the workflow boundary. The NHIMG research on AI LLM hijack breach and Moltbook AI agent keys breach shows why tool chaining and exposed keys quickly turn a narrow task into a broader security event. The practical test is simple: if the organisation cannot reconstruct who authorised the action, what context the agent had, and why the system allowed it, the accountability model is incomplete.

Related resources from NHI Mgmt Group

• Who should be accountable when an agent makes a high-risk decision?
• Who should be accountable when an agent makes a risky tool call?
• Who is accountable when an AI agent makes the wrong change?
• Who is accountable when an AI agent makes an unauthorised change?