AI-SPM alone is not enough for securing AI workloads

At a glance

What this is: This is Aqua Security’s argument that AI-SPM is only a starting point for AI workload security, because posture visibility does not stop runtime abuse.

Why it matters: It matters because IAM, NHI, and security teams need controls that govern live AI behaviour, not only inventory and policy checks that miss exploitation in flight.

By the numbers:

• Aqua Security says runtime attacks against AI workloads have surged 400% as AI adoption has accelerated.
• IDC predicts more than 1 billion new AI applications will be live by 2028.

👉 Read Aqua Security's analysis of why AI-SPM alone does not secure AI workloads

Context

AI workload security is no longer just a visibility problem. As organisations embed LLMs and AI services into applications and APIs, the main gap is between knowing an AI asset exists and being able to stop it from being abused while it is running.

AI-SPM helps teams map usage, policies, integrations, and exposure, but that is posture, not protection. For IAM and security programmes, the practical issue is whether live AI interactions can be governed with the same discipline expected for workload identity, secrets, and privileged access.

Key questions

Q: How should security teams secure AI workloads beyond AI-SPM?

A: Security teams should use AI-SPM for discovery and policy visibility, then add runtime controls that can inspect and block live model interactions. The goal is to detect prompt injection, jailbreak attempts, and data leakage during execution, not after the session ends. Without that second layer, AI-SPM only describes risk; it does not contain it.

Q: Why do AI workloads need runtime controls if posture tools already show misconfigurations?

A: Because misconfiguration visibility does not stop exploitation in flight. AI attacks often happen during active prompt, tool, and data interactions, which means attackers can abuse a system even when the posture report looks clean. Runtime controls matter when the system can make or receive decisions in production, not just when it is being assessed.

Q: What do organisations get wrong about AI-SPM?

A: They often treat AI-SPM as a complete security strategy instead of a starting point. AI-SPM is useful for mapping models, integrations, and policy adherence, but it does not enforce behaviour once the AI system is live. The common mistake is confusing governance visibility with containment capability.

Q: How do runtime AI controls differ from cloud posture management?

A: Cloud posture management identifies weak configurations, while runtime controls intervene during active execution. In AI security, that difference matters because prompt injection and leaky outputs are dynamic abuse patterns, not static misconfigurations. Teams need both layers, but only runtime defence can stop a malicious interaction as it happens.

Technical breakdown

Why AI-SPM stops at posture visibility

AI-SPM is a posture management layer for AI systems. It inventories models, services, data flows, and policy adherence, similar to how CSPM inventories cloud misconfigurations. That matters because teams cannot govern what they cannot see. But posture data is retrospective and static. It tells you what is deployed and how it is configured, not whether an attacker is actively manipulating prompts, abusing context windows, or chaining integrations during execution.

Practical implication: treat AI-SPM as discovery and governance input, not as a control that can contain live misuse.

Why runtime attacks bypass static AI controls

Prompt injection, model inversion, and leaky outputs are runtime failure modes. They emerge only when the model is interacting with users, tools, or data, which is why static scans and logs miss them. Security controls that do not observe the live request-response path cannot reliably detect manipulation of prompts or prevent sensitive data disclosure once execution begins. The same pattern appeared in cloud security: visibility found risk, but runtime protection reduced exploitability.

Practical implication: add live inspection and enforcement for prompt, tool, and data access paths where AI systems execute.

How AI workload security mirrors the cloud posture-to-runtime shift

The architectural lesson is familiar. CSPM improved cloud hygiene, but workload protection closed the gap by enforcing controls at execution time. AI security is following the same pattern. AI-SPM maps the estate, while runtime defence must intercept unsafe behaviour in production. That includes blocking malicious prompts, stopping jailbreak attempts, and preventing insecure access to sensitive data without requiring code changes.

Practical implication: align AI security ownership across posture, runtime, and identity controls instead of assigning the problem to one team.

NHI Mgmt Group analysis

AI-SPM is a visibility layer, not a security boundary. It can show which models, services, and policies exist, but it cannot by itself stop misuse during a live session. That distinction matters because AI workloads are now being treated like production identity-bearing systems, not static software assets. Practitioners should stop equating inventory with control.

