What is AI Security Posture Management?
The quick definition. AI-SPM is four functions (discover, assess, secure, prove) that run continuously. The hard part is not any one function in isolation; the hard part is keeping them aligned to the same asset inventory while the AI surface keeps expanding under you.
We have been writing this post in our heads for about six months because every customer conversation starts in roughly the same place: "what is AI-SPM, and how is it different from the security tooling we already have." This is the answer we settled on, with the parts that took longest to figure out.
AI Security Posture Management (AI-SPM) is the continuous process of discovering, assessing, securing, and proving the compliance posture of AI systems. It extends the established posture-management disciplines (CSPM for cloud, DSPM for data, ASPM for applications) into the specific control surface that AI introduces: LLM applications, AI agents, MCP servers, RAG pipelines, vector databases, model endpoints, and runtime gateways.
That definition is correct but it tells you nothing useful about why teams adopt it. The honest reason is that the AI surface in a modern enterprise has grown faster than any one existing security tool's coverage model can keep up with, and "we are using the same posture tooling we used for cloud" is increasingly the wrong answer at the next audit.
The four functions of AI-SPM
AI-SPM is most usefully thought of as four functions that run continuously rather than as a one-time programme. They look obvious when listed; the operational details below are where the difficulty actually lives.
1. Discover
AI-SPM starts with an inventory of every AI surface the organisation runs. That inventory has to cover not only LLM endpoints but also the supporting stack: the agents that call those endpoints, the MCP servers that expose tools to those agents, the RAG pipelines that feed retrieved context into prompts, the vector databases that hold the embeddings, the embedding and fine-tuned models that produce them, and the managed foundation-model and ML platform services across the major cloud providers that host the foundation models.
In our experience the inventory is always longer than the security team's first guess. Every customer engagement we have run this quarter has surfaced at least one production endpoint that nobody on the platform side had heard of. The pattern is consistent enough that we built a separate post about asset inventory so we would stop repeating ourselves in calls. Anything missing from the inventory is shadow AI, and shadow AI is what the first auditor finding lands on.
2. Assess
Once the inventory exists, AI-SPM continuously assesses each asset against a defined risk model. For LLM endpoints this means scheduled adversarial scans aligned to OWASP LLM Top 10 and OWASP Agentic Top 10. For RAG pipelines this means corpus tainting tests, tenant isolation tests, and embedding-space adversarial inputs. For agents and MCP servers this means tool permission scoring and confused-deputy probes. For vector databases this means namespace isolation and metadata filter integrity.
The word that does the heavy lifting here is "continuously". A one-shot annual pentest is useful evidence but it does not satisfy the EU AI Act post-market monitoring article or the NIST AI 600-1 MEASURE expectations on its own. Daily or weekly cadence is the default we recommend; less is hard to defend at audit.
3. Secure
AI-SPM does not stop at finding issues; it enforces controls on the live request path. The most common pattern is a self-hosted runtime gateway that proxies LLM API calls, applies a DLP firewall on the wire, enforces a tool allowlist, and respects per-domain rate limits and budgets. Policy bundles are cryptographically signed so a compromised agent cannot apply unauthorised rules.
We are biased on the deployment shape because the Penaxtra gateway is a self-hosted Go agent. The customer-side reason teams insist on self-hosted is data residency: regulated buyers will not authorise a security tool that sends prompt content to a third-party scanner service, and the DPIA process surfaces this before the contract gets signed.
4. Prove
The final function is producing evidence that a regulator or internal auditor accepts. AI-SPM exports control-mapped reports across six framework families that matter for AI: OWASP LLM Top 10, OWASP Agentic Top 10, NIST AI 600-1, MITRE ATLAS, EU AI Act, and ISO/IEC 42001. Every finding ships with the specific control identifier; PDF and JSON exports drop straight into an audit pack.
The part we keep relearning: the auditor does not just want the report, they want the audit trail behind it. Who changed which finding's status, when, with what comment, and is the evidence chain tamper-evident. The platform-level requirement is an append-only log; the practical requirement is a workflow where every finding has an owner.
Why AI-SPM is not the same as LLM Security
LLM Security focuses on testing and governing large language model applications and prompt flows. AI-SPM is the broader programme. The scope difference matters because most production AI deployments are not a single model behind a chat endpoint anymore; they are agentic chains, tool-enabled assistants, multi-corpus RAG systems, and orchestrated pipelines.
A useful way to think about it: LLM Security is one layer inside AI-SPM. You can do LLM Security without doing AI-SPM, but you cannot give an auditor an AI-SPM evidence pack without covering the rest of the surface. We expanded this distinction in a follow-up post because procurement teams keep asking the same question.
Why AI-SPM is not the same as CSPM, DSPM, or ASPM
- CSPM secures cloud account configuration: IAM, networking, storage, service-level policy. It does not enumerate agent tools or test prompt flows.
- DSPM secures data stores and lineage. It does not test RAG corpus tainting or vector-database tenant isolation.
- ASPM secures application code and dependencies through the SDLC. It does not test the running model, the running agent, or the runtime gateway.
AI-SPM complements all three. Most regulated organisations we work with run them in parallel; the question is which team owns the AI surface, and the answer is usually whichever team got there first plus a quarterly meeting with the other two.
What to look for in an AI-SPM platform
A capable AI-SPM platform should be able to answer five questions on demand:
- How many AI assets do we have, and what are they?
- For each asset, what risks are open today, and against which framework controls?
- Which controls are enforced at runtime, and which are detection-only?
- When did our posture last change, and why?
- Can the auditor download the evidence pack for this quarter without manual work?
If a platform cannot answer all five, it is either narrowly scoped (LLM Security only) or it is selling governance paperwork without a control surface. Question four is the one most teams cannot answer the first time we ask it.
Where to start
The fastest path is to begin with discovery: enumerate every LLM endpoint, every agent, every RAG pipeline, every vector store. Once the inventory is honest, scheduled scans plus runtime gateway controls plus compliance evidence fall into place. We have not yet seen a team that did the inventory honestly and then got stuck on the rest; we have seen plenty of teams skip the inventory and bounce off everything downstream.
To explore the Penaxtra approach to AI-SPM, read the platform overview or request an architecture review.