Agent-SPM vs AI-SPM: what coding agents change for security teams

At a glance

What this is: This is an analysis of why AI usage controls and AI-SPM stop short of governing coding agents, and why Agent-SPM is framed as the layer that tracks agent behaviour, connections, and blast radius.

Why it matters: It matters because IAM and security teams need controls that address autonomous agents as operating identities, not just approved tools or static AI assets, if they want governance to keep pace with deployment speed.

Context

AI usage controls and AI-SPM solve different parts of the AI security problem, but neither is sufficient when coding agents are being deployed faster than teams can inventory them. The governance gap is not simply visibility, it is that autonomous agents can act, connect, and expand access without fitting the human-centred policy models most organisations started with.

In this article's framing, the security question shifts from who is using AI to what the AI system can do once it is already running. That matters for identity governance because coding agents can behave like non-human identities with tool access, MCP connections, and permissions that need explicit lifecycle control.

Key questions

Q: How should security teams govern AI coding tools that create non-human identities?

A: Teams should treat every AI coding tool that can authenticate or call systems as a non-human identity with an owner, a scope, and a lifecycle. That means inventorying its credentials, limiting its permissions, monitoring its runtime actions, and revoking access when the task ends. Security policy should cover the agent, not just the code it helps produce.

Q: Why do AI usage controls fail once autonomous agents start acting independently?

A: AI usage controls are designed to watch human interaction with AI services, not software that runs, calls tools, and chains tasks on its own. Once an agent is deployed as infrastructure, the relevant risk becomes delegated access and runtime reach, which usage controls were never built to govern.

Q: What are the signs that AI-SPM is not enough for an agentic environment?

A: If your inventory covers models and applications but not which agents can reach production systems, MCP servers, or downstream tools, AI-SPM is stopping too early. The gap shows up when you can name the asset but not explain the agent's actual action scope or blast radius.

Q: What should teams do when coding agents can create more agents than security can catalogue?

A: Move from periodic catalogues to continuous discovery, permission scoping, and connection mapping for every agent. The practical test is whether security can explain each agent's current authority before the next deployment wave makes the last inventory obsolete.

Technical breakdown

Why AI usage controls stop at the human user

AI usage controls are built to govern people using AI services through sanctioned or unsanctioned interfaces. They work when the risk is a developer pasting sensitive data into a chatbot or adopting shadow AI without approval. They do not govern an autonomous agent that has been deployed as infrastructure, calls APIs directly, or chains actions without a browser session. In other words, the control boundary is the human interaction, not the agent's operating scope. Practical implication: treat usage controls as a human-behaviour layer, not a substitute for governing agent privileges, connections, and runtime behaviour.

Practical implication: treat usage controls as a human-behaviour layer, not a substitute for governing agent privileges, connections, and runtime behaviour.

How AI-SPM maps AI assets but misses agent behaviour

AI-SPM is designed to discover and assess AI assets such as models, applications, data pipelines, and infrastructure. That makes it useful for configuration exposure, missing controls, and compliance gaps in AI systems. The limitation is that a static inventory cannot fully represent an agent that decides when to call a tool, what data to touch, and how to chain tasks across systems. Once an agent can write to production or reach an MCP server, the relevant risk is no longer only configuration. It is behavioural reach and the blast radius created by that reach. Practical implication: extend posture reviews from AI assets to the actions those assets can actually execute.

Practical implication: extend posture reviews from AI assets to the actions those assets can actually execute.

Agent-SPM and MCP connections define the real attack surface

Agent-SPM is aimed at the agentic layer itself, including permissions, tool integrations, MCP server relationships, and agent-to-agent links. That matters because these connections are where compromise turns into operational impact. If an agent is overprivileged, trusted across tools, or allowed to reach unvetted external sources, a single malicious prompt or poisoned tool path can expand into a multi-system incident. The security problem is not merely that the agent exists. It is that the agent has a governed identity surface, and that surface can be wider than the teams deploying it understand. Practical implication: inventory and constrain every agentic connection as part of access governance.

Practical implication: inventory and constrain every agentic connection as part of access governance.

NHI Mgmt Group analysis

