AI-SPM vs AI Runtime Security: What Each Catches and When You Need Both

Teams buying AI security tooling often assume that a posture product will stop a prompt injection, or that a prompt firewall will tell them which model endpoints are public, and both assumptions leave a gap an attacker can walk through. AI security posture management (AI-SPM) looks at how AI assets are built and configured; AI runtime security looks at what passes through them while they run. This guide compares the two on detection timing, what each can see, the threats each addresses, how each fails, and how to decide where to spend first. It is for security architects, cloud and platform teams and AI engineering leads who already know what each category is and need to decide how they fit together. For the category basics, see the AI Security Posture Management (AI-SPM) Guide and the AI Runtime Security and Guardrails Buyer's Guide.

Key takeaways

• They work at different moments. AI-SPM evaluates configuration, identity and data exposure before and between requests; runtime security evaluates each prompt, response and tool call as it happens.
• They see different evidence. AI-SPM reads cloud APIs, infrastructure as code and identity graphs; runtime controls read content and actions. Neither can reconstruct what the other sees.
• Posture sets the blast radius, runtime limits the event. A runtime filter can be bypassed by careful wording; what the model and its identity can reach is then decided by posture.
• Overlap is growing but is not equivalence. Cloud platforms now ship both capabilities side by side, and a single console does not mean a single control. Check each function separately.
• Start with the gap that matches your exposure. Many self-hosted models and unknown endpoints point to posture first; a public chatbot or an agent with write tools points to runtime first. Most organisations end up needing both.

Short answer

AI-SPM answers "what AI do we have, and is it set up safely?" It discovers models, endpoints, datasets, notebooks, agents and Model Context Protocol (MCP) servers, then flags public network exposure, key-based authentication, over-permissive identities, unencrypted data and vulnerable AI libraries. AI runtime security answers "is this interaction safe right now?" It inspects prompts and responses for injection, jailbreaks, sensitive data and unsafe content, and in agentic systems it checks tool calls before they execute. Posture is preventive and periodic or event-driven; runtime is inline or near real time and per request. You cannot buy your way out of either with the other, because each fails in places the other cannot reach.

Side-by-side comparison

AI-SPM in depth: posture

Threat model

AI-SPM assumes the attacker comes in through the estate, not the conversation. The typical paths are a leaked or over-scoped model API key used to run inference on your bill (MITRE ATLAS AML.T0055 Unsecured Credentials, leading to AML.T0040 AI Model Inference API Access), a public inference endpoint with weak authentication, a workload identity on a notebook that can read the training bucket, a poisoned or vulnerable library in the serving image (OWASP LLM03:2025 Supply Chain), and a shadow model running on a GPU virtual machine nobody registered. The Google API Keys Exposure 2026 case shows the pattern: unrestricted keys that had been treated as public identifiers gained access to Gemini when the API was enabled in the same project, which is a configuration fact a posture scan can see before anyone abuses it.

Architecture in words

A posture service connects read-only to cloud accounts, subscriptions and projects, to code repositories and to container registries. It builds a graph of AI resources (models, endpoints, data sources, agents, MCP servers), the identities that can reach them and the network paths to them, then runs checks and attack path queries across that graph. Microsoft describes its AI-SPM as discovering a generative AI bill of materials covering "application components, data, and AI artifacts from code to cloud", with IaC checks such as Use Azure AI Service Private Endpoints and Use identity-based authentication for Azure AI Service Accounts. The output is a list of findings and prioritised attack paths, not a block decision.

Where it fails

• Unconnected estate: models on accounts, tenants or SaaS platforms that were never onboarded produce no findings, which reads as clean.
• Inferred assets: a general-purpose virtual machine serving an open-weights model may not be classified as AI at all. See the Shadow AI Discovery Guide.
• Content-only risk: a correctly configured, private, keyless endpoint can still leak data when a user or a retrieved document instructs the model to do so.
• Finding fatigue: hundreds of medium findings without attack path context are ignored, and the one finding that matters waits in the queue.

Controls it drives

Disable key-based authentication in favour of workload identity, make inference endpoints private, scope each AI identity to its own data, encrypt data sources with managed keys (AWS Security Hub control Bedrock.1 checks customer managed KMS keys on Amazon Bedrock data sources), patch AI libraries in images, and register every model and agent in an inventory. These map to NIST SP 800-53 CM-8 (component inventory), CM-6 (configuration settings), RA-5 (vulnerability monitoring) and AC-6 (least privilege). For the identity side, see the AI Infrastructure Workload Identity Guide and the LLMjacking Guide.

AI runtime security in depth: protection

Threat model

