Inside the AI Operator

An AI agent runs an intrusion as a loop. It maps the target, tests thousands of variants, writes down what worked and what failed, and turns every lesson into a reusable skill for the next target. The agent’s own notes are the best evidence of this, and in late 2026 several operators exposed theirs.

Profero Threat Intelligence analyzed the working files of six independent operators who used AI agents against real organizations. Across them we found thousands of agent skills, hundreds of per-target case files and more than 250 named target organizations in at least nine countries. This post explains how these operations run, technique by technique, and where defenders can catch them. It leaves out every victim. Network indicators for one of the operators are listed at the end.

Figure 1. One human steers; the agent runs on rented infrastructure, works from its skill library and case notes, and distills each lesson back into its skills.

Key findings

• The agent does the work, the human steers. Agent activity spans nearly every hour of the day. Human interventions are a small minority of actions and cluster in one time zone.
• Skills compound across victims. Each engagement ends with the agent distilling new skills. One operator’s library held several thousand skills, about two thirds of them offensive security. Only about one in eight had a counterpart in the other collections we examined, so most of the tradecraft is self-generated.
• Engagements are long and wide, not fast and deep. One recorded engagement ran for two days over more than 20 rounds, logged over a hundred findings and dozens of explicitly abandoned attack paths, and tested thousands of request variants.
• Recon is the main product. For most targets the agent took no data. It left behind a precise map of subdomains, identity tenants, API endpoints and the controls that stopped it.
• Basic controls held. Rate limits, network-level bans, multi-factor authentication (MFA), account lockout and server-side authorization checks ended many of the attack paths in the case files.
• The genre is barely reported. Most public reporting on AI-agent operators has found their data on exposed servers and open directories. HackersEye’s analysis of one of these operators is the only prior public report we found on operators leaking their agents’ own knowledge bases; the other five operators in this research have not been reported.

What an AI operator looks like

The six operators used two architectures. Five ran the same popular open-source agent framework; one ran a custom agent built on large language model APIs and tool-calling. The components were the same in every case:

The library is the asset. The operator does not need to know how to attack an identity provider or a .NET web service; the agent loads a skill that already encodes what worked and failed last time.

The engagement loop

Every case file we reviewed followed the same cycle. The agent repeats it in numbered rounds until it runs out of hypotheses or the operator stops it.

Figure 2. Each round runs map, hypothesize, test, record and distill around the skill library, until the hypotheses run out or the operator stops it.

1. Map: passive and active reconnaissance builds the target model: subdomains from certificate logs, technology fingerprints, API routes and the identity platforms in use.
2. Hypothesize: the agent ranks attack paths using its skill library and what worked against similar targets.
3. Test at scale: it generates and sends hundreds to thousands of variants per hypothesis, pacing and rotating source addresses to avoid bans.
4. Record: it writes every finding, every negative result and the reason it was abandoned. Negative results matter to the agent: one operator’s notes list dozens of “excluded paths” for a single target.
5. Distill: at the end of the engagement the agent writes a retrospective and updates its skills. One retrospective concluded that starting with identity reconnaissance would have cut a two-day engagement by more than half. That lesson became a rule for the next target.

Step five is what makes agent-run operations different. A human red team carries lessons in its head. An agent writes them into files that every future run, and every copy of the library, inherits.

Techniques by phase

The table maps what we observed to MITRE ATT&CK. It describes technique families, not procedures.

Two patterns stand out. First, the agent attacks identity before infrastructure: mapping tenants, federated providers and MFA state is cheap, quiet and tells it where to spend effort. Second, supply chains beat hardened perimeters: the largest data access we saw came through a third-party SaaS platform shared by several organizations, not through any target’s own systems.

Figure 3. Technique families seen across six operators, mapped to MITRE ATT&CK, with the signal each phase leaves for defenders.

Tradecraft and its failures

The operators treated their agents as junior staff with perfect memory. That memory is also their biggest operational security failure.

