Who Is Accountable When an AI Agent Acts Without Approval?

Two Things Happened in the Same Week

On August 9, 2026, Anthropic announced that auto mode would become the default permission setting in Claude Code for Pro, Max, and Team plan subscribers, effective August 14. The agent would no longer pause for human approval at each step. A classifier trained to detect dangerous commands would handle that review automatically. Anthropic's own testing showed the classifier caught 89 percent of deliberately dangerous commands, compared to 13.6 percent caught by human reviewers. To put that in concrete terms: in a simulated set of 100 dangerous commands, a human reviewer stopped roughly 14 while the classifier stopped 89. The numbers make a reasonable case for the change.

At almost exactly the same moment, Black Hat USA 2026 was generating a different kind of headline. The security research community had arrived at a consensus cutting across nearly every session on AI: agentic AI systems are the most consequential new attack surface most organizations have introduced in years. As one post-conference analysis put it, the shift from "prompt injection as a curiosity" to "agent exploitation as a discipline" is complete. Agentic systems are now a governance problem, not just an AI research topic.

Two developments, same week, pointing in opposite directions. And that gap is the story.

The Anthropic classifier data is real, and the rationale for reducing friction in developer workflows is sound. The concern here is narrower and more actionable: autonomy is workable when identity and audit keep pace. For most organizations right now, they do not.

The Burden Just Shifted to You

Before August 14, auto mode in Claude Code was opt-in. A developer who wanted the agent to run without per-step approval had to make a deliberate choice to enable it. After August 14, the burden inverted. Now an organization must actively configure restrictions or opt out to prevent unsupervised execution. That is not a subtle distinction. It is the difference between a controlled deployment and an uncontrolled one.

Security teams and compliance officers who have not yet defined what guardrails they require are now operating behind the default, not ahead of it. Coding agents are already running in developer environments across regulated commercial firms, and the governance data strongly suggests the same pattern is taking hold in state agencies and school districts: when only 22 percent of organizations govern agents as distinct identities, the absence of a formal approval path is the norm rather than the exception. The default change means those agents, if operating on affected Claude Code plans, are now running in auto mode whether or not anyone in the security function is aware of it.

This is not an Anthropic-specific dynamic. OpenAI's ChatGPT agent mode and GitHub Copilot's cloud agent both extend autonomous action into developer workflows with varying degrees of human-in-the-loop control. The direction across the platform landscape is consistent: less friction, more autonomy. That serves developers well. It creates a governance gap for everyone else.

Why Agents Break Every Security Model You Already Have

AI agents do not fit cleanly into any governance category that enterprise security programs were built to handle, and that mismatch is what makes them a genuinely new risk surface.

Think of it this way: a traditional service account is like a vending machine. It takes a specific input, performs one defined action, and stops. An AI agent is more like a contractor with a master key. It receives a goal, decides how to achieve it, accesses whatever systems its credentials allow along the way, and keeps working until the task is done or something stops it. That contractor can touch your code repository, your cloud storage, your external APIs, and your deployment pipeline in a single session. No single action necessarily triggers an alert, because each step looks like routine system behavior; the risk accumulates across the sequence, not within any individual call.

An agent has the behavioral profile of a user: it makes decisions and adapts to context. It has the persistence of a system: it runs continuously and maintains state across sessions. And it carries the access privileges of a service account. User access controls assume a human making decisions. Service account controls assume deterministic, scripted behavior. An agent is both simultaneously; no existing governance framework accounts for that combination cleanly.

CISA and five allied national cybersecurity agencies made this precise point in their May 2026 joint guidance on agentic AI, the first coordinated Five Eyes advisory specifically targeting autonomous AI systems. The guidance identifies three properties that invalidate traditional security assumptions: autonomy, statefulness, and tool access. The Cloud Security Alliance's research on the non-human identity governance vacuum establishes the lifecycle dimension: AI agent identities should be subject to the same disciplines applied to human user accounts. According to Palo Alto Networks' 2026 Identity Security Landscape Report, a vendor survey of 2,930 cybersecurity leaders, organizations now manage an average of 109 machine identities for every human identity. That figure covers all machine identities, a category that includes AI agents alongside service accounts, API keys, and certificates, not AI agents exclusively. For a 500-person organization, that ratio implies roughly 55,000 machine identities requiring governance attention across all of those categories. That figure is not a threat in itself. It is a measurement of how far governance has fallen behind deployment.

