There is a difference between an attacker asking a chatbot to write a phishing email and an AI agent that operates tools, evaluates results and keeps working against a target with little human input.
The first is AI-assisted crime. The second changes how quickly an intrusion can unfold and how much work one operator can delegate.
Real investigations published in 2025 and 2026 show the second pattern is happening. The evidence does not mean that AI independently chooses to commit crimes, that every attack is now autonomous, or that attackers have discovered an entirely new class of vulnerability. In the documented cases, people still generally selected objectives, arranged access and decided what to do with results. Agents executed much of the operational work.
For teams responsible for cloud infrastructure, Kubernetes, CI/CD and production security, that distinction is more important than the headline.
What an AI-operated intrusion actually looks like
A conventional automated attack follows a relatively fixed script. It checks known conditions and runs pre-programmed steps. An agentic workflow can also use the results of one step to decide what to investigate next, select tools or recover from an error.
A useful way to distinguish three levels is:
- Assistance: a human asks a model to summarize a vulnerability, create code or draft social-engineering text. The person executes the resulting plan.
- Orchestration: a human defines a target and gives an agent access to tools. The agent conducts multiple steps and returns to the operator for important decisions.
- Limited-supervision execution: multiple agents or workflows continue performing scanning, exploitation attempts, credential collection and analysis for hours without human review of each individual operation.
These are descriptions of observed operating models, not a standardized industry taxonomy.
From the defender's perspective, the troubling feature is that the same credential, forgotten service or vulnerable endpoint can now be tested by attackers at higher frequency and with faster adaptation.
November 2025: Anthropic reports AI-orchestrated espionage
In a November 13, 2025 investigation, Anthropic described a suspected state-sponsored espionage operation that abused its coding agent to attempt intrusions against roughly 30 targets. Anthropic assessed that AI performed approximately 80-90% of the campaign's operational tasks, while people remained involved at a small number of key decision points.
That 80-90% is Anthropic's estimate about that specific investigated campaign, not a statistic about the percentage of all cyberattacks using AI.
The report also described a limitation: the agent could hallucinate credentials or mistake publicly available information for stolen secrets. Agentic operation was not synonymous with perfect execution.
The central lesson was that a malicious operator could delegate a substantial intrusion workflow to tools connected to an AI system. The operator did not have to personally perform every individual technical step.
July 2026: a reported autonomous extortion operation
On July 1, 2026, Sysdig published its JADEPUFFER investigation. Sysdig assessed that a large language model drove an intrusion and destructive database-extortion workflow, beginning with compromise of an exposed Langflow installation.
Sysdig's evidence included adaptive troubleshooting behavior and rapid retries after operational errors. Its description calls the case agentic ransomware. The characterization is based on Sysdig's investigation of the observed environment; we should not pretend to have independently reconstructed the entire operator-agent interaction.
This matters to defenders because exposed applications with known weaknesses, credentials that can be reused and permissive paths toward production data can turn a single entry point into a larger incident.
It does not follow that every exposed AI framework will be compromised or that every autonomous campaign will succeed.
September 2026: the model moves from assistant to operator
Anthropic's September 2026 threat-intelligence report, covering activity observed between December 2025 and August 2026, described multi-agent frameworks conducting reconnaissance, exploitation and data theft against multiple victims.
Some operations ran for hours or days with limited supervision. Others still required human instructions for individual actions. Anthropic emphasized that humans often retained target selection, monetization and result review.
The same month, Google Threat Intelligence Group reported a Q2 2026 case in which attackers compromised a cloud resource and built and launched an agent-enabled mass credential-harvesting campaign in under six hours. Google also documented attempts to manipulate AI coding tools and security scanners in open-source supply-chain compromises.
These vendor investigations establish a real capability and observed pattern, not a reliable global count of autonomous attacks or a universally measured rate of growth.
In its October 2026 Digital Defense Report, Microsoft similarly described an evolution from AI assistance toward more autonomous execution, while cautioning that most complex real-world intrusions still involve meaningful human direction.
The vulnerable systems are often familiar
The reported operations involved ordinary attack surfaces: internet-facing services, exposed software vulnerabilities, compromised identities, reused secrets, weak authorization and attractive data stores.
AI changes the economics of exploiting these weaknesses. Faster investigation and iteration mean a defender may have less time between an exposed opportunity and an attempted compromise.
A platform team should therefore review where a low-effort initial foothold could lead to a high-impact action:
- An internet-facing admin panel that can reach internal services.
- A Kubernetes workload holding credentials that grant wider cloud permissions.
- A build runner with access to package publishing or deployment tokens.
- An application service account allowed to read more secrets than its workload requires.
- An AI agent that can fetch untrusted content and then invoke privileged tools with the same identity.
This is a defensive threat-model checklist, not a claim that these entry points were present in every cited case.
Five defensive priorities for DevSecOps and SRE
1. Reduce exposure time, not just CVE backlog size
Inventory genuinely reachable services, follow critical vendor advisories and verify patch deployment on the exposed runtime. Prioritize vulnerabilities by exploitation evidence, reachable paths, privileges and business impact rather than by CVSS score alone.
A clean container scan is useful evidence, but it does not prove that the deployed identity, network paths or runtime configuration are safe.
For changes that cannot be applied immediately, document the temporary containment, owner and deadline. Do not describe a compensating control as a guaranteed fix.
2. Treat credentials as the likely next target
Prefer short-lived workload identities where supported. Limit what a compromised Pod, CI job or AI tool can do; separate read-only analysis from writes to production and business systems.
A secret should not become a cluster-admin credential merely because an automation workflow needs to read metrics.
3. Instrument meaningful activity at the identity and application layers
A firewall rule or CPU alert may reveal only a small part of an intrusion. Preserve API access events, cloud identity actions, unusual credential use, critical configuration changes and confirmed outbound data paths.
Make alerts actionable. A detection queue full of ordinary automated requests will not help when a real intrusion progresses faster than the incident team can triage it.
4. Exercise containment, credential rotation and restore
A runbook should identify which identities can be disabled, which network paths can be isolated and how service ownership is transferred during an incident. Test how long a key rotation takes and whether recovery requires an already compromised control plane.
Where databases and object storage are involved, test an application-consistent restore rather than relying on the presence of a backup object. The same measured approach applies to disaster recovery testing and failover.
5. Defend your own AI integrations as production services
An agent that reads email, issues, repository files or web pages can encounter attacker-controlled instructions. Its tools, tokens, execution sandbox and approval boundary need the same scrutiny as any other service account.
Do not give an LLM permission to perform an irreversible operation simply because a system prompt says it should be careful. See how prompt injection can turn untrusted content into tool misuse.
What AI changes - and what it does not
AI agents may make intrusion attempts faster and more scalable, but their availability does not make identity controls, patching, segmentation, secure build pipelines or recovery testing obsolete. It makes failures in those controls more urgent.
The wrong response is to claim every alert now comes from an autonomous AI. The right response is to assume that a sufficiently motivated attacker can automate significant parts of the workflow, then make the critical paths observable, restrictive and recoverable.
For organizations that run Kubernetes, cloud production systems or connected AI agents, Big Bad Byte DevSecOps engineering should focus on the permissions and exposed paths a malicious operator - or their autonomous tooling - could actually use. When the review also needs to cover tooling, reliability and cost, start with a broader infrastructure audit.