AI Security Posture Management (AI-SPM): The Complete 2026 Guide

Last reviewed: 25 October 2026

Quick answer: AI Security Posture Management (AI-SPM) is the continuous practice of discovering, classifying, assessing and enforcing controls across every AI system an organisation touches. It covers two distinct postures. Inbound posture governs the third-party AI your employees consume - which providers are sanctioned, who may use them for what, and what data is allowed to leave in a prompt. Outbound posture governs the AI your organisation itself serves - resistance to prompt injection, safe output behaviour, and bounded agent authority. Most programmes build one and discover the other the hard way.

Most organisations discovered their AI exposure backwards. The policy was written for ChatGPT in a browser, and then someone noticed the coding assistant had been sending repository context for nine months, the CRM had quietly shipped an AI summariser, and the internal support bot had started answering questions about medication.

None of that is a tooling failure. It is the absence of a posture - a continuously maintained answer to what AI exists here, what it is allowed to touch, and whether the controls actually held. Security teams have built exactly this twice before, for cloud and for data. The method transfers. The implementation does not.

Start With a Posture You Already Know: CSPM and DSPM

Before AI, security teams had already solved this problem shape twice.

When workloads moved to the cloud, nobody could answer a simple question: how many storage buckets do we have, and which of them are public? Cloud Security Posture Management (CSPM) was the answer. It was not a new firewall. It was a loop: enumerate every cloud resource, compare each one against a policy baseline, rank the gaps by blast radius, fix them, and keep watching because the estate changes hourly.

The same thing happened to data. Copies of the customer database multiplied across warehouses, S3 prefixes, analytics sandboxes and a spreadsheet on somebody's laptop. Data Security Posture Management (DSPM) answered it with the same loop applied to data: find every data store, classify what is inside it, map who can reach it, score the exposure, remediate, repeat.

Strip both down and the loop is identical:

That loop is the inheritance. AI-SPM is not a new philosophy - it is the same six stages pointed at a new kind of asset.

Why AI Breaks the Inherited Model

Borrowing the loop is right. Borrowing the implementation is not, for four reasons.

• The asset is a request, not a resource. CSPM scans a bucket that sits still. The unit of AI risk is a single prompt that exists for 400 milliseconds and is never written to disk. You cannot scan it after the fact; you have to inspect it in flight.
• The boundary is a sentence. Traditional DLP watches files, attachments and USB ports. An employee pasting a customer list into a chat window exfiltrates the same data with none of those signals present.
• The control plane is natural language. In every other system, instructions and data travel on separate channels. In an LLM they are the same channel. That single architectural fact is why prompt injection exists and why it has no clean fix.
• Behaviour is probabilistic. A correctly configured S3 bucket is correctly configured every time. A correctly configured model refuses a request on Monday and complies with a rephrased version on Tuesday. Posture must therefore be measured continuously, not certified once.

The Two Postures Every Enterprise Runs at Once

Here is the framing that matters most, and the one most programmes get wrong by addressing only half of it.

They share a policy engine and an audit trail. Everything else about them is different. Treat them as one programme with two control sets.

Posture 1: Governing the AI Your Employees Consume

This is where almost every organisation already has exposure, whether or not it has a policy. Adoption happened bottom-up: an engineer signed up with a work email, a marketer installed a browser extension, a finance analyst pasted a quarterly model into a chat window to get a summary.

Step 1: Discover the Routes, Not Just the Tools

The common mistake is to inventory vendors. The thing you actually need is an inventory of routes, because each route needs a different enforcement point:

• Browser - chat.openai.com, claude.ai, gemini.google.com, and the long tail of smaller assistants
• Browser extensions - grammar, summarising, meeting-notes and "AI sidebar" extensions that silently forward page content
• Desktop applications - native assistant apps that bypass the browser entirely and are invisible to a CASB
• IDE and coding assistants - inline completion sending repository context on every keystroke
• Embedded SaaS features - the AI summariser now shipped by default inside your CRM, ticketing and collaboration tools
• Direct API calls - scripts, notebooks and services calling provider endpoints with a key someone expensed
• Agents and MCP connectors - the fastest-growing and least visible route, where a tool acts on data continuously without a human watching

