Who is accountable when a coding agent leaks secrets or makes an unsafe tool call?

Why This Matters for Security Teams

When a coding agent leaks secrets or issues an unsafe tool call, the failure is not just a prompt problem. It is an access governance problem, a telemetry problem, and often an ownership problem. The agent can only act within the permissions, tool paths, and data exposure that a team has granted. That means accountability should follow the operating model, not the gateway brand or the LLM vendor. Guidance from the NIST AI Risk Management Framework is clear that AI risks need governance, measurement, and continuous management across the full lifecycle.

Security teams often miss the fact that “unsafe tool use” is rarely a single control failure. It can involve weak secret scoping, broad repository access, poor approval logic, or missing audit trails that prevent reconstruction of the action chain. For agentic systems, the practical question is who can constrain behavior before a token is exposed or a command is executed. That makes the owner of the agent’s non-human identity, policy, and logs the most defensible point of accountability, especially when the agent has write access or can trigger external systems. In practice, many security teams encounter this only after a credential leak or unintended action has already created blast radius, rather than through intentional control design.

How It Works in Practice

Accountability is usually assigned through control ownership, not by a single technical component. The team operating the coding agent should own the non-human identity, the secret store integration, the tool allowlist, and the detection logic around tool execution. The gateway can enforce policy, but it does not define acceptable risk on its own. That distinction matters because agent workflows often span IDE plugins, code repositories, ticketing systems, CI/CD, and cloud APIs.

A mature operating model normally separates duties across several layers:

• Secret issuance and rotation are controlled by the platform or identity team.
• Tool permissions are limited to the smallest viable set of read and write actions.
• Every high-risk action is logged with user, agent, tool, and context metadata.
• Policy violations trigger alerting, quarantine, or step-up approval before execution.
• Ownership for investigation and remediation is assigned to the service team that deployed the agent.

This is where agentic AI guidance overlaps with identity governance. If the coding agent can authenticate as a non-human identity, then secret handling and privilege scope should be treated as first-class identity controls. The OWASP Non-Human Identity Top 10 is useful here because it frames credential sprawl, over-privilege, and weak lifecycle controls as operational risks rather than abstract policy issues. For higher-risk agent workflows, security teams should also cross-check tool behavior against attack patterns described in the MITRE ATLAS adversarial AI threat matrix and the OWASP Agentic AI Top 10.

These controls tend to break down when the agent is embedded in developer tooling with broad inherited access and no separate audit path, because policy decisions become invisible inside normal user workflows.

Common Variations and Edge Cases

Tighter agent approval controls often increase developer friction and platform overhead, so organisations have to balance speed against blast-radius reduction. There is no universal standard for exactly where accountability should sit in every environment, but current guidance suggests that any team allowing an agent to see secrets or invoke tools must own the resulting risk decisions end to end.

Edge cases usually appear when several teams share the same agent stack. In that model, the platform team may run the gateway, the application team may define tool use, and the security team may own monitoring. That split can work, but only if ownership for the non-human identity, policy exceptions, and incident response is written down. Without that, blame shifts to the most visible control, even when the real failure was permissive scope or missing telemetry.

Another common variation involves sandboxed agents used in development versus production-connected agents. Development systems may tolerate broader experimentation, but once an agent can touch production repositories, cloud accounts, or release pipelines, the accountability model should tighten immediately. The Anthropic report on the first AI-orchestrated cyber espionage campaign report is a reminder that autonomous tooling can be operationalised quickly once permissions are sufficient. In mature environments, accountability follows the team that can revoke access, investigate execution, and prove policy enforcement, not the system component that merely forwarded the request.

Related resources from NHI Mgmt Group

• Who should be accountable when an agent makes a risky tool call?
• Who is accountable when a coding agent makes an unsafe change?
• Who is accountable when an AI agent makes a destructive tool call?
• Who is accountable when an exposed AI agent gateway leaks secrets and chat history?