What is AI security posture management across the AI lifecycle?

AI security posture management (AI-SPM) is the practice of finding every model, dataset, pipeline, tool and agent your organization uses, then continuously checking their configuration, access and supply chain against policy. It is an industry term, not a standard. The NIST AI Risk Management Framework and OWASP's LLM risks supply the substance.

What does the AI lifecycle include?

NIST's AI RMF 1.0 (NIST AI 100-1, January 2023) adapts an OECD model in which an AI system has four dimensions, Application Context, Data and Input, AI Model, and Task and Output, and lifecycle stages from planning and design through deployment and use. NIST says risk management should start at the Plan and Design stage and continue throughout, with testing, evaluation, verification and validation (TEVV) at every stage.

Its Core has four functions: GOVERN, MAP, MEASURE and MANAGE. GOVERN applies to all stages of an organization's AI risk management. MAP, MEASURE and MANAGE apply to specific systems and stages. Posture management is mostly the MEASURE and MANAGE work, done on an ongoing basis, with an inventory that MAP and GOVERN depend on.

What does "secure" mean for an AI system?

The AI RMF describes secure and resilient as one of several characteristics of trustworthy AI. Common security concerns it names include adversarial examples, data poisoning, and the exfiltration of models, training data or other intellectual property through AI system endpoints. It points to the NIST Cybersecurity Framework and the Risk Management Framework as applicable guidance, and separates resilience (withstanding and recovering from unexpected events) from security, which also covers avoiding and protecting against attacks.

Which risks should the posture checks cover?

OWASP's Top 10 for LLM and generative AI applications lists the risks that map onto lifecycle stages. Several are checkable as posture:

• Supply chain. OWASP says LLM supply chains are susceptible to vulnerabilities that affect training data, models and deployment platforms, including third-party pre-trained models, outdated packages and licensing problems. Posture check: inventory models and packages and their sources.
• Data and model poisoning. Manipulated pre-training, fine-tuning or embedding data can introduce backdoors or bias. OWASP notes that shared models can also carry code that runs when the model is loaded. Posture check: provenance and integrity of every data and model source.
• Excessive agency. Agents with too many tools, permissions or autonomy. Posture check: tool lists, scopes and approval steps.
• Sensitive information disclosure, prompt injection, improper output handling, system prompt leakage and unbounded consumption are other entries on the list that need configuration review and testing.

A constructed example

A support team ships a chatbot that answers from internal documents and can open tickets. An inventory finds a hosted model endpoint, an embedding store, a document sync job and a ticket tool. Posture checks flag four things: the embedding store accepts documents from a shared folder anyone can write to (poisoning path), the ticket tool uses an admin credential when a create-only one would do (excessive permissions), the model endpoint key sits in a repository (secrets), and an open-source model file was downloaded from an unverified source (supply chain). None is exotic. Each is a configuration fact that a regular check would catch.

How is this different from regular security posture management?

The categories are familiar: inventory, configuration, access, vulnerabilities, secrets. What changes is the asset list. It now includes models and their versions, training and fine-tuning data, vector stores, prompts, tool definitions, agent identities and the third-party services behind them. Also, behavior itself becomes a posture question, so testing outputs and tool use is part of the check, not only reading configuration.

How to check or apply this

1. Build an AI inventory: models, endpoints, datasets, vector stores, agents, tools and owners. Include shadow use, such as teams calling external APIs with personal keys.
2. Record the source and integrity of each model and dataset, and the licenses that apply.
3. Scan the code and dependencies around the AI features like any other software, and scan for exposed keys and tokens.
4. For each agent, document its tools, permissions and who it acts for, and require approval for irreversible actions.
5. Test with adversarial prompts and unexpected inputs before release and on a schedule, and log tool calls.
6. Assign owners and review cycles under GOVERN so findings lead to action.

Safeguard covers some of this on the software side: dependency and SBOM scanning for the packages around AI features, MCP Guardrail and agent identity for what agents can call and as whom, and policies and gates that can block risky changes. It does not replace a broader AI governance program.

Quick check

Sources

• NIST AI 100-1, Artificial Intelligence Risk Management Framework (AI RMF 1.0)
• NIST AI Risk Management Framework overview page
• OWASP GenAI, LLM03:2025 Supply Chain
• OWASP GenAI, LLM04:2025 Data and Model Poisoning
• OWASP GenAI, LLM06:2025 Excessive Agency

Last reviewed: 18 October 2026.