A credible discovery exercise answers four things per route: which provider, which identity, how often, and what kind of content. If you only get the first two, you have an inventory, not a posture. Our guide to detecting shadow AI traffic covers the mechanics in depth, and AI security for enterprise LLM usage shows where each route is enforced.

Step 2: Allowed Providers - Decide Which Models Are Sanctioned

Model allowlisting is the AI equivalent of an approved software catalogue, and it should be driven by contract terms rather than brand familiarity. The questions that separate a sanctioned provider from an unsanctioned one:

• Training on inputs. Does the enterprise agreement contractually exclude your prompts from model training? Consumer tiers of the same product usually do not.
• Retention. How long are prompts stored, and can retention be set to zero?
• Residency. Which jurisdictions process the request - a live question under GDPR, Singapore's PDPA and sectoral rules such as MAS TRM.
• Sub-processors. Who sits behind the provider, and are they disclosed?
• Certification and assurance. SOC 2 Type II, ISO/IEC 27001, and increasingly ISO/IEC 42001 for the AI management system itself.
• Tenant isolation and key control. Especially where the model is reached through a cloud marketplace deployment.

The output is a three-tier list: sanctioned (enterprise agreement in place, routed through a controlled gateway), permitted with constraints (allowed for defined low-sensitivity purposes), and blocked. Publish the list, name the owner, and set a review cadence - new providers appear monthly.

A warning about blocking. An outright block on a popular assistant does not remove the demand; it moves the work to a personal laptop where you have no visibility at all. The strongest posture is a sanctioned route that is genuinely easier to use than the unsanctioned one, with enforcement reserved for the data rather than the tool.

Step 3: Allowed Usage - Bind Purpose to Role

Approving a provider is not the same as approving every use of it. The same model that is appropriate for drafting a job advertisement is not appropriate for an HR team to use for generating production code, and not appropriate for a support agent to use for giving a customer tax guidance.

Purpose binding means each role gets an explicit set of allowed task categories:

Two observations from deployments. First, restrictions written as categories survive; restrictions written as named tools go stale within a quarter. Second, an HR user generating code is rarely malicious - it is usually a sign that a legitimate need has no sanctioned path, which is a product problem disguised as a policy violation.

Step 4: DLP at the Prompt Layer - the Control That Carries the Programme

If you implement one thing from this guide, implement this. Provider allowlisting tells you where data can go. Prompt-level DLP decides what is allowed to go there, and it is the only control that holds when an employee uses a route you did not anticipate.

Classic DLP was built for a world where data left as a file - an attachment, an upload, a copy to a USB drive. A prompt defeats every one of those assumptions. It is unstructured, conversational, often paraphrased rather than pasted verbatim, and it leaves over ordinary HTTPS that looks exactly like any other web traffic.

An AI DLP control worth deploying has five properties:

1. It inspects the prompt before it leaves. Enforcement after the request has reached the provider is reporting, not prevention.
2. It classifies in context. Regular expressions catch a credit card number and miss a paraphrased clinical summary. Entity detection needs to span PII, PHI, PCI, credentials, source code, contract terms and internal identifiers - and it has to work on a sentence rather than a form field.
3. It masks rather than blocks, wherever it can. This is the difference between a control people route around and one they accept. Sensitive values are replaced with reversible tokens, the model answers the question it was actually asked, and the real values are restored in the response for an authorised user. The work completes; the data never left.
4. It is bidirectional. The response matters too - regulated advice, leaked system prompt content, and data pulled back from a RAG index all arrive on the way in.
5. It produces evidence. Per request: identity, destination, policy evaluated, action taken, entities detected. Without this you cannot answer a regulator, and you cannot tune the policy either.

Measure it honestly. False positives and false negatives per data type, latency at p50 and p95 on your own traffic, and behaviour when the control service is unavailable - fail open or fail closed is a decision, not a default. Our AI DLP tooling comparison and the enterprise AI data security playbook go further on evaluation.

Step 5: RBAC - Make Identity the Unit of Policy

Everything above collapses without identity. A policy that cannot distinguish a contractor from a director is a policy that must be written for the least trusted person in the building.

Workable AI RBAC covers four dimensions:

• Who - the authenticated identity, group and employment type, federated from your existing IdP rather than maintained separately
• What model - which providers and which specific models that identity may reach
• What data - which sensitivity classes may appear in that identity's prompts, and which are masked or denied
• What action - read-only assistance versus an agent permitted to write to a system of record

