Agentic security graph visibility is becoming the AI control gap

At a glance

What this is: This is an analysis of the Agentic Security Graph, a visibility model for mapping how AI agents connect to MCP servers and APIs across an enterprise.

Why it matters: It matters because IAM, PAM, and AI governance teams need context on agent relationships and privileges before they can scope least privilege, detect abnormal behaviour, or safely decommission machine access.

By the numbers:

• 82% of organizations discovered AI agents in their environment that they did not know existed.
• 65% of organizations have already experienced a security incident related to AI agents.
• 7% of security leaders admit they do not know how often their AI systems are making autonomous changes to infrastructure.
• Only 44% of organizations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.

👉 Read Salt's analysis of the Agentic Security Graph for AI security

Context

Agentic security graph visibility is a response to a familiar governance problem in a new form: organisations cannot control what they cannot enumerate, and conventional inventories do not capture relationships between AI agents, MCP servers, and downstream APIs. In practice, that means security teams often know an agent exists without knowing what it can reach, what it can change, or which credentials it uses to act.

For IAM and NHI programmes, the issue is not simply more automation. It is that agentic systems create chains of delegated access that must be mapped, reviewed, and revoked like any other identity pathway. That makes the Agentic Security Graph relevant to machine identity governance, secrets management, and the operational boundary between approved and shadow AI activity.

Key questions

Q: How should security teams govern MCP-enabled AI assistants that can act on tools and data?

A: Treat MCP-enabled assistants as non-human identities with scoped authority, not as passive interfaces. Put a policy decision point between interpretation and execution, require explicit confirmation for privileged actions, and restrict which context sources the assistant may trust. Governance should focus on preventing unverified input from becoming executable intent.

Q: Why do shadow agents create a bigger risk than ordinary automation?

A: Shadow agents create more risk because their authority can expand quietly as teams adapt them to new tasks. Ordinary automation usually has a narrower, more fixed control path. Shadow agents can cross systems, accumulate permissions, and continue acting without a clear owner, which makes accountability and containment much harder.

Q: What do teams get wrong about least privilege for AI agents?

A: They often stop at permission scope and ignore behavioural scope. An agent can have narrow access and still be risky if it can independently select targets, chain tool calls, and trigger irreversible actions. Least privilege is necessary, but it does not describe the agent's freedom to act.

Q: Who is accountable when an AI agent uses delegated access incorrectly?

A: Accountability should follow the delegated authority chain, not stop at the agent label. The relevant owners are the teams responsible for the human identity, the service identity, the workflow, and the policy that allowed the action path. If those responsibilities are not explicit, incident review will be incomplete and remediation will focus on the wrong layer.

Technical breakdown

What the agentic security graph maps across LLMs, MCP servers, and APIs

The Agentic Security Graph is a relationship map, not a simple asset inventory. It links the LLM making decisions, the MCP server that brokers tool and data access, and the APIs or services that ultimately execute actions. That matters because risk sits in the edges between components, not only in the components themselves. An agent may appear low risk until the graph shows it can query sensitive data, trigger workflows, or write into production systems through an MCP server that was broadly provisioned at deployment. The graph turns hidden trust chains into visible control points.

Practical implication: map agent-to-tool-to-API paths before approving production access.

Why shadow agents and MCP sprawl create blind spots for identity governance

Shadow agents emerge when teams deploy agentic workflows without central review, then connect them to internal systems using whatever access is easiest. MCP sprawl compounds that problem because new servers can be stood up quickly, granted broad permissions, and forgotten. From an identity perspective, these are unmanaged machine access paths with unclear ownership, unclear lifecycle, and unclear privilege boundaries. Traditional IAM tools often miss the full sequence because they track identities and entitlements, not the runtime relationships that agents use to act.

Practical implication: require registration, ownership, and review for every agent and MCP server.

How the graph changes blast-radius assessment for agentic AI

Blast radius is the practical value of the graph. Once security teams know which agents can reach which APIs, and whether those APIs are read-only or write-capable, they can separate nuisance exposure from enterprise-impacting exposure. That context also improves detection, because anomalous behaviour only stands out when you know the expected route, scope, and payload pattern for each agent. In agentic environments, the control question is not whether an agent exists, but whether its reachable action space is bounded tightly enough to survive a mistake or compromise.

Practical implication: tie access reviews and detections to reachable actions, not just named identities.

Threat narrative

Attacker objective: The attacker aims to abuse hidden agentic access paths to reach data, tools, or infrastructure that should not be available from the original deployment point.

