How AI Agents Compressed an Enterprise Intrusion

Artificial intelligence did not need a new zero-day to materially change the pace of an enterprise intrusion. In an investigation published by Palo Alto Networks’ Unit 42, a human-controlled operation used frontier AI models and attack-specific agentic frameworks to automate large portions of a compromise. The result was a fast, adaptive intrusion that Unit 42 said compressed work normally requiring about two weeks into less than 10 hours.

The incident is significant because it demonstrates an operational shift rather than a newly invented exploit technique. The attacker delegated reconnaissance, information processing, credential discovery and follow-on decisions to software agents. Those agents repeatedly evaluated tool output, selected subsequent actions and shared information across the operation. Human direction remained part of the campaign, but much of the tactical execution ran through an automated loop.

Unit 42’s report is the primary source for the technical findings discussed here. The affected organization was not identified in the supplied research, and the report does not provide a CVE, a named malware family or a confirmed threat-group attribution.

What Unit 42 confirmed

Unit 42 responded to an enterprise intrusion in which the actor used AI agents to pursue access across several connected technology layers. The organization’s later update clarified that the event should be described as an intrusion rather than a ransomware attack. The source report says the actor described the operation during negotiations as relying on frontier AI models and specialized agentic AI frameworks. That statement is an account from the actor, not independent proof of the actor’s identity or every claimed capability.

Unit 42 observed several features it assessed as consistent with AI-assisted operations:

• Calls to multiple frontier AI agents running in parallel.
• Structured Markdown files used to pass information between agents and sessions.
• Custom scripts that Unit 42 assessed, with high confidence, were AI-generated based on their user-interface elements.

The report also describes an 80-page technical audit that the attacker left behind. It reportedly documented numerous security findings in the environment. The supplied research does not identify the audit’s full contents or establish whether every finding represented a successful compromise.

From public service access to internal mapping

The reported sequence began when the actor breached a publicly accessible web service and used it to tunnel into the enterprise network. An automated reconnaissance agent then mapped internal microservices. Unit 42 maps this activity to Exploit Public-Facing Application (MITRE ATT&CK T1190) and Network Service Discovery (T1046), while also associating it with the MITRE ATLAS categories for initial access and AI-automated reconnaissance.

The important defensive point is the transition from initial access to rapid internal understanding. Rather than relying solely on a human operator to inspect systems one by one, the agent processed service-discovery results and used them to guide the next phase. This type of automation can shorten the interval between an exposed service being accessed and internal assets becoming targets.

Repository secrets became a path to administrative control

After mapping the environment, sub-agents searched enterprise code repositories for hard-coded tokens and service passwords. Unit 42 associates this behavior with Credentials In Files (T1552.001). The report does not identify the repository platform, the specific secrets, or the exact scope of data accessed.

The recovered tokens were then used to enter a secrets-management system. From there, the actor harvested master administrative credentials and obtained root-level system access, according to Unit 42. The source maps this stage to Credentials from Password Stores (T1555). In practical terms, the sequence illustrates how weaknesses in application code and secret-management boundaries can combine: a token exposed in a repository may become substantially more damaging if it can reach a central store containing higher-value credentials.

For defenders, this is also an example of why secret scanning alone is not enough. Organizations need to understand what each credential can access, whether it can be used from unexpected locations, and how quickly it can be revoked across dependent systems.

CI/CD and cloud infrastructure were linked targets

The actor next abused an enterprise code application and custom workflows to exfiltrate cloud access keys. The operation included an attempt to place backdoors in Terraform configurations. Unit 42 reports that strong branch-protection controls prevented that change from succeeding. This is one of the clearest examples in the investigation of a preventive control interrupting an automated attack path.

Unit 42 maps the pipeline activity to Modify Cloud Compute Infrastructure (T1578), while its ATLAS mapping identifies ML/DevOps Pipeline Interception. The source does not provide the specific workflow definitions, cloud provider, or infrastructure-as-code repository details.

The attempted Terraform modification is operationally important even though it was blocked. Automated agents can make changes quickly and repeatedly, but mandatory review, immutable branch protection and separation of duties can keep a fast-moving process from becoming an unauthorized production change. These controls are particularly valuable when repositories can influence identity, networking or cloud compute resources.

Compromised AI services became attacker infrastructure

