AI agentic security gaps are widening beyond platform boundaries

At a glance

What this is: This is Salt’s analysis of how enterprise AI security has expanded from model protection into a broader agentic attack surface spanning agents, prompts, pipelines, MCP servers, and cross-platform data paths.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern machine speed access paths that cross SaaS, cloud, and model boundaries, not just traditional application sessions.

👉 Read Salt's analysis of AI agentic security risk and cross-platform exposure

Context

Enterprise AI security is no longer limited to model abuse or prompt injection. The real governance gap is that agents can discover and traverse data and systems that were never mapped into the original access model, including legacy SharePoint, SaaS, and partner-connected resources. In practice, AI agentic security now intersects directly with IAM, NHI governance, and privilege scope.

The article’s core point is that defenders need visibility into the path an agent can take, not just the model it uses. That changes the control problem from static policy enforcement to continuous authorization across clouds, APIs, and data stores, which is why platform-independent oversight matters in agentic environments.

Key questions

Q: How should security teams govern access when AI agents and humans share the same apps?

A: Treat AI agents as separate identity subjects with their own approvals, scope limits, and monitoring. Human access policy assumes a person controls the session, but agentic access can chain actions across tools and timing. Governance should separate authentication from authorisation and require explicit policy for non-human actors before they are allowed to reach business apps.

Q: Why do autonomous agents make traditional access reviews less effective?

A: Access reviews assume permissions persist long enough to be observed, challenged, and recertified. Autonomous agents can obtain, use, and discard access within a single session, which means the risky action may occur before the next review cycle. That makes runtime enforcement more important than periodic certification alone.

Q: What breaks when AI security only covers one cloud or one model stack?

A: Teams lose the ability to see how access moves between platforms, which means they miss the real attack path. A partial view can still show alerts, but it cannot explain how a prompt, connector, or token in one environment opens data in another. That is a governance blind spot, not a monitoring gap.

Q: Who should be accountable for AI agent security incidents?

A: Accountability should sit with the team that owns the agent's business function and permission model, not with a single security tool owner. If the organisation cannot name who approved the agent's scope, who can revoke it, and who reviews runtime exceptions, the governance model is incomplete.

Technical breakdown

Why MCP servers expand the AI attack surface

Model Context Protocol, or MCP, connects AI agents to tools and data sources. That makes it a control plane for action, not just a transport layer. Once agents can invoke MCP servers, the security problem becomes authorization across chained tools, where one allowed call can expose data or enable the next action. The architectural risk is that access is distributed across services that were never designed to be evaluated as a single identity path.

Practical implication: map every MCP server to an explicit access owner and review its tool scope as if it were a privileged integration.

How agent discovery changes data exposure risk

AI agents do not need pre-existing knowledge of a target asset to surface it. They can discover forgotten systems, weakly protected shares, and stale repositories by following available connectors and prompts. That shifts exposure from known data stores to reachable data stores. In identity terms, the agent’s effective privileges define the blast radius, not just the account it authenticates with. This is why hidden access paths matter more than isolated authentication events.

Practical implication: inventory reachable data paths for each agent and remove any integration that grants broad discovery without a business justification.

Why platform-independent security becomes necessary

If security controls only see one cloud or one model stack, they cannot represent the full attack path. Agentic environments span SaaS, partner systems, multiple models, and downstream APIs, so control gaps emerge at the seams. A partial graph produces false confidence because the decisive risk is cross-domain chaining: one identity, tool, or token can unlock multiple environments. Security architecture has to track those relationships continuously, not retrospectively.

Practical implication: build a control view that correlates identities, tools, and data paths across platforms instead of relying on vendor-specific dashboards.

Threat narrative

Attacker objective: The attacker’s objective is to abuse trusted agentic connectivity to reach sensitive data and systems that sit beyond the original point of compromise.

1. Entry occurs when an attacker reaches an AI-facing integration, prompt path, or exposed credential that can be used by an agent or connected service.
2. Escalation follows as the attacker leverages trusted agent tooling, MCP connectivity, or over-broad permissions to move from one reachable system to the next.
3. Impact comes when the attacker uses that chained access to expose sensitive data, extend compromise across platforms, or trigger actions at machine speed.

NHI Mgmt Group analysis

AI agentic security is becoming an identity problem before it is a model problem. The article shows that attackers do not need to defeat the model first if they can abuse the agent’s reachable tools, connectors, and data paths. That means the governance question is who or what can act, where, and with which scope. For IAM and NHI teams, the practitioner conclusion is that agent identity must be controlled as a first-class security object.

