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

At a glance

What this is: ARMO argues that AI Security Posture Management is really three separate disciplines, and that most tools only cover one or two of them with depth.

Why it matters: That matters to IAM and security teams because AI agents inherit identity, privilege, and runtime risk patterns that require different controls than static cloud posture alone.

By the numbers:

• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read ARMO's explanation of what AI-SPM means for posture, IAM, and runtime control

Context

AI-SPM exists because AI workloads do not behave like traditional applications once they are in production. A dashboard can show posture findings for models, agents, IAM, and runtime, but those views often measure different risks underneath the same visual language. For identity teams, that matters because AI agents are effectively non-human identities with dynamic tool access, privilege paths, and behavioural drift.

ARMO’s article separates the category into model and artifact posture, identity and access posture, and behavioral posture. That decomposition is useful because it exposes a governance problem that many programmes miss: a tool can look comprehensive while only covering configuration, only covering reachability, or only covering runtime behavior. The result is a category label that sounds unified but operationally is not.

The article’s starting position is typical of the current market: teams are seeing the category converge faster than the instrumentation behind it. That is exactly when architecture clarity matters most.

Key questions

Q: How should security teams evaluate AI-SPM tools in practice?

A: Start by asking which discipline the tool really covers: model and artifact posture, identity and access posture, or behavioral posture. If it only inventories assets or permissions, it is not giving full AI-SPM coverage. Teams should test for runtime evidence, because declared configuration alone cannot prove what an AI agent actually did in production.

Q: Why do AI agents create a governance problem for IAM teams?

A: AI agents create a governance problem because they authenticate and act as autonomous software entities with tool access. If their actions are logged only as application activity, teams lose accountability, context, and revocation clarity. IAM must therefore extend to agent identity, delegated authority, and control-plane audit trails.

Q: What do teams get wrong about posture dashboards?

A: They often assume a dashboard equals control. In practice, dashboards describe risk, but enforcement still depends on the systems where users work and data moves. Without native blocking, restriction, or policy enforcement, the platform becomes a reporting layer rather than a containment layer.

Q: How can organisations prove their AI controls are actually working?

A: Look for evidence that policy decisions are logged, sensitive prompts are being redacted or blocked when required, and approved AI interactions are traceable by identity and business context. Effective programmes produce audit-ready records, not just policy text. If the control cannot explain what happened in a session, it is not operational enough.

Technical breakdown

Model and artifact posture depends on runtime-derived inventory

Model and artifact posture asks what AI components exist, where they came from, and whether their lineage can be trusted. That includes models, agent frameworks, MCP tools, inference servers, RAG sources, and vector stores. Static manifests are insufficient because agents can load dependencies and establish tool connections at runtime. A runtime-derived AI-BOM is therefore more useful than a build-time inventory when teams need to understand actual exposure, not declared exposure.

Practical implication: build inventory from runtime observation, not only from CI/CD and registry data.

Identity and access posture is really AI-specific IAM and RBAC

Identity and access posture examines what an AI agent can reach in production through IAM, RBAC, network policies, secrets boundaries, and data access paths. The key difference from ordinary cloud posture is that an agent may choose which tools to call at runtime, so a permission that looks acceptable in a deterministic service can become excessive in an AI workflow. This is where least privilege, blast-radius modelling, and path reachability become more relevant than simple entitlement counts.

Practical implication: assess per-agent reachability, not just role assignments or cloud policy drift.

Behavioral posture measures what agents actually do at runtime

Behavioral posture tracks live action, including API calls, tool use, data paths, and network destinations. It matters because AI agents are non-deterministic within their configured bounds, so their observed behaviour can drift without any change to declared policy. A model update, prompt change, or new integration can all alter runtime patterns. That makes behavioural baselines and drift detection essential if teams want to separate expected variation from risky access expansion.

Practical implication: use runtime telemetry to compare observed behaviour against intended workflow.

Threat narrative

Attacker objective: The attacker seeks to turn AI workload complexity into unchecked access, data exposure, or downstream control of business processes.

1. Entry occurs when an AI workload is introduced with incomplete visibility into models, frameworks, or MCP-connected tools.
2. Escalation happens when the agent inherits broader IAM, RBAC, or network reach than its real workflow requires.
3. Impact follows when runtime behaviour exploits that excess reach to access data or systems outside intended boundaries.

NHI Mgmt Group analysis

