AI-SPM splits into three disciplines, and most tools cover one

At a glance

What this is: ARMO argues that AI-SPM is fragmenting into three distinct disciplines, and most tools only cover one or two of them with real depth.

Why it matters: That matters because IAM, runtime monitoring, and model inventory are different control problems, and practitioners need to know which layer their AI posture tooling actually measures.

Context

AI Security Posture Management is meant to close the gap between what AI workloads are configured to access and what they actually do at runtime. The problem is that AI systems combine model artefacts, identity reachability, and behavioural drift in ways that do not fit a single posture view, so a dashboard can look complete while missing the layer that matters most.

For IAM, NHI, and AI security teams, the governance question is not whether an AI workload has a posture score but which part of the workload stack the score represents. That distinction becomes central when service accounts, tool permissions, MCP connections, and runtime behaviour all create different risk surfaces in the same deployment.

Key questions

Q: How should teams evaluate AI-SPM tools when the market uses the same dashboard language for different controls?

A: Start by mapping the product to the discipline it actually measures. If it only inventories models or flags cloud permissions, it is not automatically covering runtime behaviour. The right evaluation question is whether the tool’s instrumentation can prove what the workload loads, can reach, and actually does in production.

Q: Why do AI agents create more posture risk than ordinary cloud workloads?

A: Because their runtime choices are only partly constrained by configuration. A service account or tool permission may be acceptable for a predictable workload, but an AI agent can decide to call new tools, access new data paths, or shift behaviour after a prompt or model change.

Technical breakdown

Model and artifact posture depends on AI-BOM quality

Model and artifact posture asks what models, agent frameworks, MCP tools, and supporting components exist in the environment, where they came from, and whether their provenance is trustworthy. This is closest to an AI-specific software bill of materials, but with extra concern for dynamic dependencies that appear only at runtime, such as adapters, tool definitions, and model connections. Static manifests rarely capture that full picture. A useful AI-BOM must therefore combine registry data, build metadata, and runtime observation so teams can see what is actually loaded and in use, not just what was declared during deployment.

Practical implication: Treat AI-BOM quality as the first test of posture coverage for the model layer.

Identity and access posture tracks reachable surface, not intent

Identity and access posture examines what an AI agent can reach, including IAM roles, Kubernetes RBAC bindings, network policies, secrets boundaries, and data paths. The key issue is that permissions inherited from cloud or platform defaults may be acceptable for deterministic services but excessive for systems that choose actions at runtime. In practice, the analysis is about blast radius, path reachability, and whether configured access matches the agent’s real workflow. This is why AI-SPM often resembles CIEM or CSPM in this discipline, even though the operational context is different.

Practical implication: Measure agent reachability separately from human and service account access reviews.

Behavioral posture needs runtime evidence to detect drift

Behavioral posture evaluates what an agent actually does, including tool calls, API requests, network destinations, and changes over time. Unlike traditional applications, AI agents are not fully determined by configuration, so two workloads with the same permission set may carry very different risk depending on how they behave. This is the discipline that needs runtime sensors because configuration alone cannot tell you whether an agent is using authorized access appropriately or expanding into new actions after a prompt change or model update. It is also where drift detection becomes a security control rather than a convenience feature.

Practical implication: Base alerting and prioritisation on observed runtime behaviour, not on declared access alone.

Threat narrative

Attacker objective: The attacker objective is to exploit whichever AI-SPM layer is least instrumented so that overreach, drift, or hidden dependencies remain invisible during operations.

1. Entry occurs when AI workloads inherit broad permissions, tool access, or MCP connections that were provisioned for convenience rather than verified use.
2. Credential or access abuse follows when the agent can invoke resources that are outside its intended workflow, even if the configuration appears normal.
3. Impact appears as expanded blast radius, because static posture cannot distinguish a harmless permission from one the agent is actively using in production.

Breaches seen in the wild

• Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI-SPM is fragmenting into three control planes, not one category. Model inventories, access reachability, and runtime behaviour answer different security questions and require different sensors. That means a single dashboard score can easily conceal missing coverage in the very layer that carries the greatest risk. Practitioners should treat coverage claims as instrumentation claims, not category claims.