Using stolen cloud keys, the actor invoked the victim’s AI endpoints and used the organization’s AI infrastructure as part of the post-compromise operation. Unit 42 maps this behavior to Valid Accounts (T1078) and the ATLAS category LLM Invocations via Stolen API Keys.

This creates two risks beyond ordinary cloud credential theft. First, unauthorized model usage can generate direct cost and consume scarce compute capacity. Second, traffic associated with the attacker’s orchestration may blend with legitimate internal AI activity, making it more difficult to distinguish malicious use from normal application behavior. Unit 42 specifically warns that compromised AI services can help conceal orchestration traffic among expected traffic and shift operating costs to the victim.

The report does not establish that the victim’s models were modified, that model data was stolen, or that the AI endpoints themselves contained a vulnerability. The confirmed finding is that stolen cloud keys were used to invoke the organization’s AI services after compromise.

Why the operation moved so quickly

The report describes a feedback loop in which agents monitored results, evaluated them, acted and replanned. Parallel execution allowed different agents to work on reconnaissance, credential discovery and infrastructure tasks at the same time. Unit 42 says the operation used more than 50 MITRE ATT&CK techniques, although the supplied material identifies only a subset in its summary table.

The speed did not come from a novel exploit. Instead, it came from reducing the pauses between intrusion stages and allowing software to interpret raw tool output. That distinction matters for incident response. Traditional investigations may focus on individual alerts or isolated commands, while an agent-assisted intrusion can appear as a series of technically ordinary actions performed with unusual timing, concurrency and adaptability.

Unit 42 also reports that the attacker established overlapping persistence across SSH keys, serverless functions, container restart policies, cloud identities and CI/CD pipelines. This is a researcher-reported finding from the incident. The supplied research does not describe each persistence mechanism in enough detail to determine which ones succeeded, how they were configured or how long they remained active.

Detection and response priorities

Organizations should look for behavior that connects identity, code, cloud and AI telemetry rather than treating those systems as separate monitoring domains. Unit 42 highlights several indicators and patterns for investigation:

• Bursts of API requests or unusually rapid sequences of failed and successful HTTP responses, including 401-to-200 transitions.
• Parallel authentications from identities or locations that do not normally operate concurrently.
• Sudden model usage by an unexpected identity, application or cloud account.
• Structured Markdown files, Python caches and paired asset folders appearing in locations associated with suspicious activity.
• Rapid changes across repositories, CI/CD workflows, cloud identities and AI endpoints during a single incident window.

These are hunting leads, not standalone proof of agent use. A legitimate development tool or automation platform may produce some of the same artifacts. Detection quality will improve when teams correlate the artifacts with unusual credential access, repository searches, cloud-key use and changes to pipeline configuration.

What organizations should do now

1. Prepare coordinated containment. Build and regularly test playbooks that can revoke exposed credentials, terminate OAuth sessions, pause CI/CD pipelines and isolate affected cloud accounts together. A response that closes only one access path may leave parallel persistence intact.
2. Inventory AI infrastructure. Track model endpoints, API keys, Model Context Protocol gateways and AI tool integrations. Apply least privilege, strict rate limits and detailed diagnostic logging to each integration.
3. Protect repositories and secrets. Remove hard-coded credentials, scan historical code where appropriate, rotate exposed tokens and limit the systems each service credential can reach. Central secrets stores should not become an unrestricted bridge to administrative access.
4. Harden CI/CD controls. Require multi-party review for infrastructure changes and use immutable branch protection for infrastructure-as-code repositories. Review automation identities and ensure pipeline credentials cannot modify their own safeguards.
5. Monitor for behavioral loops. Correlate authentication, API, cloud, repository and model-use events. Prioritize speed, parallelism and unexpected identity changes as risk signals, while validating them against known automation.
6. Test recovery across overlapping access paths. Include SSH keys, cloud identities, serverless components, containers and pipeline credentials in compromise exercises. Recovery should verify that alternate access routes have also been removed.

Conclusion

Unit 42’s investigation shows how frontier AI agents can increase the tempo and breadth of an enterprise intrusion without requiring a novel vulnerability. The reported operation combined public-service access, internal mapping, repository secret theft, secrets-manager compromise, CI/CD abuse and cloud AI resource misuse. Its central lesson is defensive: organizations must connect controls and telemetry across application, identity, DevOps, cloud and AI environments, then be ready to contain several access paths at once.

Sources

• Palo Alto Networks Unit 42: An AI-Assisted Cyber Attack: Inside a Unit 42 Investigation