The Top 6 Infrastructure Risks When AI Becomes an Attack Tool

Agentic AI does not create an entirely new infrastructure attack surface. It changes who can exploit the existing one, how comprehensively they can understand it, and how quickly they can act.

The transition from warning to observed behavior has already begun. In November 2025, Anthropic reported what it described as the first documented AI-orchestrated cyber-espionage campaign. According to Anthropic, a Chinese state-sponsored group manipulated Claude Code into attempting infiltration of roughly 30 global targets. The company estimated that AI performed 80–90% of the campaign, with human intervention required at only four to six critical decision points per target. The system researched targets, identified and tested vulnerabilities, wrote exploit code, harvested credentials, identified higher-privilege accounts, extracted data and documented its findings for subsequent operations.

That does not mean every cyberattack has suddenly become autonomous. It does demonstrate that the capabilities discussed in this article are no longer purely theoretical. Autonomous systems can research targets, generate and modify code, analyze results, adapt an approach and continue pursuing an objective without requiring a human decision at every stage. For infrastructure teams, the more useful question is therefore what an AI-enabled attacker would actually find when examining the infrastructure we operate today.

The answer is unlikely to begin with a new generation of exotic AI-created vulnerabilities. Modern infrastructure already contains identities with extensive privileges, executable automation, APIs, pipelines, management systems, configuration state and complex relationships between independently controlled infrastructure domains. AI changes the economics of understanding and exploiting those relationships.

Traditionally, the sophistication of an attack has been constrained in part by the expertise, time and attention available to the attacker. AI begins to change that equation. A human can provide an objective while AI contributes research, code generation, interpretation, correlation and iteration. This does not make every AI system an autonomous cyberweapon, and an attacker still needs access, opportunity and exploitable weakness. What changes is the cost of repeatedly examining an infrastructure environment, correlating what is discovered and using each result to determine what should be investigated next.

From an infrastructure perspective, six characteristics are particularly important.

1. Authority Becomes a Search Problem

Modern infrastructure contains an enormous population of identities that are not people. Service accounts, cloud roles, API tokens, CI/CD credentials, Kubernetes service accounts and automation identities routinely possess authority to create, modify and destroy infrastructure. The associated security problems are already well understood. Excessive permissions, long-lived credentials, privilege inheritance and identities whose access has expanded beyond their original purpose have existed for years.

Agentic AI does not create those weaknesses, but it can change how systematically they are investigated. An enterprise infrastructure estate can contain thousands of identities and many more relationships between identities, roles, policies, resources and services. Understanding which identity can access which system, which role can assume another, and which apparently limited credential provides an indirect route to something more valuable is an expensive manual exercise. With AI assisting the analysis, the problem increasingly resembles one of constructing and interrogating a graph of authority.

Real World Signal – The Existing Attack Surface is Already Large 

Verizon’s 2026 Data Breach Investigations Report found that vulnerability exploitation had become the leading initial access vector, accounting for 31% of breaches. Verizon also reported that AI is helping threat actors compress the time between disclosure and exploitation of known vulnerabilities from months toward hours. The significance for infrastructure teams is straightforward: AI does not need to invent weaknesses if exploitable ones already exist at sufficient scale.

This distinction matters because the most privileged identity is not necessarily the most useful one. An attacker is interested in the identity that provides a path toward the intended objective. A relatively constrained automation identity may be able to invoke a deployment system. That deployment system may possess a different identity with broader infrastructure permissions. A service account associated with one environment may have legitimate relationships with services elsewhere. Each permission can appear reasonable when inspected independently while the combined path represents considerably more authority than any individual component suggests.

The infrastructure attack surface therefore includes more than credentials and permissions. It includes the relationships connecting identities to automation, management systems and infrastructure. AI makes those relationships considerably more practical to examine at scale.

2. The Organization Has Already Encoded How Its Infrastructure Works

The infrastructure industry has spent two decades turning operational knowledge into software. Terraform modules describe infrastructure, Ansible playbooks encode configuration, Helm charts and Kubernetes manifests define applications and services, CloudFormation templates express cloud architectures, and scripts capture operational procedures. CI/CD and orchestration systems then connect these assets to the environments in which they execute.

