AI infrastructure security must catch up with federal AI adoption

At a glance

What this is: This analysis argues that federal AI rollout is outpacing the security and compliance controls needed to govern the infrastructure beneath it.

Why it matters: It matters because IAM, cloud, and NHI teams have to secure the platforms that host AI workloads before adoption speed turns into unmanaged exposure.

Context

Federal AI adoption is creating a governance gap that traditional cloud and compliance programmes were not designed to absorb. The issue is not just access to frontier models, but the infrastructure underneath them, including cloud accounts, Kubernetes estates, and the controls that decide whether AI systems can be trusted in production.

Orca Security frames the problem as one of speed, scale, and control overlap: agencies are expected to move quickly, maintain regulatory discipline, and protect critical AI assets at the same time. That combination makes AI infrastructure security a prerequisite for delivery, not a follow-on hardening task.

Key questions

Q: How should federal teams secure AI infrastructure without slowing delivery?

A: Start by governing the cloud and Kubernetes layers that host AI systems, not just the models themselves. The fastest path is to combine continuous asset discovery, permission review, and compliance evidence so deployment speed does not outpace visibility. That keeps security decisions close to runtime reality.

Q: Why does AI infrastructure create more risk than a standalone AI tool?

A: Because the infrastructure inherits cloud entitlements, service identities, and deployment drift that can turn a single AI workload into a wider access path. The risk is compounded when those paths lead to shared data, orchestration services, or production environments that support multiple missions.

Q: What breaks when AI risk reviews are done only at deployment time?

A: You miss the behaviour that appears after launch. Models change, prompts are edited, connectors are added, and a previously acceptable workflow can become risky without any formal re-review. Static assessment creates stale assurance, which is especially dangerous when the system can act faster than a human can intervene.

Q: How do NIST CSF and NIST SP 800-53 apply to federal AI environments?

A: They provide the governance and control language for monitoring, access management, and evidence collection across the infrastructure that AI depends on. Federal teams should use them to align cloud and workload security with continuous compliance, rather than treating AI as a separate exception path.

Technical breakdown

Why AI infrastructure becomes the real control plane

AI infrastructure is the layer where cloud permissions, Kubernetes workloads, application code, and model-adjacent services meet. In practice, the risk is rarely the model alone. It is the identity and configuration sprawl around it, including broad cloud entitlements, exposed service paths, and weak linkage between deployment artifacts and runtime risk. CNAPP-style visibility matters here because AI systems inherit the security posture of the environments they run in. When agencies scale AI quickly, the governing problem becomes whether they can see and rank exposure across multi-cloud and container estates before those systems become operational dependencies.

Practical implication: map AI workloads to the cloud and cluster controls that actually govern them, rather than treating the model layer as the only asset.

How compliance reporting changes in fast-moving AI estates

The article’s compliance theme is about continuous evidence, not periodic paperwork. AI infrastructure deployed across agencies and public-sector environments has to satisfy existing frameworks while remaining auditable as services change. That means security teams need a control view that keeps pace with infrastructure drift, not one that depends on manual review cycles after deployment. Continuous monitoring and automated compliance reporting reduce the gap between implementation and evidence. For federal teams, that is especially important when procurement, oversight, and technical operations are split across different stakeholders.

Practical implication: tie AI infrastructure monitoring to compliance evidence generation so control validation moves at deployment speed.

Attack-path analysis for critical AI assets

Attack-path analysis is useful because it shows how low-severity issues can combine into a path to mission-critical AI systems. In AI environments, a misconfiguration, weak permission boundary, or exposed workload can matter more when it sits on the route to a high-value model, dataset, or orchestration service. Context-aware prioritisation helps teams separate noise from true exposure by focusing on combinations of risk rather than isolated findings. That is the right model for public-sector AI, where the operational cost of alert overload is high and the tolerance for blind spots is low.

Practical implication: prioritise remediation based on attack paths to crown-jewel AI systems, not on isolated scanner output.

Threat narrative

Attacker objective: The attacker wants to reach AI infrastructure and the crown-jewel systems it supports before defenders can fully map or govern the exposure.

1. Entry begins when AI infrastructure is exposed through broad cloud, Kubernetes, or application paths that expand the attack surface faster than teams can review it.
2. Escalation occurs when misconfigurations, excessive permissions, or unmanaged dependencies combine into a route toward higher-value AI services and underlying data.
3. Impact is the compromise of critical AI assets, compliance posture, or operational trust in systems that agencies now depend on for mission delivery.

Breaches seen in the wild