Agent-SPM is the missing governance layer for autonomous non-human identities. The article correctly separates human AI usage controls from the controls needed for agents that act independently. Once a coding agent can create other agents, connect to MCP servers, and inherit permissions, the problem is no longer acceptable use, it is lifecycle governance for a non-human operating identity. Practitioners should treat agent discovery, authorization, and offboarding as a single control plane, not three disconnected conversations.

AI-SPM is necessary, but it is not sufficient for agentic environments. AI-SPM remains relevant for models, pipelines, and exposed AI infrastructure, but it does not fully represent decision-making behaviour or delegated tool use. That distinction matters because modern risk sits in what an agent can do after deployment, not just in whether the underlying system is configured cleanly. Security teams should re-evaluate whether their AI posture tooling understands action scope as well as asset scope.

Blast-radius governance is now the decisive control question. The article's central warning is that coding agents outpace catalogue-based oversight. That creates a governance trust gap: teams assume they can review what they can enumerate, but agents can be active before the inventory is current. The field needs controls that measure who or what an agent can reach, not just whether the agent is known. Practitioners should prioritise permissions, integration boundaries, and runtime containment.

Agent identity and authorisation must be explicit, not inferred from deployment context. A deployed agent is not secure because it came from an approved team or was built with a familiar coding assistant. Once it is connected to enterprise systems, its authority needs to be defined, limited, and continuously reassessed. For identity programmes, that means extending IAM and PAM thinking into agentic systems where access is granted to software that behaves like a delegated actor.

Agent inventory is becoming an operational control, not a documentation exercise. The article shows that velocity alone can defeat quarterly policy cycles. That makes continuous discovery, access scoping, and connection mapping a baseline requirement for AI governance. Practitioners should not measure success by the number of approved tools alone, but by whether they can explain every agent's permissions and failure mode.

From our research library:

• Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

Agentic governance is becoming an identity problem as much as an AI problem. Once coding agents can create or modify other agents, the control question shifts from usage policy to delegated authority. Security teams should expect agent inventories to drift quickly unless discovery, authorisation, and offboarding are treated as one lifecycle.

Non-human identity thinking now has to include behaviour, not just credentials. A static service account model is not enough when software can choose tools, chain tasks, and expand its own reach. Agent programmes need explicit boundaries for what an agent may do, not just what secret it uses to connect.

The operating risk is blast radius, not just shadow AI. Human-facing AI controls still matter, but they miss the software layer that coding agents are creating underneath them. Security teams should prepare for a world where the important question is whether an agent can reach production systems before governance notices it exists.

For practitioners

• Establish a separate control plane for autonomous agents Classify coding agents as governed non-human identities with their own approval, review, and retirement process rather than treating them as ordinary AI tools.
• Inventory agent permissions and MCP connections continuously Track every agent, the tools it can call, the MCP servers it reaches, and the data sources it can access so the exposure map stays current.
• Limit agent blast radius by default Remove unnecessary write access, production reach, and cross-system delegation from agents that do not explicitly need those privileges.
• Review agent deployment paths as a governance issue Require security review before coding agents can create downstream agents, connect to enterprise systems, or inherit existing credentials and permissions.
• Combine usage controls with posture management Keep AI usage controls for human shadow AI, but pair them with posture management that can assess the agentic layer and its runtime reach.

Key takeaways

• AI usage controls and AI-SPM address real problems, but they do not fully govern autonomous coding agents that can act outside human approval flows.
• The core exposure is delegated agent authority, especially when agents can connect to MCP servers, tools, and enterprise systems faster than inventories update.
• Security teams need continuous discovery, explicit authorisation, and blast-radius limits for agents if they want governance to keep pace with deployment velocity.

Key terms

• Agent-SPM: Agent-SPM is security posture management for AI agents. It focuses on discovering agents, their tools, their data sources, and the permissions they carry so teams can understand exposure, scope, and change over time.
• AI-SPM: AI Security Posture Management extends security visibility into AI models, prompts, outputs, and supporting workflows. It gives teams a way to identify risky AI usage, check policy alignment, and monitor how AI systems interact with data and identity controls over time.
• AI usage control: AI usage control is the governance of prompts, outputs, uploads, and copy-paste behaviour when people or systems interact with generative tools. It is not just content filtering. It is a policy model that decides what may be submitted, what may leave the session, and what must be blocked.
• 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

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, and secrets management. It gives practitioners a common control language for governing the software entities now operating inside modern environments.