Runtime AI abuse is an identity problem as much as an application problem. When an AI service can access data, tools, or downstream systems, the question becomes who or what is allowed to act at runtime and under what conditions. That puts AI workload governance squarely alongside NHI, PAM, and access policy enforcement, not just application security review.

Static guardrails fail when attacker behaviour adapts faster than policy review cycles. The article’s core premise is that prompt injection, jailbreaks, and leaky outputs happen in execution, where posture tools are blind. The implication is that security programmes need to judge AI controls by runtime containment, not by how complete the inventory looks.

Model Context Protocol-style integrations widen the practical blast radius of AI systems. Once a model can reach tools, data sources, or services, the trust chain extends beyond the model itself into the identity and authorisation model around it. Teams should evaluate the permissions attached to AI-connected workflows as carefully as any privileged service account.

AI-SPM and runtime defence are complementary only when the operating model is clear. One tells you what exists, the other constrains what can happen in production. Security leaders should map both to the same governance owner so the organisation does not end up with clean posture reports and uncontrolled execution.

From our research:

• From our research: Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.
• For the broader control problem, read OWASP NHI Top 10 for the runtime risks that posture tools alone cannot contain.

What this signals

Posture visibility will not close the AI governance gap unless organisations can also observe live execution. As AI systems gain access to tools and data, the control question shifts from what exists to what can happen in-session. Teams should expect AI security ownership to converge with NHI governance, privileged access management, and workload identity controls.

The operational signal is clear: AI-SPM is becoming the discovery layer, while runtime defence becomes the enforcement layer. Security leaders who separate those responsibilities early will have a better path to scaling AI safely without turning every new use case into a blind spot.

AI-connected services should now be treated as part of the identity perimeter, especially where tool use or data access is involved. For teams building that perimeter, the OWASP Agentic AI Top 10 is a useful way to map the controls that need to move from policy to runtime.

For practitioners

• Separate AI discovery from AI enforcement Use AI-SPM to inventory models, services, and data paths, then define a distinct runtime control layer for live prompt and tool activity. Do not let the posture dashboard become the only governance artefact.
• Inspect live prompt and tool traffic Instrument the execution path so you can detect prompt injection, jailbreak attempts, and sensitive data leakage while the session is active. Controls that only analyse logs after the fact are too late for containment.
• Treat AI-connected services as identity-bearing workloads Review the permissions granted to models, orchestration layers, and connected tools with the same scrutiny used for privileged service accounts and workload identities. If an AI system can call APIs or retrieve data, its access scope must be explicit.
• Map governance ownership across security and platform teams Assign one owner for posture visibility, runtime enforcement, and incident response so AI controls do not fragment across separate programmes. Without shared ownership, AI-SPM will expose risk that no team is empowered to contain.

Key takeaways

• AI-SPM improves visibility, but visibility alone does not stop prompt injection, jailbreaks, or leaky outputs during live execution.
• The gap is operational, not theoretical: runtime attacks against AI workloads are rising while many organisations still cannot audit AI data access end to end.
• Security teams need a two-layer model for AI workloads, with posture management for discovery and runtime enforcement for containment.

Key terms

• AI-SPM: AI security posture management is the process of discovering AI models, services, integrations, data flows, and policy gaps. It gives teams a baseline view of how AI is deployed, but it does not itself enforce behaviour during live execution or stop abuse in real time.
• Runtime defence: Runtime defence is the set of controls that monitor and enforce behaviour while an AI system is actively processing prompts, calling tools, or handling data. It exists to catch abuse that static scanning cannot see, such as prompt injection, jailbreak attempts, and sensitive output leakage.
• Shadow AI: Shadow AI is the use of AI models or services that security teams have not fully discovered, approved, or governed. It becomes a control problem when hidden AI usage connects to business data, APIs, or workflows without the oversight normally expected for identity-bearing systems.
• AI workload identity: AI workload identity is the identity and access model attached to a model, orchestration layer, or AI service that can act on behalf of a system. It matters because once AI can reach data or tools, its access scope must be governed like any other privileged workload.

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 maturity in your organisation, it is worth exploring.

This post draws on content published by Aqua Security: Why AI-SPM Alone is Not Enough to Secure AI Workloads. Read the original.