Two refinements separate a mature deployment from a basic one. Inherited entitlement: a retrieval assistant must never return a document the asking user could not have opened directly - the single most common data leak in internal RAG. And break-glass with evidence: a documented path to exceed normal limits that is time-bounded, approved and logged, because a policy with no escape hatch gets disabled during the first incident. See enterprise RBAC for AI for the implementation pattern.

Step 6: Evidence

Posture is a claim until you can prove it. The inbound AI audit trail should let you reconstruct, for any day in the retention window: which identities used which providers, what was blocked or masked and why, which policies changed and who approved them, and which exceptions were open. This is what MAS TRM, the EU AI Act's record-keeping duties and a SOC 2 auditor are all independently asking for. We cover the specifics in building regulator-ready AI audit logs.

Posture 2: Governing the AI Your Organisation Provides

The moment you put a model in front of users - an internal copilot, a customer-facing assistant, a public demo, an agent with tools - the risk reverses direction. You are no longer worried about what leaves. You are worried about what arrives, and about what your system says in your name.

The Frameworks That Define This Space

You do not need a bespoke threat model. Four bodies of work cover the ground, and together they are what auditors and enterprise buyers now expect you to have mapped against.

Supplement these where they apply to you: the OWASP agentic security guidance for tool-using systems, the EU AI Act for anything in an Annex III high-risk domain (see our EU AI Act guide), and Singapore's AI Verify and Model AI Governance Framework for Generative AI in APAC deployments.

Prompt Injection: The Defining Vulnerability

Prompt injection has sat at LLM01 in the OWASP Top 10 for LLM Applications since the list was created, and it remains there in the 2025 edition. The reason it has not been solved is architectural: a language model receives your system instructions and the user's untrusted input on the same channel, as one undifferentiated sequence of tokens. There is no equivalent of a prepared statement to separate them.

It appears in two shapes, and the second is far more dangerous.

Direct injection is the user typing adversarial instructions themselves - "ignore your previous instructions", role-play framings, encoded or obfuscated payloads, multi-turn setups that establish a premise before exploiting it, and crescendo attacks that escalate gradually enough to stay below a refusal threshold.

Indirect injection is an instruction planted in content the model reads rather than content the user typed: a web page the assistant browses, a PDF in the RAG index, a support ticket, an email in the inbox the agent has access to, a code comment, or white text on a white background in an uploaded CV. Nobody in your organisation typed the malicious instruction, which is exactly why it works. For any system that retrieves, browses or reads shared content, this is the primary threat - and it is the mechanism behind most agent compromise.

Related entries in the same list travel with it and should be tested together: LLM02 Sensitive Information Disclosure, LLM05 Improper Output Handling (model output reaching a browser, shell or database without sanitisation - classic injection with a new source), LLM06 Excessive Agency (the agent could do more than the task required), LLM07 System Prompt Leakage, and LLM08 Vector and Embedding Weaknesses (poisoned or over-permissioned retrieval).

Defences layer; none is sufficient alone:

• Treat all retrieved content as untrusted input, delimited and labelled as data, never as instruction - the single highest-value change for RAG systems.
• Screen inputs for known injection and jailbreak patterns before they reach the model.
• Constrain privilege at the tool, not in the prompt. An instruction not to delete records is a suggestion; an API credential without delete permission is a control.
• Require human approval for consequential or irreversible actions.
• Validate outputs before they are rendered or executed downstream.
• Test continuously - a model or prompt change can silently reopen something you closed last quarter.

Output Posture: What Your Model Says Is Your Liability

Injection is the attack most teams prepare for. Unsolicited specialised advice is the one that generates the complaint, and it needs no attacker at all - a sincere user asking a sincere question is enough.

A general-purpose assistant will, unless constrained, answer a medical question with a diagnosis, a financial question with a recommendation, and a legal question with an opinion. In most jurisdictions, your organisation is accountable for that output as though a member of staff had said it. Under the EU AI Act, a user who cannot tell they are talking to a machine is a separate transparency failure on top.

The behaviours an output guardrail needs to govern:

One implementation note that matters disproportionately: these constraints belong in a guardrail layer outside the model, not only in the system prompt. A system prompt is instructions to a probabilistic system and can be argued with. An external classifier evaluating every response is a control that can be tested, versioned and evidenced.

