Notifications
Clear all
Topic starter
02/08/2026 11:36 am
TL;DR: A lack of visibility into agents, MCP servers, and API connections leaves most organisations unable to govern agentic environments, and CSA research cited by Salt says 82% have found unknown AI agents while 65% have already seen an AI-agent-related incident. The control problem is now context, not just inventory: who can do what, through which path, and at what blast radius.
NHIMG editorial — based on content published by Salt: Agentic Security Graph visibility and why it matters for AI security
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.
Questions worth separating out
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.
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.
Q: What do teams get wrong about least privilege for AI agents?
A: They often stop at permission scope and ignore behavioural scope.
Practitioner guidance
- 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.
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.
👉 Read Salt's analysis of the Agentic Security Graph for AI security →
Agentic security graphs: what IAM and security teams are missing?
Explore further
02/08/2026 12:50 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Agentic security graph visibility is becoming the AI control gap