The agent documents everything. Case files named targets, endpoints, the controls that stopped the agent and the data it claimed to reach, because the agent’s skills told it to keep that record.

Redaction failed whenever the operators delegated it to the agent. They asked their agents to scrub sensitive details before sharing. The agents removed passwords and the operators’ own server addresses, then left target names, findings and record counts in place. In every case the removed values survived in earlier versions.

Cleanup came too late. Operators rewrote history, deleted their material and re-published it several times, but copies made before each cleanup kept the original text, and those copies spread within hours.

The clock gave them away too. Agent runtime timestamps ran around the clock in UTC, while the rare human actions carried the operator’s local time zone.

What stopped them

The case files are as useful for what failed as for what worked. These controls repeatedly ended an attack path:

• Network-level bans on hosting and proxy address ranges stopped an enumeration campaign outright, despite proxy rotation.
• MFA and account lockout turned password-spray results into dead ends. Agents explicitly hunt for the accounts where these are missing.
• Hardened backends behind a well-tuned WAF absorbed thousands of variants without a usable finding.
• Server-side authorization checks decided the outcome. Where they were missing, the operator claimed thousands of records from a single IDOR. Where they were present, the agent gave up.

Detection opportunities

Agent-run operations are noisy in specific ways. Look for these patterns rather than single indicators.

• Variant bursts: hundreds of near-identical requests to one endpoint with small parameter changes, often across several source IPs inside minutes.
• Datacenter and residential rotation: a single session fingerprint (headers, TLS client, request cadence) moving across many hosting and residential IPs.
• Unauthenticated identity probing: spikes of account-existence checks and password-grant attempts against your cloud identity tenant, especially single attempts per account spread over time.
• Bundle scraping: repeated full downloads of large JavaScript bundles and source maps from non-browser clients.
• Staging and UAT access: external hits on hosts that only appear in certificate logs.
• Third-party exposure: cross-tenant access patterns at SaaS providers that hold your data. Ask them what they log.

Recommendations

1. Review what certificate logs, JavaScript bundles and sign-in flows reveal about you, and remove what an agent would harvest first. Assume someone has already written it down.
2. Enforce MFA and lockout on every cloud account, including service, legacy and administrator accounts. Agents filter for the exceptions.
3. Move secrets out of client code. Treat every key in a production bundle as published.
4. Test authorization as well as authentication on every API, including partners’ and SaaS providers’ APIs that hold your data.
5. Rate-limit and ban by network type. Hosting-provider and known proxy ranges should face stricter limits on sign-in and API endpoints.
6. Hunt for the patterns above in WAF, CDN and identity logs, and keep those logs long enough to see a multi-day campaign.

Why this matters now

Skill libraries travel. Within hours of one operator publishing, dozens of copies existed under other accounts, so every technique an agent learned against one target became available to anyone who copied the library. Expect the next operator to start where the last one finished.

The patience matters for detection too. An agent that spreads a campaign over days, one attempt per account and a few dozen requests per proxy, stays under alert thresholds tuned for minutes. Correlate identity, WAF and CDN events across days, not per session, or the loop stays invisible until the agent finds the gap.

Indicators of compromise

The indicators below belong to one of the six operators, the TGSEC operation that HackersEye exposed publicly. They are actor-side infrastructure recorded in the operator’s own files between August and November 2026: jump hosts, egress proxies and collection servers. All are rented commodity hosting, so hunt for them in sign-in, WAF and CDN logs from that period rather than blocking on them alone.

“High” means the operator’s own files name the host in that role. “Medium” is our assessment from the operator’s notes, which describe the last three as one multi-homed worker machine.

Acknowledgments

This research benefited from intelligence collaboration with HackersEye. Thank you to the HackersEye team for sharing their findings and for their public analysis of the same operator, Exposing the TGSEC operation, which covers the operator’s repositories, its links to the ARTEX framework and additional indicators.

If you want to know what an AI operator would find about your organization first, talk to Profero.