Topic starter
25/06/2026 1:10 am
TL;DR: AI security in production still lacks clear visibility, policy enforcement, and runtime control where models actually run, according to Aqua Security, even as 70% of AI applications are deployed in containers and 97% of security organisations plan to increase spending on securing AI use cases. The governance problem is no longer model experimentation; it is securing AI workloads as operational assets with enforceable controls.
Editorial analysis by NHI Mgmt Group, based on content published by Aqua Security: “Operationalizing AI Security: Protecting Workloads Where AI Runs”.
By the numbers:
- Over 70% of AI applications are deployed in containers, running on Kubernetes and cloud native infrastructure, according to Aqua Security.
- 97 percent of security organizations plan to increase spending on securing AI use cases, according to Aqua Security.
Key questions
Q: How should security teams govern in-house AI inference workloads?
A: Security teams should govern in-house AI inference workloads as non-human identities with scoped permissions, named ownership, and lifecycle controls.
Q: Why do AI firewalls and SDK controls leave gaps in production governance?
A: They sit too far from the execution layer to guarantee complete coverage.
Q: What are the signs that AI security controls are not reaching the runtime layer?
A: A common sign is that teams can describe AI usage at the application level but cannot say which model is running, where it is deployed, or how policy is enforced during execution.
Practitioner guidance
- Define the AI workload as the control boundary Document which production services host inference, handle prompts, or touch sensitive data, then assign those services to your security governance model.
- Validate runtime policy enforcement coverage Test whether controls can block or allow AI behaviour while execution is happening, not just report on it after the fact.
- Map AI workloads to existing cloud-native protections Reuse container, Kubernetes, and workload identity patterns where they already exist, but verify they cover the AI execution path rather than only the surrounding platform.
Bottom line: AI security in production is no longer mainly about model experimentation. The harder problem is governing the workloads where inference, prompts, and data access happen.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 10:23 am
AI workload governance fails when security stops at the interface. The article shows that prompt-side controls and application SDKs do not fully govern the environment where inference and data handling occur. That creates a runtime governance gap rather than a simple detection problem. Practitioners should treat the workload layer as the real enforcement boundary.
A few things that frame the scale:
- Only 23% of IT leaders were very confident in their organisation's ability to manage security and governance for GenAI deployments, according to a 2025 Gartner survey of 360 IT leaders.
A question worth separating out:
Q: Should organisations prioritise workload-level AI security over prompt-level controls?
A: Yes, when the production risk comes from how models run inside containerised services. Prompt-level controls can help at the edge, but workload-level security is what determines whether policy can be enforced where inference, data access, and execution decisions actually happen.
👉 Read our full editorial: Operationalizing AI security for workloads where models run