1. Entry occurs when a team deploys an agent or MCP server without full security review, then links it to internal tools or data sources through broad default permissions.
2. Escalation follows when the agent gains access to APIs or services beyond its intended scope, allowing it to touch more systems than the business owner realised.
3. Impact is realised when the exposed chain enables data leakage, unsafe infrastructure changes, or other actions that expand the blast radius across the environment.

NHI Mgmt Group analysis

Agentic security graph visibility is now a governance requirement, not an optional observability layer. The article describes a control problem that identity teams will recognise immediately: delegated access becomes dangerous when the full path from decision to action is invisible. In NHI terms, the graph is the missing relationship model for machine identities, secrets, and runtime permissions. Practitioners should treat this as a control boundary for agentic AI, not a dashboard feature.

Shadow agent sprawl creates the same lifecycle failure pattern that weak NHI programmes create for service accounts. The difference is speed. Agents and MCP servers can appear faster than traditional onboarding and review processes can absorb them, which means ownership and offboarding become the weak points. That aligns closely with OWASP-NHI themes around unmanaged machine identities and lifecycle drift. Security teams need to govern agent registration, privilege scope, and retirement as a single lifecycle.

Agentic risk is becoming a blast-radius problem before it becomes a model-risk problem. Many discussions around AI still focus on prompts or outputs, but the article shows the operational danger is the system of connected access behind the model. Once an agent can reach APIs, the question shifts to what it can change, not just what it can say. That framing is especially relevant for IAM, PAM, and NHI teams responsible for limiting action scope.

Context-aware detection will outperform perimeter thinking in agentic environments. WAFs, SIEM rules, and endpoint tools still matter, but they are not enough when the behaviour of concern happens inside approved connections. The named concept here is agentic relationship blind spot: the failure to see how an agent, its broker, and its target systems combine into one effective privilege path. Practitioners should build controls around that path, not around isolated components.

Enterprise AI governance will increasingly be judged by whether organisations can prove what agents were able to do, not whether they knew agents existed. That is a shift from discovery to accountability. In a mixed human and machine identity estate, the evidentiary question will be whether teams can reconstruct authority, route, and action after the fact. Security leaders should expect board and regulator scrutiny to move in that direction.

What this signals

Agentic relationship blind spot: organisations will increasingly need to measure the gap between knowing an agent exists and knowing what it can actually reach. That gap will define whether identity governance can keep pace with AI deployment, especially where machine identities, secrets, and API access intersect.

The operational signal to watch is not simple AI adoption, but uncontrolled path growth across MCP brokers and downstream services. Teams that can tie agent approvals to reachable actions, offboarding, and audit evidence will be better placed to answer board questions about autonomous access and blast radius.

The broader programme implication is that agentic AI will force IAM, PAM, and AI governance to converge around runtime access paths. Frameworks such as the NIST AI Risk Management Framework and the OWASP Top 10 for Agentic Applications 2026 provide useful language for that convergence.

For practitioners

• Inventory agentic paths end to end Map every agent, MCP server, and API relationship in production, including shadow deployments and business-unit workflows that bypass central review.
• Tie approvals to reachable actions Approve access based on what an agent can actually touch or change, not on the name of the workflow or the team that created it.
• Build lifecycle controls for machine agents Assign ownership, review cadence, and offboarding steps for each agent and MCP server so access can be revoked when the use case ends.
• Correlate detections to normal agent behaviour Baseline expected API calls, payload shapes, and target systems so anomalous agent activity can be flagged in context rather than as generic noise.

Key takeaways

• The core risk is not simply that AI agents exist, but that most organisations cannot see the full access paths they create.
• Evidence in the article and cited research points to widespread shadow agents, broad access, and insufficient policy coverage for agentic systems.
• The practical response is to govern the relationship graph, because least privilege and detection only work when the full action path is known.

Key terms

• Agentic Security Graph: A relationship map showing how AI agents connect to brokers, tools, data sources, and APIs inside an enterprise. It matters because the security risk is often in the path between components, not in any one component alone, and that path determines effective privilege.
• Shadow Agent: An AI agent deployed without formal registration, identity governance, or security oversight — the agentic equivalent of shadow IT. Shadow agents are more dangerous than typical shadow NHIs because they actively take actions using their credentials.
• 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.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.

What's in the full article

Salt's full article covers the operational detail this post intentionally leaves for the source:

• How Salt frames agentic security graph discovery across LLMs, MCP servers, and APIs in practice.
• The specific visibility gaps the vendor says appear in shadow agents, MCP sprawl, and API exposure.
• How the vendor positions graph-based context for prioritising blast radius and anomaly detection.
• The assessment-oriented detail behind its agentic security approach and workflow.

👉 Salt's full article covers shadow agents, MCP sprawl, and graph-based blast-radius analysis.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners translate identity controls into operating models for modern enterprise access.