Agents Raise Every Stake

When the model can call tools, injection stops being a content problem and becomes an execution problem. A poisoned document no longer merely produces a bad answer; it causes an action against a real system. Hold agents to four rules: least-privilege credentials scoped per tool, an explicit allowlist of permitted actions, human approval for anything irreversible or externally visible, and a complete trace of every tool call for forensics. Our note on governing agentic AI expands on each.

Test It Like an Adversary, Continuously

Posture for provided AI is measured, not asserted. A credible evaluation programme runs a versioned suite covering direct and indirect injection, jailbreak families, data exfiltration attempts, specialised-advice probes, hallucination under ambiguity, and tool misuse - executed on every model upgrade, prompt change, retrieval change and tool addition. Track attack success rate by category over time, and treat an increase after a model upgrade exactly as you would treat a failing regression test.

Putting the Two Postures Together

Mapped back onto the DSPM loop, an AI-SPM programme looks like this:

Four metrics are enough to report upward: coverage (share of AI traffic passing an enforcement point), exposure (sensitive-data events prevented versus detected after the fact), resistance (attack success rate on the current evaluation suite), and evidence completeness (share of interactions with a reconstructable audit record).

A 90-Day Sequence

1. Days 1-30 - see it. Discover routes and providers, inventory internally provided AI systems, classify each by risk tier. Publish the sanctioned provider list. No enforcement yet.
2. Days 31-60 - control the data. Deploy prompt-level DLP in monitor mode on the highest-volume routes, tune for false positives against real traffic, then switch the top sensitivity classes to masking. Wire AI policy to the identity provider. Run the first adversarial evaluation against every externally reachable system you provide.
3. Days 61-90 - enforce and prove. Move DLP to enforcement, apply purpose binding by role, put output guardrails in front of provided models, scope agent credentials down, and produce the first board-level posture report from real telemetry.

How WalledAI Delivers AI-SPM

WalledAI was built around this two-posture model, on a single policy engine and a single audit trail so that inbound and outbound AI are governed as one programme rather than two disconnected projects.

For the AI your employees consume:

• Shadow AI Detection discovers every AI route in use - browser, desktop app, extension, IDE, embedded SaaS feature, direct API and agent connector - and attributes it to an identity, which is what turns an inventory into a posture.
• AI DLP and WalledRedact enforce at the prompt layer. Sensitive entities are detected in unstructured conversational text and reversibly masked, so the request still works and the real values never leave your boundary. The response is unmasked only for an authorised user.
• Enterprise RBAC binds provider, model, data class and permitted action to identity and role, federated from your existing IdP - this is where provider allowlisting and purpose binding are actually expressed.
• Governance Dashboard turns every decision into regulator-ready evidence and the four posture metrics above.

For the AI your organisation provides:

• WalledProtect screens inbound prompts and retrieved content for direct and indirect injection, jailbreak patterns and unsafe requests, and screens responses for harmful content, data disclosure and unsolicited specialised advice - as an external guardrail layer, not a system-prompt instruction.
• WalledCorrect checks responses for groundedness against their sources, so a model that is unsure refuses rather than fabricates.
• The same RBAC and dashboard layers scope agent authority and record every interaction and tool call.

Because the controls run at the request layer, deployment follows the data: on-premises, private cloud or air-gapped, with classification, policy decisions and re-identification keys staying inside your boundary. That is the distinction regulated buyers in financial services, healthcare and government consistently ask about - see our financial services governance guide for how it plays out under MAS TRM.

Bottom Line

AI-SPM inherits a loop that security teams already know - discover, classify, assess, prioritise, enforce, evidence - and points it at an asset that only exists in flight. The programmes that work govern both postures at once: the third-party AI employees consume, where the control that carries everything is DLP at the prompt layer backed by provider allowlisting, purpose binding and RBAC; and the AI the organisation provides, where injection resistance and output guardrails decide whether your own system can be turned against you. Half a programme is not a posture. It is a gap you have not measured yet.

Related reading: the enterprise AI data security playbook, how to detect shadow AI traffic, the best enterprise AI governance tools, and regulator-ready AI audit logs.

See the WalledAI enterprise platform or book an AI posture assessment.