Most production agents still have a human nearby. Good.

“Autonomous” has become one of those words that can mean almost anything. An agent that drafts an email gets the label. So does one that sends the email, changes a firewall rule or moves money. Those are not variations of the same security problem.

When I look at an agent workflow, I want to know how far it can travel before something outside the model can stop it. Sometimes that something is a person. Sometimes it is policy. If the honest answer is “we will notice in the logs,” the agent already has too much room.

The human did not disappear

There is no single, reliable number for agent autonomy in production. The surveys use different definitions and ask different groups. I would not combine them. I do think the pattern is worth reading.

A May 2026 Stack Overflow survey found that 63% of respondents rarely or never let agents run entirely on autopilot. Sixty percent blocked unapproved system changes. In a separate Zapier survey, human-in-the-loop was the most common management model.

Actual product use makes the story more interesting. Anthropic looked at millions of Claude Code and API interactions. Experienced users turned on full auto-approve more often than new users. They also interrupted the agent more often.

That last detail matters. Experience did not remove the human. It moved the human from approving each step to watching the trajectory and intervening when necessary. Less clicking, more judgment.

The four modes I use

I use four labels when I review these systems. They are not a ladder, and “full autonomy” is not the prize at the top. A sensible product can use all four. Reading a public document and wiring funds should not inherit the same authority because both actions happen in one interface.

Human-in-the-loop. The agent prepares an action and waits. Here, the approval screen carries a lot of weight. It must show the actual tool, identity, destination, arguments and expected effect. “Allow” is not enough.

I have seen approval flows where the visible request and the executed request were only loosely connected. That is not a gate. The approval has to bind to the exact action that runs.

Human-on-the-loop. The agent is already moving. The person watches and can intervene. This sounds simple until the agent performs ten actions in the time it takes an operator to understand the first three.

A stop button has to stop something. The operator also needs to know what will be left behind: an open transaction, a partially changed record, a credential already copied somewhere else. Otherwise “supervision” is just a live incident report.

Bounded autonomy. This is the mode I trust most for consequential production work today. The agent moves without asking each time, but software enforces the limits.

Those limits have to inspect more than the tool name. Identity, tenant, resource, arguments and side effects all matter. So does provenance. A skill, MCP server or configuration change can alter the path without any change to the model.

Full autonomy. No person participates in the normal path. The phrase still hides a lot of human work: somebody defined the goal, issued the credentials, chose the tools and wrote the policy.

What disappears is the opportunity to catch a bad decision in real time. Recovery must already exist. Task-scoped credentials, budgets, circuit breakers, idempotency and rollback are the security model, not cleanup work for a later sprint.

What JADEPUFFER tells us

JADEPUFFER is a useful case because it shows the speed of machine execution. It is also easy to overstate. Sysdig reported that the agent chained reconnaissance, credential harvesting, lateral movement and destructive database extortion after entering a vulnerable Langflow deployment.

It did not choose the victim or build the whole operation by itself. Sysdig later clarified that a person selected the target, prepared command-and-control and staging infrastructure, and supplied credentials from an earlier compromise.

I do not find that reassuring. A relatively small amount of human direction started a long, adaptive sequence. Human-on-the-loop controls have to keep pace with that sequence. Bounded autonomy should prevent some steps outright, no matter how persuasive the model's reasoning looks.

A practical review

Do not assign one autonomy level to the product. Assign it to each consequential action. Then ask:

  • Which identity does the agent present to each tool, and how is that identity tied to the user and task?
  • Which policies run before execution, and which signals are only reviewed afterward?
  • How quickly can a person or automated circuit breaker interrupt the sequence?
  • What state remains after interruption, and can the system roll it back or resume safely?
  • What happens when a model, skill, MCP server or tool definition changes without a policy review?

If those questions do not have concrete answers, reduce the authority. That is not a lack of ambition. It is how a team earns the right to automate more later.

Autonomy is not a feature flag. It is a security boundary.

Sources

Sources and incident status reviewed on July 21, 2026.