AISPM is becoming a continuous program, not a point-in-time checklist

At a glance

What this is: This analysis argues that AISPM is evolving into a continuous governance program, with control coverage extending across AI assets, identities, secrets, data paths, agents, and model endpoints.

Why it matters: It matters because AI security teams cannot rely on static checklists when runtime behaviour, delegated access, and data exposure paths keep changing across the AI stack.

Context

AISPM only works when it is treated as an operating model, not a periodic assessment. The control problem is broader than cloud configuration review because AI systems introduce moving parts, including agents, MCP servers, retrieval layers, model endpoints, and third-party connectors, each with its own identity and data exposure path.

That makes identity governance part of AI security governance. If teams cannot continuously inventory who and what can act, what credentials they use, and which data they can reach, the program will miss the failure modes that appear after deployment rather than during review.

Key questions

Q: What is the fastest way to start AISPM for AI systems?

A: Start with asset inventory and ownership, then map identities and scopes, then trace data exposure paths before turning to policy enforcement and runtime monitoring. This sequencing reduces blind spots because you cannot govern what you have not discovered, and you cannot control access until you know which identities and connectors carry it.

Q: Why do AI agents need special governance compared with normal applications?

A: AI agents make decisions about which tools to use and how to use them, so they can be manipulated by malicious context as well as code. That creates an NHI risk because the agent itself has delegated execution authority. Governance must cover identity, metadata trust, and action policy, not only authentication.

Q: How can security teams tell whether AI posture management is actually working?

A: It is working when teams can answer four questions quickly and consistently: who owns the agent, what it can access, which guardrails apply, and when access changed. If those answers depend on manual log-chasing, the control is too weak. Effective posture management produces usable evidence, not just a dashboard view.

Q: What is the difference between runtime AI monitoring and periodic AI security reviews?

A: Periodic reviews check whether controls were present at a point in time, while runtime monitoring shows whether AI systems are still behaving inside their approved boundaries. For AI workloads that change through usage, connectors, and retrieval paths, runtime evidence is the only reliable way to detect privilege creep, data exposure, and unsafe tool calls.

Technical breakdown

How continuous AISPM changes the control model

Continuous AISPM replaces a snapshot checklist with an evidence loop. The program has to track discovery, ownership, policy enforcement, telemetry, and remediation as linked controls rather than separate tasks. In practice, this means AI assets are not limited to models. They include agents, tool gateways, RAG stores, MCP servers, and endpoints that can change behaviour over time. Once these components can call tools, retrieve data, or mutate state, the security question becomes whether the organisation can observe and govern them throughout their lifecycle.

Practical implication: Treat AISPM as a runtime governance function, not a quarterly review exercise.

Why identities, secrets, and scoped tokens are now core AISPM controls

AI security posture is now inseparable from identity and credential scope. The article’s emphasis on upstream user identity, service identity, and executor identity shows that AI actions often pass through multiple trust boundaries before a tool is called. Scoped tokens, expiration, and centralised secrets management matter because an agent or connector with standing access can expand blast radius quickly. That is especially important where tool calls can write to ticketing systems, payment flows, or databases, because those actions turn an AI control issue into an enterprise access issue.

Practical implication: Enforce least privilege, short-lived credentials, and explicit approval for any AI tool path that can change state.

What agent and MCP server governance adds to AI security

Agent governance is about controlling what an AI system may do, while MCP server governance is about controlling the privileged integration layer it uses to do it. That distinction matters because MCP servers behave like high-value service connectors: they must authenticate, authorise, and log every tool interaction. If they are treated as ordinary app dependencies, organisations miss the fact that they concentrate access to multiple tools and datasets. The same applies to tool catalogs and blast-radius analysis, which make hidden privilege paths visible before they are abused.

Practical implication: Review MCP servers and agent tools as privileged integrations with explicit ownership, logging, and scope boundaries.

Threat narrative

Attacker objective: The attacker seeks to use AI-connected identities and tools to expand access, expose data, or perform unauthorised actions inside enterprise workflows.

1. Entry occurs when an AI system, agent, or MCP server is allowed to interact with data or tools without continuous asset and identity governance.
2. Credential access or abuse follows when scoped tokens, executor identities, or third-party connectors are over-broad, long-lived, or insufficiently monitored.
3. Escalation happens when tool calls can mutate state, pull sensitive data, or traverse retrieval layers without explicit approval or logging.
4. Impact is blast-radius expansion across workflows, data exposure, and enterprise systems, with risks persisting after initial deployment review.

