AI container security starts inside the workload, not at the edge

At a glance

What this is: This is Aqua Security’s analysis of why AI container security must focus on runtime behaviour inside the workload, where attacker actions and AI-specific telemetry actually appear.

Why it matters: It matters because IAM, NHI, and platform teams increasingly need to govern AI workloads as containerised identities with runtime privileges, not just as models behind perimeter controls.

By the numbers:

• Aqua Security protects over 500 of the world’s largest enterprises.

👉 Read Aqua Security’s analysis of AI container security inside the workload

Context

AI container security is the discipline of watching and controlling what happens inside the running workload, not just filtering traffic at the edge. For AI environments, that matters because the container often holds the model runtime, the plugin chain, external API calls, and the sensitive data paths that perimeter tools do not fully see.

The article’s core point is that AI security becomes an identity and runtime governance problem once models, plugins, and orchestration tools execute inside containers. That has direct implications for NHI governance, workload identity, and operational visibility across production environments.

Key questions

Q: How should security teams monitor AI workloads inside containers?

A: They should monitor the workload at runtime, not just the perimeter. That means collecting process, network, file, and policy telemetry from inside the container so suspicious behaviour is visible after deployment. This is the only way to catch malicious plugins, unsafe tool use, and hidden outbound activity that static scans and proxy layers miss.

Q: Why do AI workloads create more runtime risk than static application scans capture?

A: Because the risky event often happens after start-up, when the workload can call tools, reach external services, or act on injected input. Static scans tell you what was built, not what the running container is doing. Runtime control is what exposes privilege escalation, lateral movement, and data access in motion.

Q: What breaks when AI security stops at the edge?

A: Edge filtering can reduce exposure, but it cannot reliably see inside the container where the model, plugin chain, and orchestration logic operate. If the attacker arrives through a poisoned component or manipulates runtime behaviour, edge controls are already too far away to explain or contain the action path.

Q: How can teams reduce shadow AI risk in production?

A: They need a complete inventory of AI workloads, their owners, their data dependencies, and the external services they reach. Without that inventory, shadow AI behaves like unmanaged non-human identity: it can consume credentials and interact with sensitive systems without lifecycle oversight.

Technical breakdown

Why container runtime visibility matters for AI workloads

Containerised AI systems inherit the same runtime risks as other cloud-native workloads, but with more dynamic behaviour and more external dependencies. Static scanning can catch some bad images or known vulnerabilities, yet it cannot observe what a model server, plugin, or orchestration tool does after start-up. Runtime telemetry inside the container gives defenders context on outbound calls, suspicious file access, process spawning, and policy violations. That context is what turns AI security from assumption into evidence-based control.

Practical implication: instrument the workload itself so you can detect behaviour after deployment, not only before release.

Prompt injection can become a runtime compromise path

Prompt injection is often described as a content problem, but inside a container it can become a control-flow problem. If an injected prompt influences a tool-using component, the result can be malicious API calls, privilege escalation, or movement into adjacent services. The weakness is not the text alone. It is the willingness of the runtime to execute unsafe actions based on untrusted input. That is why AI security inside containers has to inspect behaviour, not just prompts.

Practical implication: treat prompt injection as an execution risk and monitor the downstream actions it triggers.

Supply chain and misconfiguration remain the easiest entry points

The article reinforces a familiar cloud-native pattern: attackers still start with weak configuration, exposed services, or malicious components in the supply chain. A poisoned plugin or compromised model server already inside the workload bypasses perimeter assumptions and can operate at runtime. In AI environments, the model is not the only object that matters. The surrounding container image, dependencies, and orchestration path can all become the real attack surface.

Practical implication: review image provenance, plugin trust, and exposed services as part of AI workload hardening.

Threat narrative

Attacker objective: The attacker aims to turn an AI workload’s runtime trust into access, control, and downstream movement inside the containerised environment.

1. Entry begins when an attacker reaches a misconfigured AI workload, exposed database, or containerised orchestration tool, or when a poisoned plugin is introduced into the runtime environment.
2. Escalation occurs when the malicious component or injected prompt influences the container to call external services, access sensitive data, or execute unauthorised actions inside the workload.
3. Impact follows when the runtime behaviour spreads into privilege escalation, lateral movement, or rootkit-like persistence within the AI container stack.

Breaches seen in the wild

• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.
• JetBrains GitHub plugin token exposure — CVE-2024-37051 in JetBrains IntelliJ GitHub plugin exposed GitHub access tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI container security is a runtime identity problem before it is a model problem. The article shows that the important question is not only what the model answers, but what the workload is authorised to do once it starts executing. That shifts attention from prompts and proxies to the identity, behaviour, and telemetry of the running container. Practitioners should treat container runtime as the control plane for AI workload risk.

