AI Infrastructure Is Becoming Privileged Infrastructure

An AI gateway can look like plumbing. An orchestration platform can look like workflow software. A retrieval system can look like another application sitting quietly between a user and a model. But the label on the box doesn't tell you what an attacker gets if they take control of it.

Increasingly, these systems sit between models, provider credentials, enterprise data, cloud identities, tools and compute. That makes AI infrastructure security less about protecting one AI application and more about understanding where authority is accumulating across the wider architecture.

The question for security teams is becoming harder to avoid: should AI infrastructure be classified according to what it was built to do, or according to what compromising it would unlock? Once one component can open paths into several high-value systems, ordinary application-security assumptions may no longer be enough.

AI Infrastructure Is Concentrating More Than AI

Enterprise AI rarely operates as one self-contained system. Applications may call several model providers through a gateway, retrieve information from internal databases, invoke tools through an orchestration layer and run workloads across cloud infrastructure. Each connection solves a practical problem, but together they can place a surprising amount of access behind a small number of components.

That centralisation can be useful. A model gateway can give teams one place to manage routing, usage policies and provider access. Orchestration platforms can coordinate complex workflows without every application needing to rebuild the same logic. The same design choices, however, can concentrate credentials, data access, execution rights and policy decisions in one place.

Microsoft Security Research showed what that looks like in practice in August 2026. Its investigation into compromises involving LiteLLM, RAGFlow and Kestra found attackers pursuing similar goals across three different types of AI infrastructure: credentials, persistence, downstream access and compute resources. Microsoft described these workloads as high-value control points rather than isolated applications.

Google Threat Intelligence Group has since observed a similar pattern from another direction. Its September 2026 threat research describes attackers stealing AI credentials, compromising cloud environments and using access to create or abuse AI services and compute. The common thread isn't a particular product. It's the amount of useful authority sitting behind the infrastructure.

Privilege Depends On What Compromise Unlocks

Security teams already recognise some systems as unusually sensitive because of what they control. Identity providers can grant access across an organisation. Secrets managers hold credentials that unlock other services. CI/CD platforms can change software that reaches production, while cloud control planes can reshape entire environments.

An AI gateway or orchestrator isn't automatically equivalent to any of those systems. But its product category isn't the most useful test. The better question is what becomes reachable if the component is compromised. A gateway that only forwards low-risk requests is very different from one that can expose provider keys, tenant policies, database credentials and access to several downstream services.

This is where privileged infrastructure becomes a useful way to think about the problem. A component starts to behave like a privileged control point when losing control of it gives an attacker meaningful authority across systems that would otherwise be separated by their own security boundaries.

That doesn't require inventing a new Tier 0 category for every AI tool. It means judging effective privilege by consequence. If compromising one piece of infrastructure can move an attacker from model access to cloud identities, data, tools or execution, its security classification should reflect that reach rather than the seemingly modest job description attached to it.

Attackers Are Already Following The Authority

Recent attacks make the distinction easier to see. In Microsoft's LiteLLM investigation, the gateway sat between applications and model providers and could hold or retrieve provider API keys, virtual keys, database connection strings, routing configuration and tenant policy data. Once attackers gained execution in that context, they harvested credentials, accessed the backing database and established persistence.

The RAGFlow compromise followed a different route but exposed the same underlying problem. Attackers modified part of the platform so newly entered model-provider credentials could be intercepted. With Kestra, the valuable capability was workflow execution. Compromise of the orchestration environment gave attackers a route to shell execution, container discovery, secrets and compute abuse.

Google's September threat intelligence extends that pattern into the wider cloud environment. In one incident, an exposed GitHub token ultimately enabled an attacker to create AI infrastructure, deploy LiteLLM and an agent framework, create a rogue service account, query BigQuery for credentials and request more compute capacity.

None of these attacks depends on an organisation formally deciding that its AI infrastructure is privileged. Attackers make their own assessment. They look for the systems that give them credentials, execution, persistence or valuable resources, then follow the access those systems provide.

That creates an uncomfortable gap between architectural reality and security classification. A platform can be treated internally as application tooling while functioning, from an attacker's perspective, as a route into several different control domains.

Existing Security Controls Can Miss The Classification Problem

Most enterprises already have controls for applications, cloud environments, identities and secrets. The problem isn't necessarily that those controls don't exist. It's that responsibility for them can remain split across different teams while the AI layer connects the assets each team believes it is protecting separately.

An AI platform team may own the gateway. Cloud security may manage the service account behind it. Identity teams may govern credentials, while application security focuses on the exposed software. Each control can make sense in isolation, yet nobody has necessarily assessed what happens when those permissions and connections converge in one runtime.

Tenable's 2026 Cloud and AI Security Risk Report gives this problem some scale. Its telemetry found that 18 per cent of organisations had overprivileged IAM roles that AWS AI services could assume, including a 13 per cent critical exposure layer. It also found that 73 per cent of Amazon SageMaker roles and 70 per cent of Amazon Bedrock agent roles were inactive.

