What is AI security posture management (AI-SPM)?
By Identra · Updated
AI security posture management (AI-SPM) is the practice of discovering AI assets, assessing their configurations and access, and prioritizing security weaknesses for remediation. It connects models, applications and agents to the data and tools they can reach so security teams can reduce exposure.
What does AI-SPM actually do?
It finds the AI in your environment, checks how each piece is set up and what it can touch, and gets the risky bits fixed. Then it checks again, because things drift.
In practice the findings are concrete. An OAuth app in Entra ID holds Mail.ReadWrite for every mailbox when it only needs one. A developer's ~/.cursor/mcp.json points at an MCP server nobody reviewed. A retrieval index serves HR documents to anyone who asks the internal assistant.
Products sold under this name cover different ground. Some only see cloud model deployments. Write down what yours covers. The output gives AI governance something to stand on, since a policy is only useful once you can show which apps meet it.
Which AI assets belong in the inventory?
Anything that reads company data or acts on company systems. For each one, record an owner, a purpose and what it can reach. A model name tells you nothing about whether the app around it can read payroll.
- Browser AI apps and the accounts people use with them, plus desktop apps like Claude Desktop and coding agents like Claude Code or Codex.
- Agents and the MCP servers, plugins and skills they load.
- OAuth grants, service accounts and API keys. Record who owns them and what they can do. Never copy the secret itself into the inventory.
- Model endpoints you host or call, and the retrieval sources behind them.
What should a posture assessment check?
Look at how things connect, beyond individual settings. An app with perfect SSO can still leak if its retrieval layer ignores document permissions.
For OAuth app risk, check the scopes, who consented and whether anyone still needs the app. Apply least privilege to reads and writes separately. Drafting a pull request and merging it are different powers.
Also check where secrets are stored, whether logging is on and how long data is kept. If you can't see something, mark it unknown. Unknown is not a pass. And confirm a misconfiguration is actually reachable before you call it a vulnerability.
Don't forget shadow AI. Cloud deployment records won't show a personal ChatGPT login in someone's browser or an agent installed on a laptop. Write the gaps down so a partial inventory doesn't read as a clean bill of health.
What does a real AI-SPM finding look like?
Say a support team deploys an assistant to search troubleshooting docs. The assessment finds its service account can also read the finance share and edit support tickets. It needs neither.
A good finding names the assistant, its owner, the service account and the two resources. The fix is specific. Remove finance read access, drop ticket write, then run real support questions to confirm search still works and finance files don't come back.
The system prompt already said to use support docs only. That changed nothing about the account's access. If prompt injection ever redirects the assistant, the narrower grant is what limits the damage.
How is AI-SPM different from runtime protection?
Posture is about what exists and what it could do. Runtime is about what's happening right now. A perfectly configured ChatGPT Enterprise workspace doesn't stop someone pasting the same file into a personal account. That takes AI usage control.
Access
- Posture asks
- Which accounts and integrations are authorized?
- Runtime asks
- Is this account allowed to do this now?
Data
- Posture asks
- Which repositories can the app read?
- Runtime asks
- Does this upload break data policy?
Agents
- Posture asks
- Which tools and permissions does it hold?
- Runtime asks
- Should this tool call go through?
How do you run an AI-SPM program week to week?
Start with the systems that touch sensitive data or can change production. An agent with write access to prod it doesn't need beats a blank description field every time.
Every finding gets an owner, a fix and a date. Exceptions get a reason, an approver and a review date. After a fix, test that the bad access is gone and the real workflow still runs. Reassess whenever a model, tool, data source or grant changes.
How Identra thinks about it
Identra builds an inventory of the AI in use across the business: AI apps and the accounts people use with them in the browser, AI clients, coding agents, MCP servers, skills and plugins on endpoints, and AI agents in connected Microsoft 365, Google Workspace and Anthropic environments with their owners. Connected apps are sorted by what they can reach, from admin rights to sign-in only, and OAuth grants are collected with the app, permissions and grantor. Analysts can revoke risky grants, and each response records the result.
Go deeper: AI security, built on identity
Frequently asked questions
Is AI-SPM only for companies that build models?
No. If your people use AI apps and agents connected to company data, you have posture to manage.
How is AI-SPM different from cloud security posture management?
CSPM looks at cloud resource configuration. AI-SPM adds model endpoints, retrieval sources and agent tools, and may extend to SaaS and endpoint AI apps.
Can AI-SPM prevent prompt injection?
No. It shrinks what a manipulated agent can reach. You still need runtime controls and testing.
Does a clean assessment mean the AI system is secure?
It means the assets you checked passed the checks you ran. Unknown assets and later changes can still bite.
What evidence closes a finding?
Proof the permission or setting changed, a test showing the unwanted access now fails, and confirmation the business workflow still works.