AI security posture management (AI-SPM) is the practice, and the tooling, of continuously finding the AI an organisation runs, working out how exposed it is, and governing it against policy, so AI risk is measured and not guessed. It covers the AI applications, agents, tool servers, API keys, models and data connections that appear across laptops, servers and cloud accounts, including the ones nobody approved.
The term borrows from cloud security posture management, which asks "what is configured, and is it safe?" for cloud accounts. AI-SPM asks the same question one layer up: which of the things running in this company are AI, what do they hold, and what can they reach?
Why a separate discipline
AI arrives in an organisation without a purchase order. A developer installs a coding assistant, a team connects a tool server to a chat client, an employee pastes a provider API key into a script. None of that is a cloud misconfiguration, and most of it never touches a system that a traditional control was built to watch. The result is a gap that a survey will not close: you cannot protect, or even describe, what you do not know exists.
The cost is not abstract. IBM's Cost of a Data Breach 2025 report found that breaches involving shadow AI added about $670,000 to the average cost. The same report is a reminder that visibility is where the saving starts.
What AI-SPM covers
1. Discovery and inventory
A continuous, evidence-based list of AI assets. Good discovery looks at several kinds of signal, because no single one is enough: AI command-line tools and agents, provider API keys, tool servers (MCP), coding-assistant plug-ins, AI libraries in code, installed AI apps, browser extensions, network traffic to AI endpoints, AI-generated repositories, and the non-human identities that agents use. See Shadow AI: The Invisible Attack Surface for why discovery comes first.
2. Exposure assessment
For each asset: how exposed is it, how easy is it to misuse, is there a known weakness, does it act on its own, where did it come from, and what controls are missing? A useful assessment shows its working, so a reviewer can disagree with an input instead of a verdict.
3. Access and reach
What can this agent or tool reach: files, credentials, cloud accounts, data stores, the internet? Reach is what turns a stray tool into an attack path. See Securing MCP Servers and AI Agents.
4. Policy and governance
An approved list, a clear owner for every item, a risk classification where regulation applies, and a way to say yes, yes with conditions, or no. Control mapping to frameworks such as NIST AI RMF, ISO/IEC 42001, the OWASP Top 10 for LLM applications and the EU AI Act helps, but mapping is not certification.
5. Evidence
Records that an auditor can check: what was found, when, who decided, and what changed. Evidence that can be verified independently is worth more than a dashboard screenshot.
How it differs from tools you already have
- Cloud posture tools start from cloud accounts and their configuration. They do not see an assistant on a laptop or a key in a developer's shell profile.
- Endpoint protection watches processes and files for malicious behaviour. It does not tell you which of those processes are AI agents, or what they are allowed to reach.
- Data security tools watch known data stores and sanctioned channels. They do not find the AI that nobody approved.
AI-SPM does not replace any of them. It adds the AI layer and connects it to what they already know.
What good looks like, and its limits
- Coverage is measured, never claimed as 100%. Name the blind spots: devices without a sensor, SaaS you do not connect, networks you do not see.
- Collect metadata, not content. Discovery should not need prompts, responses, file contents or keystrokes. Where a key is found, record that it exists and where, never its value.
- Separate evidence from advice. A score should be deterministic and explainable. Advisory commentary can help, but it should not change the number.
- Be precise about status. Say what is available today, what is in validation and what is planned.
How to start
- Pick one population, for example 25 representative endpoints and one cloud account.
- Run read-only discovery and review what it finds, with the owners of those machines.
- Record an owner and a decision for every item: approved, approved with conditions, or not allowed.
- Rank by exposure and reach, and fix the top few first.
- Repeat on a schedule, and report coverage next to the findings.
Where Sargha fits
Sargha is Araghatta's AI-SPM platform. A read-only sensor discovers AI on Windows, macOS and Linux endpoints and servers, read-only connectors cover cloud and other sources, and scores are explained down to the facts behind them. A free assessment covers up to 25 endpoints and returns a risk report and an AI Bill of Materials. See how Sargha approaches AI-SPM. The coverage model lists what is and is not seen, and the roadmap separates what is planned from what is available.