Runtime security assumes the attacker comes in through content. Direct prompt injection and jailbreaks (OWASP LLM01:2025 Prompt Injection, ATLAS AML.T0051 and AML.T0054), indirect injection hidden in documents, emails or web pages that the model retrieves, sensitive data returned in answers (LLM02:2025 Sensitive Information Disclosure, ATLAS AML.T0057 LLM Data Leakage), and in agentic systems a manipulated model calling tools it should not (LLM06:2025 Excessive Agency, ATLAS AML.T0053 AI Agent Tool Invocation). Unbounded consumption (LLM10:2025) sits on the boundary: posture caps quotas, runtime spots abusive request patterns.

Architecture in words

Runtime controls sit in the request path. Four placements are common: a gateway or proxy in front of model APIs, an SDK call the application makes before and after each model call, a filter built into the model platform, and a hook in the agent framework that screens tool calls. Each screened request is evaluated against policies (injection detection, sensitive data patterns, topic and content rules, URL reputation) and the control blocks, redacts, allows or alerts. Detections go to the SIEM or XDR for correlation. For placement options, see the AI Guardrails vs AI Gateways comparison.

Where it fails

• Classifier evasion: detection is probabilistic. The EchoLeak 2025 research described bypassing an injection classifier with careful phrasing; what the assistant could then retrieve depended on the user's access rights, a posture matter.
• Bypass paths: a developer calling the model API directly with a key skips the gateway entirely. Runtime coverage is only as good as the network and identity rules that force traffic through it.
• Allowed but harmful actions: a tool call can pass every content check and still delete data, because the agent was permitted to delete data.
• Modality and scope limits: some services screen text only, or skip reasoning content, so images, audio or other blocks pass unscreened. Check what each control documents.
• Logging prompts creates a new data store: evidence capture holds sensitive content and needs its own access control and retention. See Secure AI logging.

Controls it drives

Input and output screening with separate policies for each direction, sensitive data redaction, tool call allowlists and argument checks, human approval for high-impact actions, rate and spend limits, and alert routing to the SOC. These map to NIST SP 800-53 SI-10 (input validation), SI-4 (system monitoring) and AU-2 (event logging). Policy design is covered in the AI Guardrails and AI Firewalls Guide and the Prompt Injection Guide.

What each sees and misses

Where the capabilities meet on cloud platforms

The three largest cloud providers each document posture and runtime capabilities for AI workloads as separate functions that report to shared consoles. Platforms are listed alphabetically; the order is not a ranking. For deeper platform coverage, see the Amazon Bedrock Security Guide, the Google Vertex AI Security Guide and the Azure OpenAI and Azure AI Foundry Security Guide.

• Amazon Web Services: posture checks for Amazon Bedrock run in AWS Security Hub CSPM (for example Bedrock.1, backed by the AWS Config rule bedrock-data-source-encryption-enabled). Runtime screening is Amazon Bedrock Guardrails, with content filters (including a Prompt Attack category), denied topics, word filters, sensitive information filters, contextual grounding checks and Automated Reasoning checks, applied at inference by guardrail ID and version or through the ApplyGuardrail API without invoking a model.
• Google Cloud: Security Command Center AI Protection covers both. Posture includes an AI inventory (endpoints, data sources, models and MCP servers in Agent Registry), AI Discovery from Cloud Monitoring data and Compliance Manager frameworks in detective mode. Runtime includes Model Armor findings (prompt injection and jailbreak detection, Sensitive Data Protection, malicious URL detection, responsible AI filters) and threat detection for agents on Agent Runtime.
• Microsoft Azure: AI-SPM in Defender for Cloud discovers the AI bill of materials, issues identity, data and exposure recommendations and runs attack path analysis across Azure, AWS and Google Cloud. Threat protection for AI services works with Azure AI Content Safety Prompt Shields and Microsoft threat intelligence to raise alerts for threats such as jailbreak, data leakage and credential theft, and sends them to Defender XDR.

Availability notes: Google Cloud documents that AI Discovery, threat findings and runtime agent threat detection need the Premium or Enterprise tier, with some features in Preview. Microsoft documents that AI-SPM is part of the Defender CSPM plan, and that from 1 July 2026 agent discovery and posture for Foundry and third-party cloud agents require a Microsoft Agent 365 licence. Confirm current terms in each provider's documentation.

Choosing: decision criteria

Small organisations usually get most value from the posture and filter features already in their cloud platform, a short inventory and disabling key authentication, before buying anything. Large organisations with multiple clouds and many teams need posture across accounts, a runtime enforcement point that teams cannot bypass, and one correlation point in the SOC. Consolidated platforms reduce integration effort; separate tools can give deeper coverage in one layer. Either way, test each function on its own merits. See the AI Security Platform Buyer's Guide for evaluation criteria.

Worked scenario: an internal agent over finance data