Those figures don't prove that every AI service is a privileged control point. They do show how easily powerful permissions can accumulate around AI services and then remain in place after their original purpose has faded. Cloud Security Alliance research adds another warning sign: only 12 per cent of surveyed organisations reported high confidence in preventing attacks through non-human identities, while more than 16 per cent said they didn't track the creation of new AI-related identities.

NIST has also warned that long-lived API keys, broadly scoped tokens and inherited access can become especially risky as agentic systems move across networks, tools and resources. The underlying identity problems aren't new. What changes is the speed and range with which AI systems can use the access they receive.

Classification affects how much scrutiny a system receives. If an AI component can reach privileged resources but is still reviewed like an ordinary application, the organisation may have all the right security disciplines and still apply them at the wrong level.

Treat Authority As The Trigger For Stronger Controls

A useful starting point is to stop asking whether a platform is technically an AI gateway, orchestrator, runtime or retrieval system. Those labels describe function. Security teams need a second view that describes authority.

Five questions can help expose when an AI component has crossed that line:

• Credential authority: What identities, API keys, tokens, database credentials or other secrets can the component access or retrieve?
• Execution authority: What can it cause another system to do, directly or through a workflow, tool or runtime?
• Reach: How many data sources, applications, cloud resources or external providers become reachable through it?
• Policy authority: Can it change routing, permissions, workflow behaviour or other decisions that affect downstream systems?
• Blast radius: If it is compromised, does the incident stay local, or does it create usable paths into several other environments?

No single answer automatically makes a system privileged. The pattern is more important. A gateway with one narrowly scoped credential and no execution capability presents a very different risk from an orchestrator that can reach multiple data stores, launch workflows, retrieve secrets and operate under a powerful cloud identity.

The more of those capabilities converge, the weaker an ordinary application-security classification becomes. At that point, the organisation should consider whether the component needs controls closer to those used for other privileged infrastructure.

Microsoft's guidance after its recent investigations offers a useful sense of what that stronger treatment can involve. It recommends treating AI gateways as Tier-0 secrets stores, restricting management interfaces, scoping provider credentials, applying least privilege, isolating databases, limiting outbound traffic and monitoring for suspicious execution or secret access originating from AI workloads.

The exact control set will depend on the architecture, but the order is important. First identify how much authority the component holds. Then decide whether access controls, segmentation, secrets handling, runtime monitoring and change management are strong enough for the consequences of losing it.

That avoids both extremes. Security teams don't need to declare every AI component critical infrastructure, but they also shouldn't wait for a product label to tell them when one has become a high-value control point.

AI Architecture Decisions Are Becoming Security Decisions

Centralising AI infrastructure isn't inherently a security mistake. In many cases, the opposite is true. Gateways and orchestration layers can improve visibility, standardise policy and reduce the number of unmanaged connections between applications and model providers.

But every centralisation decision changes the shape of risk. A gateway that becomes the approved route to several model providers may also become the place where provider credentials and routing policy converge. An orchestrator that simplifies automation can also become the component capable of triggering actions across several systems.

That trade-off needs to be visible when the architecture is designed, not discovered later during an incident. AI architecture reviews should consider accumulated privilege and downstream consequence alongside performance, functionality, interoperability and cost. The security question isn't simply whether the component itself is hardened. It's what authority the wider design has placed behind it.

This also makes AI security architecture a shared responsibility. CISOs and cloud security teams need visibility into how these platforms are built, while AI architects and platform teams need to understand when a useful integration creates a new privileged path. Neither side can assess the risk properly from its own layer alone.

As more enterprise AI systems connect to tools, data and operational workflows, those architecture choices will keep carrying more security consequence. The organisations that recognise privilege while they design the system have a much better chance of protecting it at the level its real role requires.

Final Thoughts: Secure AI Infrastructure For The Authority It Holds

An AI gateway can still be a gateway. An orchestration platform can still be workflow software. The point isn't to give every component a more dramatic label. It's to recognise when the architecture behind that label has changed what losing control of the component would actually mean.

Not every AI gateway, runtime or orchestrator belongs in the same security tier as an identity provider or cloud control plane. But some will increasingly hold credentials, execution rights, data access and downstream reach that make ordinary application treatment hard to justify.

That is the more useful test for privileged AI infrastructure: not what the system is called, but how much authority travels through it and how far an attacker could go if it were compromised.

As enterprise AI gains more tools, access and autonomy, the infrastructure coordinating those systems will become more consequential. Security teams therefore need to keep following the architecture as it changes, because yesterday's middleware can quietly become tomorrow's privileged control point.

EM360Tech will continue exploring how these shifts are changing the assumptions enterprise leaders use to design, govern and secure AI systems as they move deeper into day-to-day operations.