Autonomous Hackbots Are Here and Agent-Layer Visibility Is the Answer

In a writeup published July 1, 2026, two security researchers described something that should reset how every security team thinks about autonomous agents. Over roughly five months, a two-person team built and ran an autonomous 'hackbot' for bug bounty. It was not a lab demo. According to their account, it found 126 vulnerabilities, about 70 percent of them rated high or critical, and reported findings included a full platform takeover, a major money-transfer API exposing large amounts of personal data, stored cross-site scripting that enabled crypto-wallet theft, and multiple critical IDORs.

The headline is easy to read as an offensive story. The more important read is defensive. The hackbot was assembled from ordinary coding-agent tooling, the same category of tool a developer installs to move faster. That means this capability is not rare or exotic. It is cheap, widely available, and already inside most engineering organizations - which is exactly why the agent layer has become the new shadow IT.

What a two-person team just built

The architecture the researchers described is worth reading closely, because every piece of it maps to something a defender needs to account for. All figures below are as reported in their July 2026 writeup, attributed to a July 2026 writeup by two security researchers.

• Cloud-based orchestration coordinating specialized skills: server-side fuzzing, client-side analysis, IDOR testing, and subdomain enumeration.
• A separate validation and adversarial agent whose job was to disprove each finding before it counted, so the system argued against itself rather than trusting its own output.
• Continuous, persistent investigation loops - the researchers called them 'ralph loops' - in which a promising finding triggered deeper analysis instead of ending the run.
• A real physical computer running a real browser to handle logins and bypass anti-bot defenses that block headless browsers coming from datacenter IP ranges.
• Full session logging. They streamed entire agent sessions for observability, and named 'always keep logs' as a key operational lesson.

The researchers' own conclusion was blunt: automation lets a tiny team reach production-scale offensive capability, greatly widening who can find critical vulnerabilities. That is the part defenders should sit with.

The same tooling is already inside your organization

There is no proprietary dependency in that architecture. The building blocks are coding agents, orchestration, and a browser. If two people can point them outward at a bug-bounty program and reach that kind of coverage, the same class of agent is trivially easy to run inward, at your own codebase, your internal APIs, or a staging environment. The uncomfortable truth is that this is not a hypothetical future capability creeping toward your perimeter. It is a tool your developers and security engineers can already install today, and many have.

An autonomous agent with network reach and code execution is a powerful thing regardless of who is holding it. The offense and defense distinction is about intent, not architecture. A red-team hackbot, an internal scanning agent, and a developer's everyday coding agent share the same shape: they run unattended, they reach the network, and they execute code and call tools on the endpoint. We have written about how thin that boundary is in Securing AI Coding Agents and CLIs, and about how agentic tooling reshapes the software supply chain in AI Supply Chain Attacks: A Defender's Guide.

The governance problem is not that these agents are malicious. It is that most organizations cannot produce a list of the ones already running. You cannot govern what you cannot see, and an autonomous agent that nobody registered is the definition of an unmanaged asset.

Their best practice is your security requirement

The single most useful operational habit in the researchers' telling was not a clever exploit technique. It was discipline: always keep logs, stream every session. When an autonomous agent runs thousands of actions without a human watching each one, the session log is the only way to understand what it did, reproduce a finding, and trust the result. For an operator, that is observability. For anyone governing agents inside an organization, the same requirement has a different name.

'Always keep logs' is offensive tradecraft and defensive policy at the same time. You cannot govern an autonomous agent you did not record.

If an autonomous agent runs on an employee's laptop, you need a durable, queryable record of what it read, what it called, and what left the machine. Without one, an incident is unreconstructable: you know something happened, but not what, not when, and not how far it reached. That record is the foundation of both baseline behavior and after-the-fact investigation, which is why we treat it as non-negotiable in Runtime Monitoring and Anomaly Detection for AI Agents and in the AI Agent Incident Response Playbook. The researchers reached this conclusion from the offensive side. Defenders should adopt it as policy.

Offensive or defensive, an agent is still an agent

It is tempting to file a hackbot under 'security tooling' and assume it lives outside normal governance. That instinct is exactly backwards. A security agent is an agent too, subject to the same failure modes, the same runaway autonomy, and the same need for guardrails as anything else running on your fleet - a point we make in full in Autonomous Security Agents Are Agents Too.

This is not confined to closed commercial tools. The open-source research community is building the same capability in the open, which puts autonomous vulnerability research into everyone's hands and makes governance rails - not just enthusiasm - the responsible path. We cover the open-source cousin of this work in Open Kritt: Governing Agentic Vulnerability Research.

And when one of these agents behaves unexpectedly, the response is an agent-layer problem, not a traditional endpoint one. Containing an agent means knowing which one it is, what it can still call, and how to cut that off fast, as we walk through in The OpenAI and Hugging Face Incident: Containing an Agent. An agent that combines access to sensitive data, exposure to untrusted input, and a path to send data out is the lethal trifecta in the flesh, which we detail in The Lethal Trifecta in Production. A hackbot with network reach and code execution has all three legs by design.

How Anomity makes the agent layer visible

Anomity is defensive. It does not scan or attack anything; it governs the AI agents and MCP servers running inside your own organization. The whole point is to turn the shadow layer that a hackbot lives in into something you can inventory, govern, and audit.

• Inventory the agents you did not know you had. An unprivileged Endpoint Sensor for Windows, macOS, and Linux inventories eight AI artifact types - AI agents, MCP servers, extensions, plugins, skills, secrets, hooks, and CLIs - so a scanning agent, a coding agent, or a homegrown hackbot shows up whether or not anyone registered it. See Fleet visibility.
• Govern the call before it runs. At an agent hook, such as the Claude Code PreToolUse hook, Anomity can allow, deny, or log an action before it executes, so a risky command is a policy decision rather than a line in a post-incident log. See Runtime governance.
• Keep the record the researchers demanded. A queryable 90-day audit trail preserves what each governed agent did, with metadata-only capture and on-endpoint secret redaction so the record itself does not become a new liability. See Outcomes and the docs.
• Route findings where your team already works. Alerts and events flow to SIEM, Slack, email, and Jira, and Anomity is SOC 2 Type II. It complements your Network, EDR, DLP, and GRC controls rather than replacing them. See how it compares.

The hackbot writeup is a preview of a world where autonomous agents with real reach are cheap enough that they are everywhere, including inside your own walls. The researchers told you the control that matters: know they exist, and keep the logs. If you want that visibility across your fleet, request early access.