This has transformed infrastructure operations because engineers no longer need to reproduce manually every step required to construct an environment. The same abstraction has an important security consequence: infrastructure automation is executable organizational knowledge.

An AI-enabled attacker does not necessarily need to recreate that knowledge. Infrastructure-as-code can describe which resources belong together, which providers are used, which parameters matter and which dependencies must exist. Repositories reveal versions and relationships. Pipelines show how automation is invoked, while orchestration systems can reveal how separate automation assets become complete environments. The attacker’s problem begins to change from understanding how to build or modify the infrastructure from first principles to understanding how the organization already does it.

This is particularly relevant to AI because code generation is only part of the capability that matters. Code comprehension, correlation and iteration may prove equally important. An agent capable of analyzing existing automation alongside infrastructure state and execution results does not need to begin with deep expertise in every tool represented in the environment. It can use the organization’s automation as part of the technical context from which it reasons.

Repositories, infrastructure-as-code, pipelines, automation systems and their execution identities therefore need to be considered part of the infrastructure attack surface. The organization may already have encoded much of the expertise required to operate its most complex environments. An attacker increasingly has tools capable of understanding that encoding.

Real-World Example – Automation Created Leverage

The March 2025 compromise of the widely used tj-actions/changed-files GitHub Action illustrates the leverage already concentrated in infrastructure automation. Palo Alto Networks Unit 42 reported that the compromised action was used by more than 23,000 GitHub repositories. Attackers injected a payload that dumped CI/CD runner memory, exposing environment variables and secrets in workflow logs. This was not an AI-originated attack, but that is precisely why it matters here: the incident demonstrates how a single automation component can provide reach across thousands of software delivery environments. An AI-enabled attacker does not have to create that leverage; it can search for and exploit leverage that organizations have already built.

3. Fragmentation Creates More Paths Through the Infrastructure

Modern full-stack infrastructure is rarely operated as a single system. Compute, networking, storage, Kubernetes, public cloud, security and applications commonly have separate management platforms, APIs, identities, configuration models and automation. AI infrastructure makes this particularly visible because GPU compute, high-performance networking, storage, orchestration and software services have to operate together while frequently remaining the responsibility of different tools and specialist teams.

There are legitimate reasons for this specialization, and fragmentation does not mean that any individual infrastructure component is insecure. The security issue is that the effective attack surface includes the relationships between those components. An attacker does not need to compromise every layer of the stack. It needs to identify a useful path through them.

This is where agentic AI potentially changes the significance of fragmentation. A cloud team may understand its environment primarily through cloud IAM and provider APIs, while a network team works through a different policy and management model. Platform engineering understands Kubernetes, storage has its own administration layer, and DevOps owns pipelines and repositories. Those organizational boundaries help humans divide the problem into manageable domains, but they do not necessarily constrain an autonomous system analyzing the environment.

An AI-enabled attacker can potentially correlate information across those domains. A cloud identity can be associated with a repository, the repository with a pipeline, the pipeline with a deployment environment, and that environment with network or storage relationships. Those relationships may expose additional identities or management systems worth investigating. No individual step has to represent a serious vulnerability by itself. The combination can create the useful path.

This is an important distinction for full-stack infrastructure security. Each specialist team can maintain a defensible security posture while the relationships between their systems remain much less visible. As the number of independently managed layers increases, so does the number of interfaces, identities, automation boundaries and trust relationships that need to be understood. The attacker is not constrained by the organizational silos through which the infrastructure is managed; it can treat the relationships between them as part of the same analytical problem.

4. Infrastructure State Becomes an Intelligence Source

Understanding an infrastructure environment has traditionally required considerable expertise and time. Documentation is incomplete, ownership changes, resources drift, teams use different tools, temporary infrastructure survives longer than intended and the operational environment rarely corresponds perfectly with its architectural diagram. What looks like complexity to the people responsible for operating the infrastructure can also become a rich source of information when an AI system is able to correlate many different pieces of state.

An attacker does not need to discover a single authoritative document describing the infrastructure estate. Resource metadata, repositories, deployment records, configuration, tags, APIs, logs, automation definitions and identity relationships can each provide part of the model. Individually, these pieces may reveal relatively little. Together, they can establish what an environment does, how it was created, who owns it, which systems it depends upon and what is capable of changing it.

