Autonomous AI Agents: What Changes When Agents Act Without Step-by-Step Human Approval

By Tahir Mahmood, Co-founder & CTO, OpenBox · Last updated 6 November 2026

In brief: Anthropic’s September 2026 threat report describes a range of AI autonomy in cyber operations, from chat assistance to workflows that ran with minimal human supervision, and it says autonomy and harm are separate axes. For enterprise teams, an agent that acts without asking can shift the main control point from reviewing outcomes to deciding before an action runs. OpenBox, an AI agent governance platform, builds that decision into its Trust Lifecycle: Assess, Authorize, Monitor, Verify, and Adapt (per OpenBox docs).

What is the shift from AI assistant to AI orchestrator?

An assistant answers when asked. An orchestrator takes a goal, breaks it into steps, and runs those steps itself, often through several cooperating agents. In its September 2026 threat report, Anthropic titles its cyber operations findings “From assistant to orchestrator.” It reports that a majority of the operations it describes were enabled by AI through direct execution or orchestration, and says this use went beyond chatbot questions and answers to include multi-agent frameworks executing reconnaissance, exploitation, and data exfiltration.

Anthropic also reports that humans remained in the loop by setting targets and reviewing exfiltration. The report describes its cases as examples of the most notable and novel activity Anthropic identified, not typical misuse. These findings therefore describe the cases Anthropic chose to publish. They do not measure how common this activity is.

This article reads those findings as a prompt for enterprise teams. It separates what Anthropic reports from what we infer, and it uses the OpenBox Trust Lifecycle to show where a governance decision can sit in an agent’s loop. For the broader foundation, see our guide to AI agent governance.

What does Anthropic’s report show about autonomous AI in cyber operations?

The report covers operations that Anthropic’s Threat Intelligence team disrupted between December 2025 and August 2026. Anthropic refers to the actors as Generative Threat Groups (GTGs), its internal designators for actors observed abusing AI. Everything below is Anthropic’s reported investigation and attribution. We have not independently reproduced it.

The report describes a range of autonomy rather than a single pattern:

Source: Anthropic, September 2026 report, p. 39. Wording condensed.

Two cases show what unattended execution looked like in practice. For GTG-10007, Anthropic describes a fleet of thirteen standing collection AI agents running on a scheduled job to identify and download content from target websites (report p. 27). For GTG-20006, which Anthropic describes as a state-nexus espionage operator, the report describes an AI-assisted workflow that automatically rebuilt and re-deployed the actor’s toolkit if security products detected it (report pp. 5-6). Its monitoring agents were designed to keep iterating on the toolkit until it went undetected, at which point the tools were staged for live operations (report p. 6).

Unattended execution of one workflow is not the same as an unattended campaign. In the same passage, Anthropic says humans retained the decisions that matter most to them and remained heavily involved in target selection, monetization of findings, and review of results. For agents that run for long stretches, see our post Your agent ran two hours. Who was watching?.

Does more autonomy mean more harm?

Not by itself. Anthropic treats autonomy and harm as “separate axes”: autonomy multiplied the scale and speed of an operation and reduced operating costs and complexity, while severity was still determined by many other factors. The report adds that several of the most serious compromises it describes came from operations where a human directed every step (report p. 39).

On the cost side, Anthropic says autonomy lowers the skill threshold and the labor required per campaign while leaving potential payoffs largely unchanged. That makes previously marginal targets viable and encourages higher-volume, lower-touch operations. The report’s own summary cites breaches completed in two to three hours and dozens of victims handled in parallel by individual operators. It also says none of the operations depended on an entirely novel technique: the attacks were familiar, and the economics changed.

Why does this matter for enterprise AI agents?

This section is our reasoning, not a finding in Anthropic’s report. The report’s stated scope is operations in which threat actors tried to use Claude for malicious activity, not enterprise AI deployments.

The reasoning starts from where a person can intervene. With a conversational assistant, a person can see each response before anything else happens. With an orchestrated workflow, a person may see a result only after several steps have run. If an enterprise agent can take consequential actions, such as exporting data, moving money, or changing a schema, without step-by-step approval, then a review that happens after the action completes can describe what occurred. It does not change the outcome of an action that already ran.

Anthropic’s separation of autonomy from harm fits this reasoning. If autonomy multiplies the scale and speed of what an agent does, the permissions and controls around the agent shape how much harm that speed can produce. An agent confined to narrow permissions and an agent with broad ones can run at the same pace and carry very different risk. OpenBox has written about how an agent can breach a system without an attacker by chaining approved actions, and a documented case of how an AI agent granted itself permissions.

None of this suggests that an enterprise agent behaves like the actors in the report. It suggests that any system able to act without asking raises a design question: where does a person or a policy get a say before the action runs? OpenBox’s 4 November article, Why Blocking Bad AI Prompts Fails on Dual-Use Actions, draws on a different section of the same Anthropic report.

How is runtime governance different from after-the-fact observability?

