AI security posture management is becoming the control plane for AI risk

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Cycode's blog post: AI security posture management is becoming the control plane for AI risk because AI assets, pipelines, and agents are proliferating faster than legacy controls can track them.

Why it matters: This matters because IAM, security architecture, and governance teams now have to treat AI models, MCP servers, and AI agents as governed assets, not informal tooling.

By the numbers:

• In 2024, the AI-SPM market was valued at $4.65 billion, while Forrester estimates spending on AI governance will grow to four times its current size by 2030 ($15.8 billion).
• In 2025, 16,200 AI security incidents were documented, representing a 49% year-over-year increase.
• Breaches involving AI now carry an average cost of $5.72 million.

Context

AI security posture management is the discipline of continuously discovering, assessing, and remediating AI-specific risk across models, data flows, infrastructure, and agentic components. The governance gap is that most security stacks were built for applications and cloud workloads, not for fast-moving AI assets that can appear in code, SaaS, developer tools, and runtime paths with little central oversight.

That gap matters most where AI intersects with identity and access. When AI agents invoke external tools, connect to MCP servers, or touch sensitive data stores, the control problem is no longer just model security. It becomes a question of who or what is authorised to act, what data it can reach, and how blast radius is constrained when the AI layer changes faster than review cycles.

Key questions

Q: How should teams govern AI agents that use MCP?

A: Treat each connected agent as a non-human identity with an owner, a scope, and a review cycle. The practical control set is familiar: least privilege, secret rotation, access expiration, and auditability across the systems the agent can reach.

Q: Why does shadow AI create more risk than a simple inventory gap?

A: Because unseen AI assets can still process sensitive data, reach external services, and inherit permissions from connected pipelines. The risk is not only missed visibility. It is unauthorized authority. Once an unsanctioned model or agent is inside the workflow, security teams lose the ability to validate provenance, scope, and data handling before it affects production outcomes.

Q: What are the signs that AI governance is failing in the enterprise?

A: Common warning signs include rapid growth in AI use without matching policy coverage, sensitive files being copied into personal accounts, and a large share of AI apps carrying high or critical risk. Another indicator is weak visibility into who is using which tools and what data they are sending. If teams cannot answer those questions, governance is not working as intended.

Q: Should organisations prioritise provenance controls or runtime monitoring first for AI risk?

A: Provenance controls should come first when unverified models, datasets, or dependencies can enter production, because you cannot safely monitor what should never have been trusted. Runtime monitoring still matters, especially for agents and inference endpoints, but it is a second line of defence. The right sequence is trust establishment before operational expansion.

Technical breakdown

AI asset discovery across code, cloud, and runtime

AI-SPM starts by building a continuous inventory of AI models, datasets, inference endpoints, coding assistants, MCP servers, and ML dependencies. The technical point is that AI risk is distributed across repositories, cloud services, IDEs, and pipelines, so periodic scans miss assets that developers add outside formal change control. Discovery has to be automated and traceable, with each asset linked back to ownership, repository, and deployment path. Without that evidence chain, governance cannot distinguish sanctioned AI from shadow AI or measure exposure consistently.

Practical implication: security teams need a live AI inventory tied to owners and deployment paths, not a static spreadsheet or one-time assessment.

Pipeline mapping and data flow governance

Once assets are found, AI-SPM maps how data moves through training, preprocessing, inference, and external tool calls. This is what turns a list of AI components into a control graph, showing where sensitive data enters, where it is transformed, and where dependencies widen blast radius. If a shared dataset trains several models, one poisoning event can affect multiple production workflows. If an AI agent has broad MCP access, a compromise can propagate across services that were never meant to share authority.

Practical implication: teams should map AI data flows and tool connections before approving production use, especially where one component can affect many downstream systems.

Provenance, AIBOMs, and policy enforcement

AI-SPM also addresses third-party and open-source model risk by verifying provenance, integrity, licensing, and authorization before deployment. An AI Bill of Materials gives security teams a structured record of models, datasets, and dependencies, which is essential when unverified artifacts or malicious models can introduce arbitrary code execution or hidden behaviour. The governance layer matters because manual review cannot keep pace with model churn, agent updates, and developer self-service adoption. Policy enforcement therefore has to happen inside the development lifecycle, not after release.

Practical implication: require provenance checks and an AIBOM before deployment, and enforce policy where models and agents enter the delivery pipeline.

Threat narrative

Attacker objective: The objective is to turn AI supply chain trust and overbroad AI access into data exposure, service compromise, or unreliable model output at scale.

