AI-SPM is becoming a baseline control for agentic AI security

At a glance

What this is: AI-SPM is a control approach for continuously discovering, assessing, and governing AI systems, with the article arguing that it addresses AI-specific risks such as prompt injection, shadow AI, and over-privileged access.

Why it matters: For IAM practitioners, AI-SPM matters because AI agents, MCP-connected tools, and LLM workflows introduce identity, access, and runtime governance problems that existing cloud and data posture tools do not fully cover.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Akto's complete guide to AI Security Posture Management

Context

AI Security Posture Management sits at the point where AI operations, identity governance, and security posture management overlap. AI systems are not static assets. They change with prompts, tools, memory, retraining, and third-party integrations, which means conventional cloud posture and data posture models miss the behaviour that creates real risk.

For NHI Mgmt Group, the important shift is that AI agents behave like governed identities as soon as they can act through APIs, databases, messaging systems, or MCP-connected tools. That creates a security problem that is part IAM, part NHI governance, and part AI runtime control. The article's starting position is typical for the market: most organisations still describe the risk as an AI tooling gap when it is actually an identity and access boundary problem.

Akto frames AI-SPM as the layer that discovers shadow AI, tests runtime behaviour, and enforces guardrails. The deeper issue is that AI systems now hold credentials, touch sensitive data, and execute actions, so visibility without access control leaves a large gap between policy and practice.

Key questions

Q: How should security teams govern AI agents that can access enterprise systems?

A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring. The control set should include inventory, task-bound credentials, audit trails, and revocation paths. If an agent can call tools or touch production systems, it belongs in the same governance model as service accounts and other machine identities.

Q: Why do AI agents create risks that CSPM and DSPM do not fully cover?

A: CSPM focuses on infrastructure settings and DSPM focuses on data visibility, but AI agents change behaviour through prompts, tools, and memory. That means the risk can appear at runtime even when cloud and data posture look clean. Organisations need controls that govern how the agent acts, not just where it runs or what data it stores.

Q: What breaks when AI controls stop at pre-deployment testing?

A: Pre-deployment testing cannot stop a compliant model from making risky decisions in a live workflow or through connected tools. That leaves regulated data exposure, agent misuse, and weak audit trails unaddressed. Teams need controls that follow the interaction at runtime, because many failures only appear once the system is operating with real users, real data, and real permissions.

Q: Which frameworks should organisations use for AI-SPM and agent governance?

A: Start with NIST AI RMF for governance, OWASP Agentic AI Top 10 for application risks, and CSA MAESTRO where multi-agent threat modelling is needed. If the agent acts like a non-human identity, add IAM and NHI governance controls so access, ownership, and revocation are explicit and auditable.

Technical breakdown

How AI-SPM discovers AI assets and shadow AI

AI-SPM begins by building an inventory of models, agents, datasets, pipelines, and connected tools. That inventory matters because AI risk is often hidden across SaaS AI tools, code repositories, cloud services, and MCP-style integrations that are easy to miss in conventional asset management. Shadow AI becomes a governance issue when employees can route sensitive data into unapproved models or plugins without review. AI-BOM concepts extend software bill of materials thinking to model dependencies, training data, and runtime interfaces.

Practical implication: inventory AI assets continuously and treat undiscovered agents or models as unmanaged identities until they are approved and constrained.

Why runtime monitoring is different from pre-deployment testing

AI systems are probabilistic and stateful, so passing a pre-production test does not mean the system remains safe in operation. Runtime monitoring looks for prompt injection, tool misuse, anomalous queries, data leakage, and behavioural drift as the agent interacts with live data and external systems. For agentic systems, this is critical because valid credentials can still be misused if the workflow itself has been manipulated. In practice, AI-SPM becomes a control plane for behaviour, not just configuration.

Practical implication: monitor prompts, tool calls, and outputs in production and wire high-risk events into security operations workflows.

How guardrails and least-privilege access reduce AI agent risk

Guardrails are the enforcement layer that limits what an AI system can see, say, and do. In an identity context, that means scoping tool permissions, restricting data access, filtering inputs and outputs, and applying policy to human and non-human identities that interact with the model. This is where AI-SPM intersects directly with IAM and NHI governance. If an agent can reach a database, send email, or invoke code execution, the access model must be explicit and revocable, not implied by application convenience.

Practical implication: bind each agent to a narrow privilege set and review any MCP or API connection as if it were a new machine identity.

Threat narrative

Attacker objective: The attacker aims to convert a trusted AI workflow into a privileged execution path that exposes data, misuses tools, or triggers unauthorised actions at scale.

1. Entry occurs when an attacker injects malicious prompts, exploits shadow AI usage, or abuses a third-party integration that was never formally reviewed.
2. Escalation happens when the AI agent uses valid tool permissions to access email, databases, code execution, or sensitive data beyond its intended task.
3. Impact follows when the manipulated system leaks data, performs unauthorised actions, or propagates unsafe decisions into downstream workflows.

