AI changes how quickly infrastructure can be understood, manipulated and operated. Infrastructure control needs to change with it.
In The Top 6 Infrastructure Risks When AI Becomes an Attack Tool, we looked at an uncomfortable characteristic of modern infrastructure. AI does not need an entirely new attack surface. Identities, APIs, infrastructure automation, configuration state, management systems and the relationships between them already provide one. AI changes how comprehensively that environment can be investigated and how quickly what is discovered can be acted upon.
There is another side to the same problem. Organizations are simultaneously introducing their own AI agents into infrastructure operations. These agents may be entirely legitimate. We want them to understand requests, select automation, invoke APIs, provision environments, investigate problems and eventually take increasingly autonomous action.
The distinction between the two scenarios is important, but from the infrastructure’s perspective they eventually converge on the same question: who or what has the authority to change infrastructure, and under what conditions should that change actually be allowed to happen? The answer cannot simply be to trust AI when it is ours and stop it when it belongs to somebody else. Infrastructure needs its own control boundaries. That requires more than conventional security around individual resources. It requires infrastructure to retain control of identity, automation, policy, context, lifecycle and the scope within which actions can occur.
1. Bound Authority Before AI Uses It
The first risk identified in the companion article was authority. Modern infrastructure contains an enormous population of machine identities including service accounts, cloud roles, API tokens, CI/CD credentials, Kubernetes identities and automation accounts. AI potentially makes the relationships between those identities considerably easier to investigate, so the defensive response begins with reducing what those identities can ultimately accomplish.
Least privilege remains fundamental, but agentic infrastructure adds another consideration. It is no longer enough to ask whether an identity has permission to execute an operation. Organizations increasingly need to consider the decision authority represented by that permission. An AI agent given permission to invoke an infrastructure API has execution authority. If it can independently decide when, why and how to invoke it, that permission has also granted the agent some degree of decision authority.
That authority needs defined boundaries. A development request should not inherit production authority simply because the underlying automation can operate in both environments. An agent provisioning temporary GPU infrastructure should not implicitly receive authority to retain it indefinitely, and access to an infrastructure capability should not automatically mean access to every possible implementation of it. The same principle helps defend against compromised identities because an attacker obtaining an identity should inherit only its deliberately constrained authority, rather than an unexpected chain of permissions capable of traversing the infrastructure estate.
An infrastructure automation control plane should therefore tie identity to defined infrastructure capabilities, context and policy rather than providing unrestricted access to the underlying infrastructure. Authentication remains essential, but the larger objective is to bound the authority that successful authentication ultimately represents.
2. Expose Approved Automation, Not Raw Infrastructure
The infrastructure industry has spent years encoding operational expertise into Terraform, Ansible, Helm, CloudFormation, pipelines, scripts and orchestration. That is enormously valuable, but it also means much of the knowledge required to construct and manipulate infrastructure already exists in executable form.
The companion article examined why this is attractive to an AI-enabled attacker. The same observation suggests part of the defense. Instead of allowing an agent, or indeed every infrastructure consumer, to reconstruct complex environments through unrestricted low-level access, organizations can expose approved, reusable infrastructure capabilities.
A request might, for example, be allowed to consume an approved AI development environment containing compute, networking, storage, security configuration and application services. The consumer does not necessarily need independent authority over every system required to construct it. The underlying complexity remains, but the authority model changes because the approved capability becomes the governed route through which that complexity is consumed.
This is where source-controlled, reusable automation becomes more than an operational convenience. It creates a controlled path through which infrastructure can be delivered. Torque provides one practical example. Infrastructure and application automation can be assembled into reusable, source-controlled blueprints, while individual deployments retain their own lifecycle and ownership context. An authorized AI agent can therefore reason about the required outcome without necessarily being given the authority to invent every aspect of its implementation.
An infrastructure automation control plane should make approved, version-controlled automation the normal route to infrastructure rather than one option among many uncontrolled paths. This allows AI to reason about the required outcome while the infrastructure platform retains control over how that outcome is implemented.
3. Put a Control Plane Between AI and a Fragmented Stack
Infrastructure fragmentation is not going away. Compute, networking, storage, Kubernetes, public cloud, security and application platforms have different APIs, identity models, configuration systems and specialist automation for legitimate reasons. The problem is that fragmentation also creates relationships between those systems.
The threat article looked at those relationships from the attacker’s perspective. A cloud identity can lead to a repository, the repository to a pipeline, the pipeline to automation and the automation to infrastructure elsewhere. Simply connecting an authorized AI agent directly to every infrastructure system creates the mirror image of that problem.
The agent can begin accumulating cloud credentials, network access, Kubernetes permissions, storage identities, application APIs and automation interfaces. Eventually, its effective authority becomes the aggregate of all those independently governed relationships. In practical terms, the fragmentation problem has moved inside the agent.
A different architecture places an infrastructure control layer between AI intent and the specialist infrastructure underneath it. The underlying tools do not disappear. Terraform remains Terraform, Kubernetes remains Kubernetes, and network controllers, cloud platforms and storage systems continue doing what they already do. The important difference is that the agent does not necessarily require direct and independent authority over all of them.
A common control plane can provide identity, context, policy, approved automation and lifecycle management before requests reach the underlying stack. Such a control plane becomes an important security boundary and must itself be secured accordingly. Concentrating authority does not eliminate risk, but it can reduce the number of independent, ungoverned paths through which humans, applications and autonomous systems manipulate infrastructure.
An infrastructure automation control plane should therefore provide a governed consumption layer across heterogeneous infrastructure without requiring an AI system to accumulate independent credentials and authority for every underlying platform.
4. Enforce Intent, Not Just Identity
Consider an infrastructure operation in which the identity is valid, authentication succeeds, RBAC permits the operation, the automation is approved and the API behaves exactly as designed. The resulting infrastructure can still be wrong.
An agent might deploy into the wrong region, consume excessive GPU capacity, create an unacceptable network relationship, use an approved capability in the wrong environment or leave temporary infrastructure running indefinitely. An attacker using compromised legitimate credentials can create a similar problem. Nothing about the individual API request necessarily identifies what is wrong.
Authentication establishes who or what is making the request, while authorization establishes what that identity is allowed to do. Neither necessarily establishes whether this particular action should happen in this location, at this time and for this purpose. That determination requires operational context and policy.
Useful context can include who requested the infrastructure, which project it belongs to, whether the target is development or production, which regions are acceptable, what resources can be consumed, which network relationships are permitted, what level of cost is acceptable and how long the infrastructure should exist. An AI system can use that information when reasoning, but important constraints should not depend entirely on whether the AI successfully retrieves, interprets and applies them.
Those constraints need independent enforcement. Policies can be applied to infrastructure consumption, environment operations and Terraform plans, including constraints around permitted regions, resource types and cost. An infrastructure automation control plane should evaluate a requested action in context before execution, rather than relying solely on whether the requesting identity possesses the necessary permission. Identity can establish whether an operation is technically permitted, while context and policy establish whether that operation is appropriate under the conditions in which it has been requested.
5. Design the Blast Radius Before Something Goes Wrong
AI changes the scale at which infrastructure can be investigated and operated. An autonomous system does not become dangerous simply because it can act quickly. The more significant consideration is how much infrastructure it can influence when it acts, and the same consideration applies when an attacker obtains legitimate credentials.
A compromised identity capable of affecting one constrained development environment represents a very different problem from one capable of modifying networking, compute, storage and production services across multiple accounts. Infrastructure architecture should therefore determine the maximum useful scope of authority before something goes wrong rather than discovering that scope during an incident.
Approved automation helps because infrastructure teams can expose higher-level capabilities whose acceptable implementation has already been defined. Policy can constrain where those capabilities are used, lifecycle controls can determine how long they exist, and ownership and contextual information can restrict who can request them and for what purpose. Together these mechanisms make blast radius something deliberately designed into infrastructure consumption rather than something examined primarily after an incident.
This also provides an important response to the AI attacker described in the companion article. AI may become increasingly effective at discovering paths through infrastructure, but finding one useful path should not automatically expose the next one. An infrastructure automation control plane should combine authority, environment scope, policy and lifecycle controls to create enforceable boundaries around how far any individual infrastructure action can propagate. The architecture should assume that eventually a person, an agent or a compromised identity will make the wrong decision and ensure that the consequences have a defined boundary.
6. Make Governance Operate at Machine Speed
The obvious response to autonomous infrastructure authority is to require a person to approve every action. Human approval remains entirely appropriate for some operations, particularly high-impact production changes or actions with an unusually large potential blast radius. It cannot, however, become the answer to every autonomous decision without eliminating much of the value of autonomous infrastructure.
If an agent can understand a request, evaluate infrastructure and formulate an operation in seconds, but every routine action subsequently waits for an infrastructure engineer to approve a ticket, the organization has simply accelerated the creation of work for the human operator rather than automating the infrastructure process.
The alternative is not less governance, but governance incorporated directly into the execution path. Identity, context, policy, approved automation and lifecycle rules can evaluate routine operations automatically. Actions that remain inside established boundaries can proceed, while those outside the boundaries can be denied or escalated for human review. Humans remain important because they establish the boundaries and handle exceptions, ambiguity and high-impact decisions rather than manually authorizing every normal operation.
Torque’s MCP architecture provides a useful example by allowing AI tools to interact with platform capabilities while inheriting the permissions associated with the authenticated user rather than creating an entirely separate privilege path for the AI. The broader architectural principle is that AI should not require a parallel governance model simply because it can operate faster than the humans who established the existing one.
An infrastructure automation control plane should therefore make policy-driven allow, deny and escalation decisions part of execution, supported by continued validation after infrastructure has been deployed. Governance has to operate at the speed of the systems it governs while preserving human involvement where the potential consequences justify it.
Infrastructure Has to Remain the Authority
The companion article examined six characteristics that make modern infrastructure attractive to an AI-enabled attacker: authority, automation, fragmentation, state, leverage and scale. None can simply be removed. Infrastructure requires authority to operate, automation is essential, specialist platforms will continue to exist, infrastructure state contains necessary operational information, management systems require leverage to manage complex environments and scale is one of the primary reasons organizations automate infrastructure in the first place.
The answer is therefore not to make infrastructure less programmable, but to make that programmability governable. The same architecture can help whether the AI approaching the infrastructure is hostile or helpful. An attacker may use AI to search for credentials, understand automation, correlate infrastructure state and identify control points, while an authorized agent may use AI to understand a request, select automation, determine infrastructure requirements and invoke many of those same control points. Their intent is entirely different, but the infrastructure should not have to depend on intent alone to protect itself.
A governed infrastructure layer can independently establish identity and context, apply policy, expose approved automation, constrain lifecycle and limit the authority through which an action becomes real. This allows AI to reason about an infrastructure objective, request the appropriate capability and, within defined boundaries, take action without transferring ultimate authority over the infrastructure to the AI itself.
The architectural principle connecting both articles is therefore straightforward: AI can participate in deciding what should happen, but infrastructure still needs an independent mechanism for determining what is allowed to happen.
I you would like to understand how big the threat of AI and traditional attacks are on infrastructure, read the companion blog The Top 6 Infrastructure Risks When AI Becomes an Attack Tool.
If you are more interested in getting 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.