1. Entry occurs when developers pull in third-party models, open-source AI dependencies, or unsanctioned AI assistants and MCP servers outside formal security review.
2. Credential or access abuse follows when AI agents, model registries, or connected services inherit broad permissions that were never designed for machine-speed decision making.
3. Escalation happens when a compromised model, poisoned dataset, or malicious tool integration expands its reach across linked pipelines, services, and data stores.
4. Impact is reached when the AI layer leaks data, produces manipulated outputs, or extends compromise across the production workflows that depend on it.

Breaches seen in the wild

• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).

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 becoming the policy layer for machine-speed decision systems, not just a discovery layer. The article makes clear that AI assets now span models, agents, MCP servers, datasets, and code paths, which means the security problem is governance of runtime authority as much as inventory. In practice, the field is moving from knowing that AI exists to controlling what AI is allowed to do.

Shadow AI is the more important governance failure than model count. The central risk is not only that enterprises deploy more AI, but that they cannot reliably see which tools, models, and agents are operating outside sanctioned controls. That creates an identity and authority problem as much as a cloud or application problem, because untracked AI can inherit access without a deliberate approval step.

AI Bills of Materials create a necessary accountability boundary for AI supply chains. When model provenance, dependency lineage, and authorization status are unclear, the organisation cannot prove what entered production or who owns the resulting risk. That makes AIBOM-style controls a governance requirement, not documentation overhead. Practitioners should treat provenance evidence as part of control validation.

AI agents force a rethink of blast-radius assumptions in enterprise governance. The article’s discussion of agents and MCP servers shows that a single compromised component can propagate across many connected services if permissions are too broad. That is an identity and privilege issue wrapped inside AI operations, and it means security teams need to govern delegated AI access with the same seriousness as privileged human access.

AI governance is now a compliance and operational resilience problem at the same time. With regulatory expectations rising, manual review cannot keep pace with AI adoption or with the evidence needed for auditability. The field’s real shift is toward continuous, policy-driven enforcement across the AI lifecycle. Practitioners should assume that governance failure will show up first as operational drift, then as audit exposure.

From our research library:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to the State of Secrets in AppSec.
• Read next: NHI Lifecycle Management Guide

What this signals

AI posture management changes the unit of control from the application to the AI workload. Security teams should expect discovery, lineage, and policy enforcement to become part of the same operational loop that already governs code and cloud. That shift matters because AI assets can appear and mutate faster than quarterly review cycles, so control coverage now depends on continuous evidence rather than periodic approval.

AI governance debt will accumulate where model provenance and access decisions are still manual. The practical signal for readers is that untracked AI tools, agents, and dependencies will eventually surface as audit gaps, exposure gaps, or business continuity issues. Teams that cannot map AI ownership and authority paths should treat that as a programme-level resilience problem, not a tooling inconvenience.

For practitioners

• Implement continuous AI asset discovery Build a live inventory of models, datasets, inference endpoints, MCP servers, coding assistants, and ML dependencies across repositories, cloud, and developer environments.
• Map AI data flows and authority paths Document how data moves from ingestion to inference and which services or agents can invoke external tools, so broad access scopes are visible before deployment.
• Require provenance checks before production use Block unverified models and dependencies until provenance, licensing, and authorization status are recorded in an AI Bill of Materials.
• Enforce policy inside the delivery lifecycle Push AI governance controls into IDE, PR, CI/CD, and runtime stages so approvals, risk scoring, and remediation happen before release rather than after.
• Separate sanctioned AI from shadow AI Classify AI tools and agents by business owner and permitted data scope, then remove or isolate anything that cannot be tied to an accountable owner.

Key takeaways

• AI security posture management is emerging as the control plane for AI because models, agents, and data pipelines now expand faster than legacy security review can follow.
• The article links that shift to measurable exposure, including 16,200 documented AI security incidents in 2025 and materially higher breach costs when shadow AI is involved.
• Practitioners need continuous discovery, provenance validation, and policy enforcement inside the delivery lifecycle if they want AI governance to keep pace with adoption.

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.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• AI bill of materials: An inventory of the components used by an AI development environment, including models, plugins, hooks, skills, and agent integrations. It gives security teams visibility into what is operating in the stack so they can assess trust, dependency risk, and governance coverage.
• 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.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management in a way that helps practitioners connect machine authority to security control design. It is suitable for teams building stronger identity governance across human, non-human, and AI-adjacent programmes.