AI-SPM: Value, Best Practices, and How to Evaluate a Platform

AI security posture management describes the discipline of knowing what AI exists in your environment, how it is configured, what it can reach, and where that creates risk. For the general definition of the category, see AI security posture management.

The difficulty in evaluating AI-SPM is not that the definition is unclear. It is that four distinct product categories currently use the same label, and they solve different problems for different buyers.

Model and pipeline security. Focuses on the models themselves and the pipelines that train and serve them: model provenance, training data integrity, serving infrastructure. The buyer is usually an ML platform team. This is the closest thing to the original meaning of the term.

Data-flow governance. Focuses on what data reaches AI systems and what leaves them, overlapping heavily with DLP. The buyer is usually a data protection or privacy team.

Cloud AI resource discovery. Focuses on finding AI services provisioned inside cloud accounts and evaluating their configuration, essentially cloud posture management extended to AI resources. The buyer is usually cloud security.

Agent access governance. Focuses on autonomous agents that hold credentials and act inside business systems: what agents exist, who built them, what their credentials reach, and what they can do in combination. The buyer is usually identity or SaaS security.

These are not competing implementations of one thing. They address different layers, and a product that is strong at one is frequently absent at another. The first evaluation question is therefore which of the four problems you actually have, because buying the wrong shape produces a working product that covers nothing you were worried about.

Across all four shapes, the value of AI-SPM reduces to three answers most organizations cannot currently produce.

What AI exists here? Not the AI that was procured. The full population, including features vendors enabled inside applications you already own and agents employees built themselves. Most organizations can list their AI vendors and cannot list their AI.

What can each piece reach? For agents specifically, this means what the credential actually reaches inside the connected system, which regularly exceeds what any configuration page declares.

Which combinations create exposure? Individual findings are mostly unremarkable. Risk concentrates where capabilities stack, and no per-item review surfaces that.

Anything beyond these three is presentation. A platform that produces a compliance-ready dashboard without being able to answer them is reporting on a population it has not established.

Five practices, in dependency order. The order matters more than any individual item, because each one is unreliable without the one before it.

1. Inventory before policy. Writing an AI usage policy before knowing what AI is running produces a document rather than a control. Establish the population first. This also reveals which of the four category shapes you actually need.

2. Assign ownership to everything. Every agent, model, and connection needs a named accountable person. This is the highest-leverage practice and the most commonly skipped, because it is organizational rather than technical. Without it, nothing can be scoped correctly, since nobody can say what a workflow requires, and nothing can be retired safely, since nobody can say what breaks.

3. Resolve effective access, not declared configuration. Configuration records intent at a point in time. Credentials accumulate scope continuously. Any assessment built on configuration alone systematically understates exposure, and produces the ghost-chasing pattern where teams investigate findings that were never real while missing the connection that was.

4. Score combinations rather than individual findings. Rank by what one agent or system can reach across everything available to it at once. This turns an unreadable list of hundreds of findings into a short list where the risk actually is.

5. Enforce only where you have truth. Enforcement built on an inaccurate inventory blocks legitimate work and misses real exposure, which is how a program loses organizational support in its first quarter. Earn enforcement with accuracy first.

Where do findings come from, configuration or runtime behavior? This is the single most revealing question. Configuration-derived findings describe what was set up. Runtime-derived findings describe what is actually reachable. A vendor that cannot clearly answer this is usually reading config.

How is the inventory refreshed? Agents and MCP servers are created by individuals in seconds. A platform that collects on a schedule reports a state that was true at collection time. Ask for the actual refresh mechanism, not the marketing cadence.

Which platforms are covered, and at what depth? Coverage claims frequently mix "we can discover this" with "we can enforce here." Insist on the distinction per platform, because a vendor that discovers across ten platforms and enforces on none is a discovery product.

Can it name the creator of each agent? Ownership is the fact everything else depends on and the one thinnest across the field. A platform that cannot attribute an agent to a person cannot support retirement or scoping decisions.

Does it score combinations or list findings? Ask to see how the platform ranks. If output is a flat list of per-object findings, the combination analysis is being left to you.

What happens with unsanctioned and orphaned assets? Ask specifically about agents whose creator has left and connections nobody approved. These are where real exposure concentrates and where thin coverage shows up fastest.

Does it require agents to be registered first? A platform that only sees what you tell it about cannot find shadow AI, which is the part you most need found.

Buying the wrong shape. Procuring model and pipeline security when the actual exposure is employee-built agents holding SaaS credentials. Both are legitimate products; only one addresses that problem.

Treating the dashboard as the outcome. A score that goes up while the underlying population is unknown measures the assessment rather than the environment.

Starting with enforcement. Blocking based on an incomplete inventory produces false positives, erodes trust, and gets the program shelved.

Ignoring the connection layer. Agent-level inventory that stops before MCP servers and integrations misses where the credentials actually live. See MCP server inventory.

Assuming configuration equals reality. The most consequential and most common. Everything downstream inherits the error.

Obsidian sits in the fourth category, agent access governance, and is explicit about that rather than claiming the full label. It builds an inventory of AI agents and their MCP connections across connected platforms from runtime activity, surfaces who created each agent, resolves the effective access each one holds inside your SaaS applications rather than what its configuration claims, and scores the toxic combinations that widen blast radius. The differentiating check is correlating agent identity against SaaS entitlements, so a user querying an agent that holds access they do not have is visible as the escalation it is.

Runtime enforcement is available today for Claude and Microsoft Copilot. Other platforms are covered for discovery and governance, and that distinction is worth holding every vendor to, including this one.