Breaches seen in the wild

• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.

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

AISPM is now a continuous governance discipline, not a control checklist. The article is right to frame inventory, ownership, telemetry, and remediation as a single operating loop. AI systems change through usage, connectors, and data exposure paths, so a once-a-quarter assessment misses the real governance surface. Practitioners should treat AISPM as an always-on control plane for AI risk.

Identity is the missing backbone of most AI security programs. The article’s split between upstream user identity, service identity, and executor identity is the right way to think about AI access. Without that mapping, organisations cannot tell whether an action was human-requested, service-mediated, or agent-executed, which makes accountability and blast-radius control impossible. Practitioners should make identity lineage a first-class AISPM requirement.

AI governance debt is the right named concept for what goes wrong when controls arrive late. The program debt accumulates when agents, MCP servers, retrieval corpora, and model endpoints are deployed faster than ownership, approval, logging, and review can keep up. That debt is not abstract. It creates unowned connectors, undocumented tool paths, and delayed remediation. Practitioners should measure how much AI posture is being governed after the fact rather than at issuance time.

MCP servers deserve privileged integration governance, not generic application oversight. The article correctly elevates them to first-class assets because they concentrate tool access and can mediate state-changing actions. In governance terms, that places them closer to a privileged connector than a normal service dependency. Practitioners should align controls to the integration privilege they actually create.

ISO/IEC 42001 and NIST AI RMF provide the right governance anchors, but the control evidence has to come from runtime behaviour. Standards matter only if they are translated into inventories, approvals, logs, and remediation SLAs. A paper program will not surface prompt-driven data exposure, delegated access abuse, or anomalous tool usage. Practitioners should use the standards to structure evidence, not to substitute for it.

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.
• The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes, according to the 2024 State of Secrets Management Survey.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

AI governance debt: organisations accumulate risk whenever AI assets, connectors, and identities are deployed faster than ownership and review can catch up. The practical signal is not just that a model exists, but that it can still reach data or tools without a current evidence trail, which is why runtime governance matters more than periodic validation.

AISPM programmes will increasingly be judged by whether they can prove control over identities, scopes, and sensitive data paths, not by how many checklist items were ticked at deployment. Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs, and that visibility gap becomes more consequential as AI systems inherit service identities and tool access.

For practitioners

• Build a continuously updated AI asset inventory Track AI applications, agents, MCP servers, RAG stores, model endpoints, and training pipelines with owners, business purpose, environment, and criticality.
• Map identities end to end Record upstream user identity, service identity, and executor identity for each agent action, then enforce least privilege and short-lived scoped tokens.
• Centralise secrets and block hardcoded keys Store credentials in a secrets manager, remove embedded keys from code and configs, and set rotation intervals for every AI-connected integration.
• Treat MCP servers as privileged integrations Require authentication, authorisation, tool-call logging, and blast-radius review for every MCP server and high-risk tool gateway.
• Tie every finding to an owner and SLA Route posture findings automatically, define severity-based remediation timelines, and track closure rates and repeated exceptions over time.

Key takeaways

• AISPM is shifting from a point-in-time assessment to a continuous control program that must follow AI assets, identities, secrets, and data paths as they change.
• The hardest governance failures are now in delegated access, where agents, MCP servers, and model endpoints can expand blast radius through over-scoped credentials and weak ownership.
• Practitioners should measure AISPM by evidence quality, remediation speed, and runtime control coverage, not by whether a static checklist exists.

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.
• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• Execution Identity: An execution identity is the non-human identity that performs a task at runtime, such as a Terraform role, Kubernetes controller, or CI/CD service account. It is the identity that matters when evaluating who can actually retrieve or decrypt a secret in production.
• API Governance Debt: API governance debt is the accumulation of weak, inconsistent, or missing controls around how APIs are designed, approved, documented, secured, and retired. It creates hidden risk over time. Technically, it includes gaps in authentication, authorization, versioning, inventory, ownership, logging, and policy enforcement that make APIs harder to trust and govern.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, secrets management, and identity lifecycle control. It is designed for practitioners who need to turn identity and access principles into operational governance across modern systems.