The ACM Workshop on Artificial Intelligence and Security has noted that current cybersecurity paradigms are too brittle to address vulnerabilities stemming from dynamic generative agents. The OWASP GenAI Security Project formalizes this in its Top 10 for Agentic Applications, identifying Excessive Agency as the leading risk category for autonomous AI systems. Black Hat 2026 reflected that maturation: researchers presented multi-stage agent exploitation chains, not proof-of-concept demonstrations.

The Audit Trail Problem Is an Accountability Problem

A translucent digital key dissolving into streams of code against a dark background, symbolizing credential inheritance and loss of accountability

Of all the governance gaps that agent autonomy creates, the credential inheritance problem hits regulated and public sector organizations first.

When a developer's Claude Code session runs under their own GitHub token or AWS credentials, every action the agent takes is attributed to that person in the audit log. When the agent writes a file, pushes a commit, or calls an external API, the log entry says the employee did it. The employee may not have known the agent was going to take that specific action. The log does not distinguish. For regulated organizations, that is an accountability failure before it is a security failure.

To make this concrete: imagine a state agency auditor reviewing an incident six months after the fact. They pull the access log and see that a specific employee's credentials accessed a sensitive database, modified a configuration file, and pushed code to a production branch, all within a four-minute window on a Tuesday afternoon. Was that the employee acting deliberately? Was it a coding agent the employee had running in the background? The log cannot tell them. Under most public records and audit requirements, that ambiguity is not acceptable.

The credential inheritance problem is solvable, but only if the agent has its own identity to inherit from. The Cloud Security Alliance is direct on this point: the absence of agent-specific identity governance creates compliance blind spots that auditors are increasingly equipped to identify. Federal agencies are already responding, consolidating Identity Governance and Administration, Privileged Access Management, and AI identity controls into unified platforms because the attribution gap has become a compliance issue.

Controls You Can Implement in the Next Quarter

The controls required to govern agents safely are extensions of IAM and zero trust disciplines that most organizations have already started. What is missing is the deliberate decision to extend them to non-human actors. Each of the five controls described here maps directly to existing IAM work, not a new program requiring new budget.

The first and most foundational is a distinct identity per agent. Each agent instance should have its own credential set, not the developer's personal credentials and not a shared service account. Think of it as the difference between issuing a contractor a building-access badge tied to their name versus handing them a master key with no record of who holds it or where it has been used. NIST SP 800-207 already requires equal treatment of non-human identities in zero trust design, and IEEE peer-reviewed research demonstrates that SPIFFE-based workload identity provides a practical alternative to API keys for agent frameworks, reducing attack surface through automatic credential lifecycle management.

The second is scoped and time-bound credentials. Agents should receive credentials that expire when the task completes, not standing access that persists indefinitely. A credential that lives for the duration of a single pull-request review, roughly 20 minutes, is categorically less risky than one that persists for weeks under a shared service account. The IETF draft on AI agent authentication and authorization establishes that OAuth 2.0 provides the mechanism for delegated, bounded access, and CISA's Five Eyes guidance specifically emphasizes tightly scoped data access as a top control for agentic AI. The Cloud Security Alliance's Agent Identity Governance Framework maps these IETF extensions to enterprise deployment patterns.

The third is least privilege by task rather than by role. An agent writing unit tests does not need production database access. An agent reviewing pull requests does not need deployment credentials. The operative principle is scoping to the task the agent is performing right now, not to the role of the human who invoked it. The CISA Zero Trust Maturity Model's identity pillar applies directly here.