Runtime context is now the decisive trust signal for AI workloads. Static posture tells you what was configured, but AI agents decide what to call, when to call it, and how far to extend their actions. That makes runtime evidence the difference between theoretical compliance and operational security. Security programmes should assume that configuration-only AI-SPM will understate behavioural risk.

Identity and access posture becomes more fragile when the subject is an agent rather than a service. The same IAM or RBAC grant can be routine for a deterministic workload and excessive for an AI system with autonomous tool selection. This is the governance gap that many tools gloss over when they present cloud-style findings without agent-specific context. Practitioners should re-evaluate least-privilege assumptions through the lens of agent decision-making.

Model and artifact posture needs an AI-BOM that captures what runtime loading actually introduces. The important control failure is not just missing inventory, but incomplete inventory that omits dynamically loaded frameworks, tools, and connectors. That creates governance debt because teams think they have reduced the attack surface when they have only reduced visibility. Security architects should anchor this layer in observed dependencies, not declared ones.

Behavioral posture is where AI-SPM becomes a security discipline rather than a compliance label. Once agents can drift, learn, or change tool-use patterns over time, posture has to measure action, not just configuration. This is where AI security converges with detection engineering, and where the market will likely differentiate between dashboard products and genuine runtime controls. Practitioners should expect the strongest programmes to privilege evidence over inventories.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Only 23% of IT leaders were very confident in their organisation's ability to manage security and governance for GenAI deployments, according to a 2025 Gartner survey of 360 IT leaders.
• Read next: NHI Lifecycle Management Guide

What this signals

AI posture programmes will increasingly be judged by the discipline they can actually observe. Teams that can only inventory models or cloud permissions will miss the behavioural layer where agent risk becomes operational. The practical response is to align tool selection with the control plane you need most, then challenge any product that cannot explain its runtime evidence model.

Model and artifact coverage without runtime visibility creates false confidence. The next phase of AI security will separate configuration reporting from genuine posture control, and that split will matter most where agents can call tools, move data, or expand access after deployment.

24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026. That scale is a reminder that AI-SPM programmes which ignore tool-layer inventory and secret exposure are already behind the risk curve.

For practitioners

• Define which AI-SPM discipline you are buying Map each candidate tool to model and artifact posture, identity and access posture, or behavioral posture, then reject any claim that it covers all three without distinct instrumentation evidence.
• Validate runtime-derived AI inventory Require an AI-BOM or equivalent inventory that is built from observed components, not only manifests or registry metadata, before you accept posture coverage for models, frameworks, and MCP tools.
• Separate permission review from behaviour review Assess agent reachability with IAM, RBAC, and network policy data, then confirm whether the agent actually uses those paths at runtime before you rank the finding.
• Instrument drift detection for agent actions Track tool calls, API usage, and destination changes over time so you can tell whether a model update or prompt change altered the agent’s operating pattern.
• Prioritise coverage gaps by discipline If your AI platform is strongest in inventory and weakest in runtime visibility, treat behavioural posture as the first gap to close because it is the layer configuration-only tools miss most often.

Key takeaways

• AI-SPM is not one control plane but three, and each one needs different instrumentation to produce a meaningful security finding.
• Tools that only scan configuration or inventory can miss the layer where AI agents actually change behaviour in production.
• Practitioners should judge AI-SPM by the evidence it collects at runtime, not by whether the dashboard looks complete.

Key terms

• AI Security Posture Management: A governance approach for discovering and tracking AI assets such as models, agents, datasets, vector stores, and related infrastructure. It becomes useful only when inventory is connected to runtime exposure and the identity that can actually reach the data.
• AI-BOM: An AI bill of materials is a structured inventory of the components that define an AI agent, including the model, prompt, tools, retrieval sources, and dependencies. In practice, it is the evidence base for review, change control, and risk assessment when the agent evolves after deployment.
• Behavioural posture: Behavioural posture is the real operating state of a security control as shown by live activity, not its declared configuration. It measures whether identities, access paths, and enforcement points are being used as intended in production, which is often different from what policy or compliance tools report.
• Identity and Access Posture: Identity and access posture is the assessment of what an AI agent can reach through permissions, policies, and secrets. It focuses on IAM, RBAC, network rules, and data access paths, with the goal of measuring blast radius rather than simply counting entitlements.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is designed for teams that need a practical control model for AI agents, machine identity, and access governance.