AI-SPM alone is not enough for securing AI workloads

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Aqua Security's blog post: AI-SPM is a necessary visibility layer for AI workloads, but it does not stop runtime abuse, exfiltration, or jailbreak-style attacks.

Why it matters: IAM, security architecture, and platform teams need to treat AI posture management as only one control layer, because runtime enforcement is where real-world abuse is contained across AI services and agent-adjacent workflows.

Context

AI-SPM is posture management for AI environments. It helps teams discover models, data flows, policy drift, and shadow AI across applications and services, but it does not itself block abuse once a system is live.

The security gap is simple: static visibility can identify where AI is being used, yet prompt injection, model inversion, and sensitive-output leakage happen at runtime. For AI governance programmes, that means posture control and live enforcement are different jobs, not interchangeable ones.

This article is about AI workloads consumed by applications or exposed through APIs, which makes it relevant to AI security, cloud-native security, and governance of non-human software behaviour.

Key questions

Q: What breaks when AI-SPM is used without enforcement controls?

A: Visibility alone does not stop leakage. If a posture tool shows that an agent can reach customer or HR data, the risk remains until something intercepts or reshapes the data before it moves. Without enforcement, organisations get reports instead of protection, and an over-permissioned agent can still pull, reveal, or transmit sensitive information.

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: How do security teams know whether AI access is actually working safely?

A: Look for three signals: complete discovery of the AI estate, clear mapping of source data to each system, and logs that prove what was accessed and why. If any of those are missing, the control environment is incomplete. Safe AI access is evidenced, not assumed.

Q: What is the difference between AI-SPM and runtime AI defence?

A: AI-SPM identifies what AI exists, how it is configured, and where policy drift appears. Runtime AI defence watches the live session and can stop malicious prompts, unsafe tool use, or sensitive-output leakage while the system is running.

Technical breakdown

Why AI-SPM stops at posture, not protection

AI-SPM is the discovery and governance layer for AI usage. It tells teams which models are in play, how data moves, and where policies are being followed or broken. That is valuable because many organisations do not yet have a reliable AI inventory. But posture tooling is inherently snapshot-based. It can show risk, document drift, and support governance decisions, yet it cannot intercept a hostile prompt, block a jailbreak, or prevent a model from returning an unsafe response during a live session.

Practical implication: Use AI-SPM to establish inventory and policy baselines, but do not treat it as a runtime control.

Why runtime attacks bypass static AI security checks

Prompt injection, model inversion, and leaky outputs are execution-time attacks. They exploit the moment when an AI system is interacting with users, tools, or data, which is outside the reach of a static scan or a periodic compliance check. The article’s broader point mirrors the cloud security shift from CSPM to workload protection: visibility can find misconfiguration, but only runtime controls can react while the attack is happening. That distinction matters because adversaries adapt quickly and chain prompts, context windows, and integrations in-session.

Practical implication: Place enforcement where the model runs, not just where it is configured.

How AI workload security extends from code to prompt

A full AI workload security model has three layers: development-time scanning, preventative guardrails, and runtime defence. The first two reduce the chance of unsafe AI usage entering production, while the third watches live behaviour and can stop suspicious actions without code changes. That architecture is important because AI systems are not static endpoints. They are interactive services with changing context, external tools, and data access. Security must therefore cover the full lifecycle from code to prompt to production, not just the pre-deployment phase.

Practical implication: Design AI security so that code review, policy enforcement, and live blocking work as separate controls.

Threat narrative

Attacker objective: The attacker wants to coerce the AI system into unsafe disclosure or behaviour that posture controls failed to stop.

1. Entry occurs when a user or external prompt reaches an AI service that is already exposed through an application or API.
2. Escalation happens when the prompt manipulates context, bypasses intended guardrails, or steers the model into unsafe behaviour.
3. Impact follows when the model exposes sensitive data, performs an insecure action, or returns a leaky output that propagates into the application workflow.

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.
• Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent 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-SPM is a discovery control, not a complete security boundary: It gives organisations the map they need, but not the ability to stop abuse once an AI service is live. That makes it useful for inventory and policy visibility, yet insufficient for runtime security on its own. Practitioners should treat it as one layer in an AI security stack, not the stack itself.

Runtime defence is where AI security becomes operational: Prompt injection and leaky outputs are not posture defects in the abstract, they are live execution problems. The governance lesson is that a policy which cannot intervene during inference has limited value against adaptive attackers. Security teams should measure control effectiveness by what they can block at runtime, not only by what they can discover beforehand.

AI security is converging with workload identity governance: As AI services are exposed through APIs and integrated into applications, their risk profile starts to resemble other non-human workloads. The named concept here is prompt-to-production exposure gap: the distance between a safe-looking configuration and an unsafe live interaction. Close that gap with controls that govern behaviour at execution time, not only at deployment time.

The cloud security pattern is repeating in AI, but faster: CSPM taught the industry that visibility into misconfiguration is not the same as workload protection. AI-SPM sits in the same position today. The practical consequence is that governance programmes built only around static review will lag behind adversaries who can change prompts and abuse integrations in minutes.

AI adoption is expanding faster than static control models can absorb: The article describes a security model under pressure from rapid deployment, shadow AI, and increasingly exposed AI services. That combination changes the operating assumption from ‘we can review this later’ to ‘we need to control this while it is running.’ Teams that keep AI security in the posture category will inherit the blind spots that runtime defence was meant to close.

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: Agentic AI Security Guide

What this signals

Prompt-to-production exposure gap: AI teams are moving faster than their governance controls, which means the highest-risk failures now occur between configuration review and live inference. Security programmes should assume that discovery alone will not contain misuse once AI is exposed through applications and APIs.

The practical shift is to treat AI posture as a baseline and runtime enforcement as the actual control boundary. That is the same lesson cloud security learned when inventory controls proved insufficient against active abuse, and it is now repeating in AI operations with even less time to react.

For practitioners

• Define AI-SPM as a discovery layer Use AI-SPM to inventory models, data paths, policy drift, and shadow AI, but document that it does not terminate live attacks or unsafe outputs.
• Add runtime enforcement to AI services Deploy controls that can detect and block prompt injection, jailbreak attempts, and sensitive-data leakage during inference without requiring code changes.
• Separate preventive and live controls Assign development-time scanning to code review and security gates, then assign runtime defense to session-level monitoring and intervention.
• Track AI workload exposure continuously Maintain an always-current view of which AI models, platforms, and versions are active across environments so governance does not depend on stale reports.

Key takeaways

• AI-SPM gives organisations visibility into AI usage, but it does not stop live abuse, unsafe prompts, or leaky outputs.
• Runtime defence becomes the decisive control when AI systems are exposed through applications, tools, and APIs.
• Teams should separate discovery, policy enforcement, and live blocking so AI governance works at both design time and execution time.

Key terms

• AI-SPM: AI Security Posture Management extends security visibility into AI models, prompts, outputs, and supporting workflows. It gives teams a way to identify risky AI usage, check policy alignment, and monitor how AI systems interact with data and identity controls over time.
• Runtime Defense: Runtime defense is the set of controls that inspect, constrain, and stop unsafe AI behavior while the system is operating. For hospitality deployments, it covers both incoming prompts and outgoing responses, plus the tool calls that agents may trigger after a model decides to act.
• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.

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.