A finance team deploys an agent that answers questions over invoices in object storage and can create payment drafts through an internal API. It runs on a managed model service.

1. Posture first: the AI-SPM scan finds that the model endpoint accepts API keys, the agent's managed identity can read every bucket in the account, and the payments API credential is stored in the agent configuration. Fixes: disable key authentication, scope the identity to the invoice bucket, move the credential to a secrets manager with a short lease.
2. Runtime next: input and output policies screen user prompts and retrieved invoice text, because supplier invoices are attacker-controllable content. Tool-call policy allows payment drafts only below a value threshold and requires human approval above it.
3. Test: a red team plants instructions in a test invoice. The runtime filter catches most variants; one passes. Because posture limited the identity and the tool policy capped values, the worst outcome is a small draft that needs approval. See the AI Red Teaming Guide.
4. Measure: the team tracks the share of agent traffic passing through the runtime control and the number of agent identities with access beyond their declared data.

The point: neither layer alone would have contained the bypass. Posture reduced what the bypass could reach; runtime reduced how often it happened.

Implementation roadmap

1. Inventory (weeks 1 to 4): connect every cloud account and repository to posture tooling, list models, endpoints, agents, MCP servers and AI credentials, and assign owners.
2. Fix exposure (weeks 3 to 8): close public endpoints, disable key authentication where identity-based access exists, scope AI identities, and add IaC checks to pipelines so new deployments fail fast.
3. Runtime in monitor mode (weeks 6 to 10): place screening on the highest-risk applications in alert-only mode, tune false positives on real traffic, and route alerts to the SOC.
4. Enforce (weeks 10 onwards): switch to block or redact per policy, application by application, with a documented rollback (return the policy to monitor mode) and an owner on call for the first week.
5. Close bypasses: use network and identity rules so model APIs are reachable only through the enforcement point, and use posture findings to spot new direct paths.
6. Correlate: join runtime alerts with posture context (which identity, which data, which exposure) so triage starts from blast radius.

Detection and measurement

• Inventory coverage: share of cloud accounts and repositories connected to posture tooling, target 100% of production.
• Keyless and private endpoints: share of AI endpoints with key authentication disabled and no public network access.
• Runtime coverage: share of production model calls that pass through a screening control, measured from model service logs rather than from the control itself.
• Bypass rate: count of identities or hosts calling model APIs directly, outside the enforcement point.
• Detection quality: false positive rate on runtime blocks per application, reviewed monthly.
• Time to fix: median days to close attack paths that reach sensitive training or grounding data.

Common failure patterns

• Buying one layer and calling it done: a posture dashboard showing zero critical findings while a public assistant runs without input screening, or the reverse.
• Runtime with an open side door: the gateway is in place but developers still hold direct model keys, so the most sensitive traffic is the unscreened traffic.
• Posture limited to one cloud: the second cloud and the SaaS AI features never get onboarded, and that is where unmanaged models run.
• Trusting a single classifier: treating injection detection as a guarantee instead of one layer, with no tool-call limits behind it.
• Two consoles, no join: runtime alerts and posture findings land with different teams, so a jailbreak attempt on an agent with broad data access is triaged as low severity.
• Same console, assumed coverage: a platform that offers both capabilities is licensed for only one, or a runtime feature is enabled on some projects and not others.

Framework mapping

The NIST AI 600-1 Generative AI Profile frames both as parts of managing generative AI risk across the lifecycle rather than as alternatives.

Practitioner checklist

• Every cloud account, subscription, project and code repository that hosts AI is connected to posture tooling.
• Each model, endpoint, agent, MCP server and AI credential has a named owner in the inventory.
• Key-based authentication is disabled on AI services wherever identity-based access is available.
• AI identities are scoped to their own data sources, verified through attack path analysis.
• Production model traffic is forced through a runtime enforcement point, and direct paths are monitored.
• Separate runtime policies exist for input and output, with documented block, redact and alert actions.
• Agent tool calls have allowlists, argument checks and human approval for high-impact actions.
• Runtime alerts reach the SOC enriched with the posture context of the identity and data involved.
• Prompt and response evidence stores have access control and retention set.

Standards and references

• NIST: AI 600-1 Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
• OWASP: Top 10 for LLM Applications 2025
• NCSC: Guidelines for secure AI system development
• MITRE ATLAS: LLM Prompt Injection
• AWS: Amazon Bedrock Guardrails
• Google Cloud: AI Protection overview
• Microsoft Learn: AI security posture management

Related NHI Mgmt Group resources: AI Security Posture Management (AI-SPM) Guide, AI Runtime Security and Guardrails Buyer's Guide, AI Security Platform Buyer's Guide, Agentic AI Security Guide.