NHI Mgmt Group analysis

AI-SPM is becoming the governance layer that turns AI behaviour into an identity problem. Once an AI system can call tools, touch data, and act without a human approving every step, it starts to resemble a non-human identity with runtime authority. That shifts the governance burden from simple model inventory to access boundaries, permission scope, and revocation discipline. Practitioners should treat AI-SPM as part of identity control, not just AI hygiene.

Shadow AI creates a verification trust gap that existing posture tooling cannot close. The article is right to emphasise discovery because organisations cannot govern what they cannot enumerate, but discovery alone is not enough. The real failure mode is unmanaged access to models, plugins, and MCP-connected services that sit outside standard review paths. Verification trust gap: the period between AI tool adoption and policy enforcement, when data and credentials can move through unapproved paths. Practitioners should close that gap with inventory, approval, and continuous attestation.

Prompt injection is only half the story. The more dangerous issue is legitimate privilege abuse. AI security programmes often focus on malicious inputs, but the article also highlights authorised tools being used in unintended ways. That is an IAM and NHI control problem because the attacker does not need to break authentication if the agent already has too much access. Security teams should align AI guardrails with least privilege and task-scoped access, especially where agents can reach customer data or operational systems.

AI-BOM thinking will matter as much for governance as it does for supply chain security. Model dependencies, datasets, integrations, and runtime connectors all shape the blast radius of an AI deployment. In practice, AI-BOMs give compliance teams and security architects a common language for what is connected, who owns it, and what can be revoked. The field should expect AI-SPM to converge with IAM, GRC, and data security controls rather than remain a standalone category.

AI-SPM will accelerate the shift from static reviews to continuous policy enforcement. AI systems change too quickly for point-in-time assessment to be enough, especially when prompts, tools, and data sources are updated after deployment. That makes runtime telemetry, guardrails, and policy drift detection central to governance. Practitioners should plan for AI-SPM to become part of normal security operations, not an isolated pilot.

What this signals

AI-SPM will increasingly sit alongside IAM and NHI governance rather than beside CSPM and DSPM. The practical implication is that organisations need one view of who or what is allowed to act, whether that actor is a person, service account, or AI agent. Where MCP connections are in use, the trust boundary is no longer the model alone but the full chain of tools and data sources it can reach.

Behavioural control plane: AI programmes will need a policy layer that tracks what the system is allowed to do in runtime, not just what it is configured to do at rest. That means security teams should expect logging, approval, and revocation workflows to expand into the AI stack. The relevant standards conversation is already forming around the NIST AI Risk Management Framework and the OWASP Top 10 for Agentic Applications 2026.

As AI adoption scales, the question will shift from whether organisations have AI tools to whether they can prove those tools are governed. The programmes that move early on inventory, access scoping, and runtime telemetry will be better placed to handle compliance, incident response, and shadow AI clean-up when the next workflow expands.

For practitioners

• Inventory every AI asset and connector Build a live inventory of models, agents, MCP servers, plugins, datasets, and API integrations. Treat any unapproved AI tool as shadow AI until ownership, purpose, and data access are formally recorded.
• Scope agent permissions to task-level access Assign each AI agent the smallest set of actions and data sources required for its job. Review email, database, and code execution permissions as privileged access, not default application functionality.
• Monitor prompts, tool calls, and outputs in production Send AI runtime telemetry into SIEM or SOC workflows so prompt injection, unsafe tool use, and data leakage can be investigated quickly. Include audit logs for model decisions and connector activity.
• Map AI governance to identity and access controls Align AI-SPM with IAM and NHI processes so approvals, reviews, and revocations cover AI identities as well as human users. Where MCP is used, treat each connection as an externally reachable trust boundary.
• Test runtime behaviour, not just deployment posture Use adversarial probes and red teaming to validate how models and agents behave under prompt injection, policy bypass, and unauthorised tool requests. Re-test after material changes to prompts, tools, or datasets.

Key takeaways

• AI-SPM is emerging as the control model for AI systems that act, connect, and change at runtime.
• The main governance gap is not model visibility alone, but unmanaged privilege across agents, tools, and data paths.
• Security teams should fold AI-SPM into IAM, NHI, and monitoring workflows before agent deployments expand further.

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.
• Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions — including calling APIs, writing code, and orchestrating other agents — with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
• 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.

What's in the full article

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

• Step-by-step AI-SPM workflow examples for discovery, runtime monitoring, and guardrail enforcement.
• Implementation detail on how Akto Argus probes prompt injection, unsafe tool execution, policy bypass, and sensitive data exposure.
• Practical guidance on integrating AI-SPM with cloud-native environments, SIEM workflows, and CI/CD pipelines.
• Examples of how the vendor maps AI-SPM to agent identity security and enterprise deployment patterns.

👉 Akto's full post covers the AI-SPM control model, runtime guardrails, and deployment considerations in more detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management in the context of modern identity programmes. It helps security practitioners connect AI agent access, machine identity, and operational control into one governance model.