AI-SPM is becoming three different control problems, not one product category. Model inventory, IAM reachability, and runtime behaviour each answer a different governance question. Treating them as interchangeable creates false confidence because the instrumentation behind them is structurally different. Practitioners should evaluate coverage discipline by discipline, not by dashboard aesthetics.

Identity and access posture is the most immediately relevant AI-SPM layer for IAM teams. Once an AI agent can call tools, touch data, or invoke cloud services, it becomes a non-human identity with governance consequences. That makes IAM, RBAC, and secrets boundaries central to AI risk reduction, especially where the agent can choose actions at runtime. Teams should map AI agents into existing identity governance rather than assuming they sit outside it.

Behavioral posture is the named concept that most clearly separates mature AI-SPM from CSPM-with-AI-labeling. If a product cannot observe what an agent actually does, it is only measuring declared access, not lived risk. That gap matters because runtime drift is where excessive agency becomes operational, and the practitioner conclusion is simple: AI-SPM without runtime evidence remains partial control.

Model and artifact posture exposes an AI supply-chain governance gap that most organisations still underestimate. Agent frameworks, MCP tools, model adapters, and vector sources all change the trust boundary, yet they rarely appear in traditional asset inventories. That means practitioners need asset lineage, dependency review, and change control for AI components before they can claim posture is under control.

The market is converging on a shared label faster than it is converging on a shared control model. That creates buying risk as teams compare tools that appear similar but differ materially in scope. The right conclusion for security leaders is to force a control-based evaluation model, because the category will keep expanding until practitioners anchor it to concrete governance outcomes.

What this signals

Behavioral posture: the practical challenge is no longer whether you can list AI assets, but whether you can prove what each agent actually did yesterday versus what it was allowed to do. That shifts programme focus from inventory completeness to runtime evidence, and it pushes AI security closer to identity governance than many teams expect. Teams that already struggle with non-human identity visibility should assume the same blind spots will appear in AI agent estates.

Runtime evidence becomes the control boundary: if your AI programme cannot distinguish declared access from observed access, it cannot reliably prioritise blast radius reduction. The most useful next step is to connect AI posture findings to the same governance rails used for service accounts, secrets, and privileged paths, while aligning terminology with the NIST Cybersecurity Framework 2.0 and NIST AI Risk Management Framework where relevant.

A mature programme will also need to decide which signals belong in CSPM, CIEM, and identity governance, and which belong in AI-specific posture. That separation will matter more as agentic workflows expand, because the control owners for model inventory, access governance, and runtime monitoring are rarely the same.

For practitioners

• Map AI agents to identity and access controls Treat every production agent as a non-human identity with explicit ownership, scoped permissions, and revocation paths across IAM, RBAC, and secrets handling.
• Separate posture coverage by discipline Evaluate whether each AI-SPM candidate covers model and artifact posture, identity and access posture, and behavioral posture, then document which discipline is missing before purchase.
• Require runtime-derived inventory Insist on runtime observation for loaded models, framework dependencies, and MCP tool connections so your inventory reflects what is actually active in production.
• Baseline agent behaviour before expansion Record normal tool calls, API usage, and data paths for each agent, then alert on drift that expands reach beyond the documented workflow.
• Tie AI findings to existing governance Route AI posture issues into IAM review, secrets rotation, and change management so AI risk is handled through existing control owners instead of a separate queue.

Key takeaways

• AI-SPM is not one control plane. It splits into model inventory, access governance, and runtime behaviour, and each requires different instrumentation.
• The biggest risk is false equivalence. Similar dashboards can mask very different coverage, which makes control validation more important than category labels.
• Identity teams should treat AI agents as governed non-human identities. That makes reachability, secrets, and runtime drift core parts of the security conversation.

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.
• Runtime-derived AI-BOM: A runtime-derived AI-BOM is an inventory of AI components built from what is actually loaded and connected in production. It captures models, frameworks, tools, and dependencies that may never appear in static manifests, making it more accurate for real-world risk assessment.
• 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.

What's in the full article

ARMO's full blog covers the operational detail this post intentionally leaves for the source:

• A deeper breakdown of the maturity progression from static posture to runtime-informed AI-SPM
• The six interconnected components of a mature AI-SPM practice and how they fit together
• A practical evaluation scorecard for separating true runtime observability from configuration-only coverage
• Examples of where posture findings should be routed across IAM, cloud, and AI governance teams

👉 The full ARMO article expands the three-discipline model and the evaluation logic behind it.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security practitioners translate identity controls into clearer ownership and lifecycle discipline.