AI is particularly relevant here because the information does not have to arrive in one clean or predefined format. Different sources can be interpreted, compared and incorporated into a developing model of the environment. A resource tag can establish ownership, a repository can reveal how the resource was created, automation can identify dependencies, identity information can establish who or what can change it, and service configuration can expose relationships with other parts of the infrastructure.

Infrastructure state is also dynamic. Temporary access persists, resources outlive their intended lifecycle, configuration changes outside normal automation paths and environments drift from their expected state. Reconstructing those changes repeatedly is expensive for a human attacker. An autonomous system can make repeated observation and comparison part of its normal analytical process.

The security concern is therefore broader than whether sensitive infrastructure information is publicly exposed. The more significant question is whether the information available across multiple systems can be assembled into an accurate enough model to expose relationships that are difficult for the organization itself to see.

5. The Most Valuable Target May Be the System That Controls Everything Else

Once the infrastructure has been sufficiently understood, the attacker’s problem becomes one of leverage. Manipulating hundreds of individual resources is inefficient if an existing system already possesses authority to manipulate them collectively. Cloud management APIs, Kubernetes control planes, CI/CD platforms, GitOps controllers, virtualization management, network controllers and infrastructure orchestration systems all concentrate operational authority because that is precisely what makes them useful.

The most valuable target is therefore not necessarily the most valuable resource. A comparatively unimportant system can become significant because of what it can influence. A development environment may be useful because of its relationship with a pipeline. The pipeline may be valuable because it can invoke infrastructure automation. The automation system may matter because its execution identity has authority over an environment, and a management interface may be important because it can manipulate resources elsewhere in the stack.

This is where the preceding risks begin to compound. Identity establishes authority. Automation describes how infrastructure is manipulated. Fragmentation provides relationships between independently controlled domains, while infrastructure state helps assemble those relationships into a coherent model. The next step is to determine which combination provides the greatest reach.

Control planes and orchestration systems are particularly important in this analysis because they intentionally abstract the complexity of the systems underneath them. The same is true of APIs. Infrastructure has become increasingly API-driven because programmatic interfaces make complex systems easier to operate and automate. Agent interfaces extend that progression by making it possible for reasoning systems to select and invoke tools based on an objective and the context available to them.

None of this makes a control plane or API inherently insecure. It does, however, concentrate the consequences associated with inappropriate access. Every abstraction that makes complex infrastructure easier for legitimate automation to operate can also reduce the amount of infrastructure-specific knowledge required by an attacker who finds a way to reach that abstraction.

For an AI-enabled attacker looking for leverage, the highest-value target may therefore be the system the enterprise built to make everything else easier to operate.

6. Successful Reasoning Can Be Repeated at Machine Scale

Automation has always allowed attackers to repeat actions. Agentic AI introduces a different capability because the result of one action can influence the decision about what to do next. An unsuccessful attempt becomes additional information. A denied operation establishes something about permissions, an unexpected response reveals something about the target, a failed piece of generated code can be analyzed and revised, and a newly discovered identity changes the developing model of authority.

The resulting process is less like running a static script and more like maintaining an iterative analytical loop.

The significance of this loop is not that every AI-enabled attack will happen in seconds. In many situations, patience and persistence may be more valuable than raw speed. The important difference is that every iteration no longer requires equivalent human attention. An autonomous system can continue gathering information, comparing hypotheses and adapting its approach within the authority and capabilities available to it.

Real-World Signal – Software is beginning to Adapt During Execution 

Google Threat Intelligence Group reported in 2025 that it had identified malware families using large language models during execution. PROMPTFLUX, an experimental VBScript dropper, queried the Gemini API for obfuscation and evasion techniques and was designed to rewrite its own source code periodically. Google emphasized that PROMPTFLUX was experimental and had not demonstrated the ability to compromise a victim network or device. Other malware, including PROMPTSTEAL, was observed in operations using an LLM to generate commands for collecting information and documents.

These examples are early rather than mature, but they show the direction of travel: AI can become part of the operational loop rather than merely a tool used beforehand by a human attacker.