The fourth is logging at the tool-call level. Standard application logs capture inputs and outputs. Agent governance requires a record of every tool invocation, every API call, and every file operation the agent performs, attributed to the agent's own identity. AWS's guidance on secure agent access patterns through the Model Context Protocol addresses this directly: combining tool restriction with IAM controls closes the gap between the agent access path and the direct access path.

The fifth is a defined and tested revocation path. If an agent behaves unexpectedly, there must be a documented, exercised procedure for terminating its access. NHIMG and IDSA best practices identify revocation path documentation as a baseline governance requirement, and the federal FICAM framework provides the institutional scaffolding for agencies implementing this at scale.

Your AI Policy Was Written for a Different Kind of AI

Most AI use policies in state and local government, education, and regulated commercial organizations were drafted in 2023 or 2024, when the dominant concern was generative AI producing inaccurate or inappropriate content. Those policies govern what an AI system can say. They do not govern what an AI system can do.

An AI assistant that drafts a response and waits for a human to click "send" is categorically different from an agent that executes a sequence of file operations, API calls, and code commits without pausing. The first creates a recommendation. The second creates facts on the ground. Policies written for the former do not govern the latter.

NASCIO's 2026 state CIO priorities survey ranked AI, GenAI, and agentic AI as the number one priority among state technology leaders, with governance and policies explicitly cited as the primary framing challenge. The National Association of State Boards of Education noted that with more than 30 states having AI guidance documents in place, the focus in 2026 is shifting toward evolution and implementation of those frameworks. A policy revision needs to answer concrete questions: Does it distinguish between AI that advises and AI that acts? Does it specify which external systems an agent is permitted to connect to? Does it define what a human is considered to have authorized when they invoke an agent? Does it require a distinct identity and audit trail for agent actions? The Cloud Security Alliance's NIST AI RMF Agentic Profile provides a governance framework that extends existing risk management disciplines to autonomous systems, including structured extensions for tool-use risk and delegation chain accountability.

This Is a Cybersecurity and Cloud Problem, Not an AI Problem

The governance gap described in this article is not a problem that the AI team owns, or that the developer team owns, or that the tool vendor will close for you. It sits at the intersection of three domains that most organizations have historically treated as separate: cybersecurity, cloud identity architecture, and AI adoption.

The cybersecurity team understands the threat model and the audit requirements. The cloud identity team owns the IAM infrastructure that needs to extend to non-human actors. The AI advisory function understands how agents are actually being used and what controls are operationally feasible without breaking developer workflows. When those three functions are siloed, the result is what Okta's 2026 AI Agents at Work survey, a vendor survey by Okta, an identity and access management provider, found: 88 percent of respondents reported a confirmed or suspected AI agent security incident, while only 22 percent govern agents as distinct identities. The Cloud Security Alliance's research note on the AI agent IAM framework enterprise gap corroborates that finding, identifying the absence of agent-specific identity governance as the defining security gap of the current agentic AI era. The gap between those two numbers is the governance deficit in quantified form. Note that both figures are drawn from Okta's own vendor survey and have not been independently corroborated by a third-party source.

At Spruce, we work at exactly this intersection, bringing cybersecurity services, cloud identity architecture, and AI advisory together because the problem genuinely requires all three. When those functions are connected, agent governance becomes an extension of work already underway. When they are not, it becomes a gap that incidents eventually find.

The controls required to govern agents safely are largely extensions of work that most organizations have already started. The question is whether the teams doing that work are connected to the teams deploying agents. If your organization has developer teams using coding agents and your AI policy or IAM architecture has not been updated to account for autonomous action, that is the gap to close first. The defaults have already changed.

Sources

Back to Blog

Who Is Accountable When an AI Agent Acts Without Approval?

Two Things Happened in the Same Week

The Burden Just Shifted to You

Why Agents Break Every Security Model You Already Have

The Audit Trail Problem Is an Accountability Problem

Controls You Can Implement in the Next Quarter

Your AI Policy Was Written for a Different Kind of AI

This Is a Cybersecurity and Cloud Problem, Not an AI Problem

Sources

More articles

Want our take on your AI roadmap?

Related services from Spruce

Cybersecurity Services

AI Advisory

AI Solutions Development