AI-SPM Finds the Risk. What Stops the Attack?

When a hostile instruction reaches an AI system in your environment, what actually stops it from becoming a breach?

Most AI security programmes answer a different question. They ask: “Where is AI running, and where is the exposure?” That is a necessary question but not a sufficient one. The real security question is what happens when an attacker, malicious prompt, or compromised interaction actually reaches the system.

Can the activity be detected?
Can the action be blocked?
Can least privilege controls limit which systems, applications and data the AI system can access?
Can sensitive data be prevented from leaving its intended boundary?

That is where the gap between AI security posture and AI security protection becomes important.

AI Security Posture Management (AI-SPM) is primarily a visibility and posture capability. Where Cloud Security Posture Management (CSPM) examines cloud infrastructure for exposure and misconfiguration, AI-SPM extends its posture visibility into the AI layer: identifying models, managed AI services, agents and their relationships, assessing configuration and exposure, and highlighting conditions that could enable or amplify an attack.

The scale of this challenge is becoming clearer as organisations rapidly adopt AI across their cloud environments. Wiz Research's State of AI in the Cloud 2026 report highlights that 81% of organisations use managed AI services and 90% run self-hosted AI, with 57% deploying self-hosted AI agents and 80% adopting Model Context Protocol (MCP) servers.

Another important finding is that AI is not always deliberately deployed by an organisation. Wiz reported that 68% of organisations running self-hosted models ingest them through third-party software, therefore inheriting risks associated with those tools. Security teams can't assess the posture of AI they don't know exists, which is why inventory comes first.

What AI-SPM tells you, then, is where your AI is, how it is configured, what it can reach and which of those conditions create exposure. Posture assessment alone does not show how the AI systems behave during live interactions. A well-configured AI application can still be manipulated through prompt injection, leak sensitive data through its outputs, or be steered by a compromised tool into taking actions nobody intended. An agent with correctly scoped permissions can be manipulated into using its access in a way that no one intended. These are runtime problems. Posture management examines how things are set up, which exposes the weaknesses an attacker could exploit, but it doesn't watch what happens when someone actually tries. AI-SPM shows you where the risk is. To see an attack as it unfolds, you need runtime controls that detect and, where appropriate, block and constrain malicious activity. You cannot secure what you cannot see. Visibility is the first step.

Several AI-SPM findings map closely to risks identified in published security guidance:

Shadow and transitive AI. Unauthorised or previously unknown models, services and agents operating outside established controls. This also includes AI capabilities arriving indirectly through third-party software.

Exposed inference surface. When model endpoints, weights, and repositories, are reachable by unauthorised parties, they can create opportunities for models to be invoked, copied, or modified.

Excessive permissions. Agents holding broader access than their function requires create a larger blast radius if the agent is manipulated or compromised.

This maps to LLM06 Excessive Agency in the OWASP Top 10 for LLM Applications 2025, where excessive functionality, permission or autonomy can allow an influenced model to take harmful actions. It also relates to ASI03 Identity and Privilege Abuse in the OWASP Agentic Top 10, where agents misuse credentials, tokens, or inherited permissions to reach systems and data beyond intended scope.

Sensitive-data reachability. Models connected to sensitive datasets in ways that create an unintended path to disclosure. The question is not simply whether the model can access the data. It is whether it needs that access, under what conditions, and what prevents that access from being abused.

Weak controls on training and retrieval data. Vector stores, indexes and training datasets that can be read or modified by unauthorised parties can introduce another attack path.

This relates to LLM08 Vector and Embedding Weaknesses, from OWASP top 10 for LLM Applications 2025.

Each finding listed so far is worth finding early. Finding them during an incident is considerably more expensive.

AI-SPM’s limitation mirrors a lesson the industry already learned with CSPM. Posture tooling flags a risky configuration, but it is not designed to provide the runtime enforcement needed to stop every attack that exploits that condition. Stopping an attack needs runtime protection, a control that sits in the path of live activity and blocks it as it happens. This distinction matters particularly for AI.

Prompt injection, jailbreaks and data leakage through model outputs occur at runtime, through the content a model receives and the actions it takes. Configuration analysis cannot see every interaction taking place through the model. OWASP identifies prompt injection as a risk that cannot simply be fixed through a one-time patch. Its guidance points to layered mitigation, including restricting model privileges, output filtering and human approval for sensitive actions.

The implication is important: the control needs to exist where the attack is happening.

This is already happening. CrowdStrike's 2026 Global Threat Report found adversaries exploited legitimate GenAI tools at more than 90 organisations by injecting malicious prompts to generate commands for stealing credentials and cryptocurrency.

It also found that 82% of detections in 2025 were malware-free, with attackers using valid credentials, trusted identity flows, and approved integrations to move through authorised pathways.

In other words, some attacks are not about breaking through a security boundary. They are about using a legitimate path for an illegitimate purpose. The implication for AI security is significant. An attacker does not necessarily need to compromise the AI infrastructure itself. If they can obtain legitimate credentials, manipulate an interaction, or influence an AI system into using its existing permissions, the attack can occur through an otherwise legitimate path. The configuration may remain unchanged. The identity may remain valid. The integration may remain approved. The posture dashboard can still show green. And the attack can still be happening.

Some AI-SPM vendors sell runtime protection alongside their posture product. It is a separate capability, usually under a separate licence. It also has to be deployed separately. How that works varies, even within a single vendor's product. Palo Alto Networks' Prisma AIRS, for example, offers a network intercept that inspects AI traffic inline, and an API intercept that developers build into each application's code. Where API intercept is used, any application that has not been integrated goes unprotected.

If this sounds like your organisation, it is a common position to be in. Many security teams now have AI-SPM or a similar visibility tool, but limited runtime enforcement.

Runtime enforcement can be grounded in NIST SP 800-53 as the underlying security-control foundation, NIST AI RMF as the AI risk-management context, and OWASP AISVS, AI Agent Security guidance and the OWASP Agent Control Standard as the AI-specific implementation layer. These frameworks, standards and guidance provide the principles. Closing the gap comes down to applying those principles to the AI systems, identities, data, tools and actions deployed. The key runtime controls are outlined below.

The organisations securing AI adoption effectively are not relying on visibility alone. They discover and assess continuously. They enforce where activity happens. They limit permissions. They reduce blast radius. And they use security frameworks as working guides rather than simply as checklists.

AI-SPM can find the risk. The architectural question is what stops the attack?If your organisation is working through this challenge, I would like to hear how you are approaching it. Which control is hardest to implement in your environment: least privilege, network isolation, or behavioural monitoring?

Send me an email. I read every response. And if you found this useful, consider sharing it with a colleague who is navigating the same challenge. The gap between posture and protection is where security architecture gets tested.

Email: [email protected]