Platform-specific controls create a false sense of coverage in agentic environments. A security view that stops at one cloud, one SaaS stack, or one model vendor cannot represent the full chain of trust. The article’s argument is that half a graph is not a graph. For the field, this sharpens a named concept: agentic blast-radius blindness, where teams can see the agent but not the downstream consequences of its access. Practitioners should treat cross-platform visibility as a governance requirement, not an optional enhancement.

The speed of compromise is now faster than human-paced review cycles. The collapse from hours to seconds means traditional detection and manual authorization cannot keep up once access is already granted. This does not make human review irrelevant, but it does move control upstream into policy design, scoped delegation, and continuous enforcement. For identity programmes, the conclusion is that static entitlements are the wrong unit of defence when machines can chain actions almost immediately.

Legacy data discovery is now part of AI governance. The article’s SharePoint example matters because agents surface assets that were previously invisible or ignored, turning dormant stores into active exposure. That extends the governance boundary beyond model risk into data reachability and stale system access. For practitioners, the field implication is clear: AI security programmes must coordinate with IAM, PAM, and data owners to remove ungoverned reach before agents inherit it.

Board-level AI security discussions need to focus on reachability, not only assurance. Executives do not need a technical tour of every model integration, but they do need to know whether the organisation can map what an agent can touch. The article frames this as an organisational capability gap, not a tooling preference. The practitioner takeaway is that governance should measure reachable privilege, not just logged activity.

What this signals

Agentic blast-radius blindness is the programme risk most teams are underestimating. When an AI workflow can traverse multiple clouds, SaaS platforms, and APIs, the issue is not just whether the agent is authenticated, but whether the organisation can explain every reachable dependency. The practical signal is to align agent inventory work with [The 2026 Infrastructure Identity Survey](https://nhimg.org/the-2026-infrastructure-identity-survey-state-of-ai-adoption) and the [OWASP NHI Top 10](https://nhimg.org/complete-guide-to-the-2026-owasp-top-10-risks-for-agentic-applications), because both highlight the same governance fault line: access grows faster than control.

The next maturity step is cross-domain correlation, not another isolated dashboard. Security teams need to join identity, connector, and data-path evidence so they can prove where an agent can operate and where it cannot. That should become a recurring control objective in IAM, PAM, and AI governance reviews.

For practitioners, the immediate planning question is whether current policies can distinguish approved agent reach from accidental reach. If the answer is no, the programme is already behind the operating model the article describes.

For practitioners

• Map agent reachable access paths Inventory every model, prompt, agent, MCP server, API, SaaS connector, and data store that an AI workflow can reach. Treat the resulting path map as an access-control artefact, not an architecture diagram, and review it against business purpose and ownership.
• Tighten agent permission boundaries Reduce broad, inherited access so each agent can only call the tools and data sources required for its task. Where possible, separate read and write actions, remove shared credentials, and force explicit approval for privileged or cross-domain operations.
• Govern MCP servers as privileged integrations Assign owners, logging requirements, and change control to every MCP server that brokers agent actions. Review tool scope, downstream data exposure, and failure modes before the connector is allowed into production, especially when it links to sensitive systems.
• Measure the blast radius of forgotten assets Search for legacy repositories, stale SharePoint sites, and dormant SaaS locations that agents can rediscover through existing connectors. Remove or isolate assets that appear outside current ownership or policy coverage before an AI workflow can surface them.

Key takeaways

• AI agent risk is now defined by reachable access paths, not just model behaviour or prompt safety.
• The control gap is widening because many organisations already grant AI systems broader access than equivalent human roles.
• Practitioners need a cross-platform identity and data graph before agentic automation scales further.

Key terms

• Agentic Security Graph: A unified view of the identities, tools, APIs, data sources, and permissions that an AI agent can traverse. It shows the operational path from an agent’s action to the systems and records it can reach, which is essential for governing cross-platform risk.
• 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.
• Agentic Blast Radius: The scope of potential damage if an AI agent's identity or credentials are compromised — amplified by the agent's autonomy, breadth of access, and ability to chain actions at machine speed. Typically much larger than the equivalent blast radius for a static service account.
• Platform-Independent Security: A control approach that tracks identities, permissions, and data paths across multiple vendors and environments instead of relying on one platform’s native visibility. For agentic systems, it is the difference between partial monitoring and a defensible view of exposure.

What's in the full article

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

• How Salt maps agent, MCP server, API, and data-path relationships into a single security graph
• The specific examples behind the SharePoint and multi-cloud exposure scenarios discussed in the interview
• The practical policy and posture details that show how platform-independent agentic security is operationalised
• The board-level framing Salt uses to explain why agentic risk now sits across security, platform, and data teams

👉 Salt's full post covers the agentic attack surface, platform-independent visibility, and board-level implications.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security practitioners translate identity principles into controls for agentic systems and broader enterprise access.