• ShadowRay 2024: Attackers took over internet-exposed Ray AI clusters via the disputed CVE-2023-48022, exposing cloud keys, AI API tokens and GPU compute.
• LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI infrastructure security is now the governance layer, not a supporting control. Federal AI adoption does not create a separate security domain so much as it concentrates cloud, workload, and access risk into one operational plane. The practical issue is whether agencies can govern that plane continuously, not whether they can bolt controls on after deployment. Practitioners should treat AI infrastructure as the place where identity, configuration, and compliance meet.

Attack-path thinking matters more than isolated findings in public-sector AI estates. AI systems rarely fail because of one defect alone. They fail when cloud permissions, container exposure, and service-to-service dependencies line up into a route to mission-critical assets. That is why context-aware prioritisation is more defensible than scanner volume as a security signal.

Continuous compliance is becoming a delivery requirement for AI programmes. The article reflects a broader shift: agencies are expected to move faster without relaxing control evidence. That means manual review cycles will increasingly lag behind operational reality. Security teams should expect compliance reporting to move closer to runtime evidence and away from after-the-fact validation.

AI infrastructure visibility is the new scarcity in federal environments. The limiting factor is no longer whether AI tools exist, but whether defenders can see multi-cloud and Kubernetes exposure quickly enough to govern it. That scarcity makes infrastructure discovery, entitlement review, and risk ranking the practical foundations of AI assurance.

Identity blast radius: AI infrastructure turns ordinary cloud permissions into mission risk when they sit on the path to high-value models, data, and orchestration services. The implication is that agencies need to reason about where access can lead, not just who has it at provisioning time.

From our research library:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: AI Infrastructure Workload Identity Guide

What this signals

Identity blast radius: Federal AI programmes should expect permissions to matter more than model choice because the infrastructure layer determines how far compromise can travel. When cloud roles, Kubernetes service identities, and application paths converge, the relevant control is not a one-time approval but a continuously current view of reachable access.

The more AI systems are operationalised across public-sector estates, the more security teams will need to combine runtime visibility with compliance evidence. That is the only practical way to keep pace when AI-related credential leaks surged 81.5% year-over-year in 2025, according to the State of Secrets Sprawl 2026.

Agencies that separate AI governance from cloud governance will end up with blind spots in both. The better programme view is to treat AI infrastructure as part of the core identity and access surface, then manage it with the same rigour used for privileged cloud operations.

For practitioners

• Map AI workloads to the underlying cloud estate Inventory which cloud accounts, Kubernetes clusters, and application services support AI initiatives, then assign ownership for each layer so security reviews do not stop at the model boundary.
• Prioritise attack paths to crown-jewel AI assets Rank findings by whether they create a route to mission-critical AI systems, shared data stores, or orchestration services instead of triaging every issue as equal.
• Automate compliance evidence for AI infrastructure Tie monitoring to reporting for NIST CSF and NIST SP 800-53 so control validation keeps pace with rapid deployment and infrastructure drift.
• Review permissions that bridge AI and non-AI estates Look for cloud roles, Kubernetes service identities, and application paths that allow AI workloads to inherit broader access than their business function requires.
• Shorten the time between detection and remediation Use continuous monitoring and context-aware prioritisation to move from broad exposure lists to targeted fixes on the findings that actually threaten AI mission systems.

Key takeaways

• Federal AI adoption shifts the security problem to the infrastructure layer, where cloud, Kubernetes, and access paths determine the real exposure.
• The article’s core message is that compliance and velocity can coexist only if visibility and evidence generation are built into AI operations from the start.
• Practitioners should prioritise the routes that lead to mission-critical AI systems, because those attack paths matter more than isolated scanner results.

Key terms

• AI Infrastructure Security: AI infrastructure security is the discipline of protecting the cloud, Kubernetes, data, identity, and application layers that support model development and deployment. It treats AI systems as part of the broader enterprise attack surface, with access paths and control evidence that must be continuously governed.
• Attack Path Analysis: Attack Path Analysis is the process of mapping how an attacker could move from an initial foothold to a valuable target. It examines identities, permissions, network reachability, misconfigurations, and trust relationships to identify realistic routes of compromise. The goal is to prioritize controls that break the shortest and most likely paths.
• Continuous Compliance Monitoring: Continuous compliance monitoring is the ongoing collection and review of control status, exceptions, and remediation evidence. It replaces periodic spot checks with live or near-real-time visibility so organisations can detect drift before it becomes a regulatory or audit issue.
• Crown-Jewel Asset: A crown-jewel asset is a system, dataset, or service whose compromise would create the most serious operational, financial, or regulatory harm. The term is used to prioritise security effort, privilege controls, and recovery planning around material business impact rather than equal treatment of every asset.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.