TL;DR: Agentic ecosystems now expose gaps between who is allowed to connect and what those identities actually do, with Vorlon citing 99.4% of organizations experiencing at least one SaaS or AI security incident in 2025 and 86% of teams unable to see agent behaviour. The governance problem is not inventory alone, but identity, data-flow, and action visibility across agents, integrations, and SaaS.
At a glance
What this is: This is an analysis of why legacy identity and SaaS security controls miss the real attack surface created by AI agents, integrations, and non-human identities in motion.
Why it matters: It matters because IAM, NHI, and security operations teams need visibility into what identities do after authentication, not just whether they exist or are provisioned.
By the numbers:
- 99.4% of organizations experienced at least one SaaS or AI security incident in 2025.
- 86% of security teams still cannot see what their AI agents are actually doing.
- 93% faster incident response.
- Install-to-insights in 24 hours.
👉 Read Vorlon's analysis of the agentic ecosystem security gap
Context
Agentic ecosystem security is the problem of understanding how AI agents, SaaS applications, integrations, and non-human identities interact once access has already been granted. The primary keyword here is agentic ecosystem security, and the core gap is that traditional identity tools were built to manage accounts and permissions, not runtime behaviour across chained systems.
Most programmes can list identities, tokens, and connected apps, but that does not reveal which agent is touching customer data, which integration is moving records between services, or which third-party access is quietly expanding blast radius. For IAM and NHI teams, the challenge is to connect identity governance to data movement and operational action, not just entitlement inventory.
The article's starting position is typical of many modern environments: the control plane exists, but the execution plane is opaque. That makes it a practical example of why agentic and non-human identity governance are now inseparable from SaaS security and incident response.
Key questions
Q: How should security teams govern AI agents that connect to multiple SaaS tools?
A: Teams should govern them as runtime identities, not just app integrations. That means tracking which agent can authenticate, what data it can reach, which tools it can call, and how far the resulting action chain can propagate. Visibility has to cover identity, data flow, and downstream execution together, not separately.
Q: Why do trusted OAuth tokens increase blast radius in agentic environments?
A: Because a trusted token can become a high-speed access path across multiple services once an agent or integration begins chaining actions. The token may be valid, but the resulting behaviour can still exceed the original security assumption. Blast radius grows when one identity can move data or trigger actions in several systems.
Q: What do security teams get wrong about agent inventory?
A: They often treat inventory as proof of control. In practice, a list of agents or integrations does not show which identities are active, what data they touch, or which third parties they reach. Governance fails when visibility stops at existence and never reaches operational behaviour.
Q: Who is accountable when an AI agent or integration causes data exposure?
A: Accountability usually sits across the identity owner, the platform team, and the business owner of the workflow, but the control question is simpler: which team can revoke the access path first. Incident ownership should be tied to the identity chain that enabled the exposure, not only to the application where it was seen.
Background and context
Why inventory is not enough in agentic ecosystems
An inventory tells you what exists, but not how identities behave once they authenticate. In agentic environments, an AI agent may log into a SaaS app, pull records, invoke an MCP-connected tool, and hand off output to another service within one workflow. That creates a chain of identity action that crosses systems and trust boundaries. The security issue is not simply access, but the observable relationship between identity, data, and downstream execution. Practical monitoring has to follow the work, not just the account.
Practical implication: teams need runtime visibility into identity actions across SaaS, integrations, and AI agents, not only a static inventory.
How data-flow mapping changes NHI governance
Sensitive data-flow mapping ties identity events to the categories of information they touch, such as PII, PCI, or PHI. That matters because a token or integration may be legitimate at authentication time while still creating excessive exposure once it can move data across services. In NHI governance, this shifts the question from 'does this identity exist?' to 'what data can this identity reach, export, or transform, and where does that data go next?' That is where blast radius becomes measurable.
Practical implication: map sensitive data paths to identities and integrations so revocation and containment can target the actual exposure chain.
Context-based behavioural detection for agentic access
Behavioural detection in this context means alerting on what an identity is doing, not only that it authenticated successfully. For agentic systems, useful signals include privilege escalation, mass exports, anomalous tool calls, and unusual third-party access patterns. The context layer matters because the same action can be benign in one workflow and dangerous in another. Without data-layer context, security teams either over-alert or miss the action entirely. That makes behaviour-plus-context the operational model for agentic identity security.
Practical implication: tune detections around identity abuse, data exfiltration, and abnormal agent behaviour with context from the data layer.
NHI Mgmt Group analysis
Agentic ecosystem security is the new identity control plane problem: the security failure is not that organisations lack identities, it is that they cannot see how identities behave across SaaS, integrations, and AI agents once authentication succeeds. Legacy IAM was built to prove entitlement, while this problem is about runtime action and data movement. That gap forces identity teams to think in terms of relationships, not isolated accounts. Practitioners should treat agentic ecosystem observability as a governance requirement, not a monitoring enhancement.
Runtime identity abuse now matters more than static permission review: an authorized token can still produce unauthorized outcomes when an agent can combine services, call tools, and move data at machine speed. That does not mean least privilege is obsolete, but it does mean entitlement review alone is no longer enough to explain risk. The field needs controls that bind identity, action, and data context together. Practitioners should re-evaluate whether their current review model can actually detect misuse after access is granted.
Blast radius has become an identity metric, not just an incident metric: when a vendor account, integration, or AI agent is compromised, the real question is how far trusted access can propagate before containment. That is the governing premise behind data-flow mapping and context-based detection. The more identities, tools, and SaaS links that exist, the more quickly small failures become enterprise-scale exposure. Practitioners should measure exposure by reachable data and connected actions, not by the number of logged-in identities.
Agentic ecosystem security gives the category a precise name for a broader failure mode: visibility stops at the account boundary while risk accumulates in the operational chain between agent, SaaS, and third-party tool. That is why an inventory of agents is not a security strategy. The discipline now has to connect identity governance, SaaS security, and data-centric monitoring under one control narrative. Practitioners should align programme ownership across IAM, NHI, and SecOps instead of treating them as separate problems.
From our research:
- 99.4% of organizations experienced at least one SaaS or AI security incident in 2025, according to The 52 NHI breaches Report.
- 86% of security teams still cannot see what their AI agents are actually doing, according to Top 10 NHI Issues.
- For a wider breach lens, read 52 NHI Breaches Analysis for the recurring control failures behind identity-led incidents.
What this signals
Agentic ecosystem security: the practical signal for programmes is that identity governance now has to include runtime behaviour, not only provisioning and review. If your teams cannot connect an agent, its tool calls, and the data it can move, the control surface is still incomplete.
The right next step is to align IAM, NHI, and SecOps around one operational map of identities, integrations, and sensitive data flows. That gives incident responders a smaller containment set and gives governance teams a clearer view of which connections create real exposure.
A useful benchmark is whether you can answer, without manual reconstruction, which identities can reach regulated data and which systems they can write to. If you cannot, your environment has visibility debt, and the debt grows as agentic adoption expands.
For practitioners
- Map agent-to-SaaS execution paths Trace which AI agents, integrations, and service accounts can touch customer data, trigger tool calls, or write output into downstream systems. Build the map around actual workflows, not only directory entries or app registrations.
- Bind identity alerts to data categories Link detections to the data each identity can reach, including PII, PCI, and PHI. That lets analysts decide whether a token abuse event is a nuisance or a containment priority.
- Review third-party access by blast radius Reassess vendor and integration access by the number of systems and records each identity can affect, then predefine which tokens or connections to revoke first during an incident.
- Correlate agent behaviour with IAM logs Use identity logs, SaaS audit trails, and behavioural signals together so mass exports, privilege escalation, or unusual tool use are visible as one chain rather than separate alerts.
Key takeaways
- Agentic ecosystems expose a governance gap that traditional IAM inventories cannot close, because the real risk sits in runtime behaviour and data movement.
- Vorlon's figures point to a structural visibility problem, with nearly universal incident experience and widespread inability to observe agent actions.
- Practitioners should shift from counting identities to mapping executable trust chains, so containment and review can follow actual blast radius.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | AG-03 | Agent tool misuse and delegated access are central to this article. |
| OWASP Non-Human Identity Top 10 | NHI-04 | The article focuses on NHI visibility, privilege, and secret-backed access across systems. |
| NIST CSF 2.0 | PR.AC-4 | Access control and least privilege are directly implicated by delegated SaaS and agent access. |
Review entitlements against actual use paths and contain any identity with broader reach than needed.
Key terms
- Agentic Ecosystem Security: Agentic ecosystem security is the practice of governing AI agents, SaaS applications, integrations, and non-human identities as one connected operational surface. The focus is on what identities do after authentication, including data movement, tool calls, and downstream actions that can expand blast radius.
- Blast Radius: Blast radius is the amount of data, systems, and workflows that can be affected when an identity, token, or integration is abused. In agentic environments, it is measured by reachable services and writable data paths, not by the number of accounts alone.
- Context-Based Behavioural Detection: Context-based behavioural detection flags suspicious identity actions by combining behavioural signals with the data and systems involved. It is stronger than simple anomaly detection because the same action can be harmless in one workflow and dangerous in another depending on what the identity can reach.
- Non-Human Identity: A non-human identity is any machine or software identity used by services, workloads, bots, agents, APIs, or integrations. It can hold credentials, tokens, certificates, or keys, and it needs governance because it can authenticate and act without a person present.
What to expect at the briefing
Vorlon's full analysis covers the operational detail this post intentionally leaves for the source:
- The architecture behind DataMatrix™ and how the living model maps agent-to-SaaS and SaaS-to-SaaS relationships.
- The specific detection examples for identity abuse, data exposure, and malicious third-party access across agentic workflows.
- The workflow for two-click remediation through SIEM, SOAR, or ITSM integrations.
- The practical breakdown of how sensitive data flow mapping supports incident triage and blast radius analysis.
👉 The full Vorlon post covers agent discovery, data-flow mapping, and remediation workflows.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on 2026-09-15.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org