In OpenBox’s framing, observability shows what agents have already done, while governance determines what agents are allowed to do before actions execute. Governance Starts Where Monitoring Ends sets out that distinction. Logging Is Not AI Governance covers the logging side, and Why AI Agents Need Runtime Monitoring makes the case for runtime monitoring over after-the-fact log review.

The OpenBox Trust Lifecycle is the model behind that distinction. Per OpenBox (docs.openbox.ai), it has five phases, and each does a different job:

The Authorize phase combines guardrails, policies (written in OPA/Rego), and behavioral rules to evaluate agent operations. These layers address different kinds of risk. Guardrails validate or transform data, policies perform stateless permission checks on a single operation, and behavioral rules detect multi-step patterns across a session.

Anthropic’s far-end cases involved multi-agent work running in parallel for hours or days. A policy that checks one operation at a time sees one step. A behavioral rule is designed to look across the steps of a session, per the docs. For multi-agent setups specifically, see Authorization Propagation in Multi-Agent AI Systems and Govern the Handoffs Between Your AI Agents.

When OpenBox evaluates an agent operation, it returns one of five governance decisions. OpenBox states that each decision executes before the tool call or model request reaches its target.

Precedence: HALT, BLOCK, REQUIRE_APPROVAL, CONSTRAIN, ALLOW. A stricter verdict overrides a looser one.

For the approval flow and the conditions that can trigger HALT, see the Governance Decisions docs. For how human approval is meant to work in practice, see Human-in-the-Loop AI, Explained the Right Way.

Monitor and Verify do different work. Per the docs, Monitor gives visibility into runtime behavior, while Verify supports review of a selected session, including drift events and execution evidence. That evidence includes a session hash (a Merkle root), an OpenBox signature, and an RFC 3161 timestamp, and Session Replay lets a reviewer step through a session. See also Attestation & Cryptographic Proof.

OpenBox also maps an agent-level Trust Score to trust tiers, with stricter controls at lower tiers. The docs describe Tier 4 as strict governance with human-in-the-loop review required. Trust Is a Runtime Governance Decision covers how scores adapt as behavior changes.

Two limits apply. First, runtime enforcement covers operations the governance layer mediates. As OpenBox notes in its 4 November article, an operation an agent can reach by an ungoverned route sits outside the policy. Second, cryptographic attestation supports the integrity of the recorded evidence. It is not, by itself, evidence that an agent’s outputs were correct.

What should CISOs and platform teams ask before agents act without asking?

These questions turn the discussion above into a review checklist:

1. What can each agent do without a person approving the step, and who decided that boundary? Our post on structural controls for enterprise agentic AI is a starting point.

2. What happens when an operation violates or approaches a policy boundary: is it allowed, constrained, paused for approval, blocked, or does the entire session halt?

3. Who receives a paused request, and what happens if no one responds before the timeout? Per the docs, a timed-out approval request expires.

4. Can your controls recognize a multi-step pattern across a session, not only a single operation?

5. Is the record of what happened cryptographically verifiable, or only a log? See AI Governance Needs Proof, Not Logs.

6. Which execution paths sit outside the governance layer?

For a rollout view, see the 90-day CISO playbook and What Are Consequential Events in AI Agents?.

Frequently asked questions

Does Anthropic’s report describe fully autonomous AI attackers?

Not as a blanket description. The report describes a range, from conversational assistance to operations that ran with minimal human input or supervision. It also says humans retained the decisions that matter most to them, such as target selection, monetization of findings, and review of results. Some individual workflows, such as a scheduled collection fleet, ran with no human in the loop, according to Anthropic.

Does the report cover enterprise AI agents?

No. The report’s stated scope is operations in which threat actors tried to use Claude for malicious activity. Any connection to enterprise agent governance in this article is our own reasoning.

What is the difference between monitoring and runtime enforcement?

According to OpenBox docs, the Monitor phase provides visibility into agent runtime behavior, while the Authorize phase defines what an agent is allowed to perform and produces governance decisions. In short, monitoring shows what is happening, and enforcement acts on operations as the governance layer evaluates them.

Which governance decisions does OpenBox return?

OpenBox returns one of five governance decisions when it evaluates an agent operation: ALLOW, CONSTRAIN, REQUIRE_APPROVAL, BLOCK, or HALT. Precedence runs HALT, BLOCK, REQUIRE_APPROVAL, CONSTRAIN, ALLOW, so a stricter verdict overrides a looser one, according to OpenBox’s October and November 2026 publications.

What happens when an operation returns REQUIRE_APPROVAL?

Per OpenBox docs, the operation pauses for human review. If a reviewer approves it, the operation proceeds. If the reviewer rejects it, the operation is blocked. If the request times out, the operation expires.

Does runtime governance cover every action an agent can take?

No. It applies to operations the governance layer mediates. As OpenBox notes in a 4 November 2026 article, an operation an agent can reach by an ungoverned route sits outside the policy.