Runtime visibility gap: the problem is not absence of tooling, but absence of evidence. Security teams often cannot say with confidence where AI is running, which workloads touch external APIs, or whether shadow AI is already in production. That is a governance failure because inventory and ownership are prerequisites for any meaningful control. The implication is that AI security programmes need a verifiable runtime map before they can claim coverage.

Container-layer defence restores the control boundary that edge filtering cannot provide. Static scans, SDK controls, and proxy filters all operate too far from the execution point to explain malicious behaviour inside a live workload. The article’s core lesson is that enforcement must observe the container where AI applications actually run and interact with sensitive data. For identity leaders, this means aligning workload identity, runtime monitoring, and policy enforcement as one operating model.

Shadow AI becomes an unmanaged workload identity problem once developers can deploy without central visibility. The article’s references to unknown models and external API use show that untracked AI behaves like any other unmanaged non-human identity: it consumes credentials, reaches out to services, and escapes standard review cycles. That is why the governance issue is lifecycle ownership, not just detection. Practitioners should treat AI workloads as identities that must be discoverable, attributable, and controllable.

AI security at scale will converge with cloud-native security rather than replace it. The same container patterns used for workload protection, drift detection, and escape prevention now apply to AI. What changes is the runtime semantics, not the need for core controls. The practical conclusion is that organisations should extend existing cloud-native governance to AI workloads instead of building a parallel security stack.

From our research:

• 69% of organisations now have more machine identities than human ones, according to The Critical Gaps in Machine Identity Management report.
• Only 38% have automated certificate lifecycle management in place, which leaves most machine identities dependent on manual governance.
• For a broader identity baseline, see Ultimate Guide to NHIs , Key Challenges and Risks for the visibility and sprawl issues that containerised AI often inherits.

What this signals

Runtime telemetry is becoming the deciding control for AI workload governance. Teams that can see only image provenance or edge traffic will miss the behaviour that actually creates exposure inside the container. That is why container observability, workload identity, and policy enforcement now need to move together, not as separate programmes.

Shadow AI should now be treated as unmanaged workload identity, not just rogue usage. Once a developer can deploy an AI service without central visibility, the programme has an identity inventory problem, an ownership problem, and a lifecycle problem at the same time. The practical next step is to unify AI discovery with NHI governance and access oversight.

With 69% of organisations already running more machine identities than human ones, the operational burden of AI workloads will rise faster than manual review cycles can absorb. Container security teams should prepare for identity sprawl, not assume it will stay bounded by the application layer.

For practitioners

• Instrument runtime behaviour inside AI containers Deploy controls that observe process execution, outbound connections, sensitive file access, and policy violations from inside the workload. Do not rely on perimeter controls alone to explain what the AI system is doing after start-up.
• Inventory all deployed AI workloads and owners Build a live inventory of models, orchestration tools, plugins, and external API dependencies, then assign an accountable owner to each workload. Shadow AI cannot be governed if it is not discoverable.
• Review AI supply chain trust before production Validate container images, plugin sources, and model-server dependencies before release, and treat any poisoned component as a runtime compromise vector. The goal is to stop malicious code from arriving inside the container at all.
• Correlate AI telemetry with identity and access logs Join container telemetry to access records so you can see which credentials, service accounts, or tokens were used when the workload reached external systems. That correlation is essential for incident triage and ownership.

Key takeaways

• AI workload risk often emerges inside the container, where runtime behaviour is visible and perimeter-only controls are not.
• Identity inventory, ownership, and telemetry are now core requirements for governing containerised AI at scale.
• Teams that align workload identity with runtime monitoring will be better positioned to contain malicious components, shadow AI, and prompt-driven abuse.

Key terms

• Container Runtime Telemetry: Container runtime telemetry is the stream of behavioural data collected from a running workload, such as process activity, network connections, and file access. For AI systems, it shows what the workload actually does after deployment, which is essential when prompts, plugins, and external APIs can change behaviour at runtime.
• Shadow AI: Shadow AI is AI software or agentic capability used in an organisation without central approval, inventory, or governance. It often appears as a developer-built service, a hidden orchestration layer, or an unmanaged model endpoint. The security problem is not only use, but the absence of lifecycle ownership and access oversight.
• Workload Identity: Workload identity is the machine identity assigned to a running service, container, or application so it can authenticate to other systems. In AI environments, it ties runtime execution to credentials, permissions, and policy, making it a core control for both access governance and incident attribution.
• Runtime Enforcement: Runtime enforcement is the set of controls that observe and block unsafe actions while software is running, not just before release. For AI containers, this includes detecting suspicious process behaviour, outbound access, and policy violations in the live workload where malicious actions actually occur.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance in your organisation, it is worth exploring.

This post draws on content published by Aqua Security: AI Container Security Begins Inside the Workload. Read the original.