Once a useful relationship has been identified, the economics change again. An identity pattern found in one environment can be investigated elsewhere. An automation relationship can be compared across repositories. A configuration weakness can be searched for across accounts, and an infrastructure dependency identified in one deployment can become a hypothesis applied to others. A human attacker has finite attention and time; autonomous systems increase the amount of investigation that can occur for the same human effort.

This is where AI intersects with decades of infrastructure programmability. APIs, infrastructure-as-code, automation and orchestration were designed to remove humans from repetitive infrastructure operations. Agentic AI introduces software that can increasingly participate not only in executing those operations but also in deciding which operation should be attempted next.

That is the scaling characteristic infrastructure teams need to consider.

The Full-Stack Attack Surface

None of these six areas is new. Identity attacks predate AI. Infrastructure-as-code, API security, configuration drift and fragmented management are established problems. Attackers have always searched for high-value management systems, and automation has long been used to scale successful techniques. Looking at any one of these issues independently therefore risks missing what agentic AI actually changes.

The difference emerges when they are considered as a connected system.

This is a more useful way to think about the AI-enabled infrastructure attack surface than imagining a malicious agent independently inventing novel attacks. The human can still provide the objective. What changes is how much of the research, correlation, technical interpretation and iteration can potentially be delegated to increasingly capable AI systems.

There is an uncomfortable consequence. Infrastructure complexity has historically created friction for everyone who needs to understand an environment, including an attacker. It still does. But some of that complexity derives from human organizational structures: different teams, specialist tooling, separate management systems and expertise distributed across multiple infrastructure domains. Those boundaries make a complicated environment manageable for the organization, but they are not necessarily equivalent security boundaries.

An AI system capable of reasoning across those domains does not need to respect the way responsibility has been divided internally. It can examine identity, automation, infrastructure state and management relationships as parts of the same problem.

AI Doesn’t Need a New Attack Surface

Agentic AI does not create excessive privilege, forgotten infrastructure, poorly governed automation, fragmented management, overpowered APIs, configuration drift or unintended trust between systems. Those conditions already exist in many infrastructure environments.

What AI changes is the ability to search for them, correlate them and repeatedly determine which combination provides a useful path toward an objective.

That should broaden how infrastructure teams think about the threat surface. It is not simply the sum of the servers, cloud resources, APIs and applications an organization operates. It also includes the identities that control them, the automation that creates them, the management systems that abstract them and, increasingly, the relationships connecting infrastructure domains that are governed independently.

An attacker does not need to defeat all of that complexity. It needs to understand enough of the environment to identify a path through it. The ability to perform that analysis persistently, across technologies and with less dependence on human expertise is what makes agentic AI important to the infrastructure security discussion.

AI doesn’t need to invent a new infrastructure attack surface. We may already have built one complicated enough for it to exploit.

I you would like to understand how to mitigate the greatest threats to your infrastructure we have a companion blog called 6 Ways to Make Infrastructure Safe from AI-Enabled Threats. It explains what can be done to ensure the 6 most important infrastructure vulnerabilities are mitigated.

If you are more interested in an assessment of your risk, we have a tool aimed at assessing your Infrastructure Threat Surface. It asks 10 questions taking about 3 minutes. It will provide you with a visual assessment and a prioritized recommended path to mitigate the threats. This assessment runs entirely in your browser. Quali does not log, track, or store your answers or your score, no analytics, no cookies, no server involved. The goal is an accurate, unbiased read of your environment, not a high score. Since nothing here is logged or tied to you, there’s no reason to answer for the infrastructure you’re aiming for instead of the one you actually have.

Sources for real-world examples

• Anthropic, “Disrupting the first reported AI-orchestrated cyber espionage campaign,” November 13, 2025.
• Verizon, 2026 Data Breach Investigations Report.
• Palo Alto Networks Unit 42, “GitHub Actions Supply Chain Attack: A Targeted Attack on Coinbase Expanded to the Widespread tj-actions/changed-files Incident,” updated April 2, 2025.
• Google Threat Intelligence Group, “AI Threat Tracker: Advances in Threat Actor Usage of AI Tools,” 2025.