AI agents in SaaS are creating a new NHI trust gap

At a glance

What this is: This is a 2026 analysis of how rapidly deployed AI agents are creating persistent NHI trust relationships in SaaS environments.

Why it matters: It matters because IAM teams need visibility, scope control, and revocation discipline before temporary agent access turns into standing privilege.

👉 Read Valence Security's analysis of AI agents and SaaS trust relationships

Context

AI agents are now being paired with SaaS applications through non-human identities, OAuth grants, API tokens, service accounts, and MCP sessions. That combination turns every integration into an access decision, and the risk grows when teams approve it during experimentation but never revisit the resulting permissions.

For IAM and NHI practitioners, the real governance gap is not whether an agent can act. It is whether security can still explain who the agent is, what it can reach, and why its access remains valid after the original use case changes. This is a typical enterprise pattern, not an edge case.

Key questions

Q: How should security teams govern AI agents that use SaaS integrations?

A: Treat each agent as a non-human identity with a lifecycle, not as a feature toggle. Require inventory, scoped consent, periodic access review, and revocation paths for every OAuth grant, API token, service account, and MCP session. Governance should cover both the first application and the downstream systems the agent can reach.

Q: When does AI agent access become standing privilege?

A: It becomes standing privilege when temporary permissions are never revisited after the pilot phase ends. If scopes, tokens, or shared credentials remain active because the agent is delivering value, the organisation has converted an experiment into permanent trust without re-approval. That is a governance failure, not a technical accident.

Q: What is the difference between human access review and AI agent access review?

A: Human access review focuses on stable job roles and periodic entitlement checks. AI agent access review must also account for runtime behaviour, changing integrations, token lifetimes, and delegated actions across SaaS systems. Agents can change what they touch faster than a standard access review cycle expects.

Q: Why do AI agents create more risk in SaaS than traditional automation?

A: Traditional automation is usually narrow, scripted, and easier to bound. AI agents can decide, chain tools, and keep acting across multiple systems using delegated access that may outlive the original task. That makes the trust relationship more fluid and the blast radius harder to predict.

Technical breakdown

How AI agents inherit SaaS identity and access

AI agents usually do not authenticate like human users. They inherit access through OAuth consent, API tokens, service accounts, and SaaS-to-SaaS integrations, which means the agent is effectively operating as a non-human identity with delegated authority. When MCP servers are added, the agent can also connect tool use to external systems and data sources. The core security issue is that initial consent often captures only the intended workflow, not the full downstream path of data movement and action. That makes the access graph dynamic, but the review process static.

Practical implication: Map every agent to the identity mechanism it uses, then review the downstream permissions rather than the original approval ticket.

Why temporary agent access hardens into standing privilege

The article describes a common failure mode in SaaS environments: access granted for a pilot or short trial remains in place after the agent becomes operational. Over time, overbroad OAuth scopes, long-lived tokens, and shared service accounts accumulate around the agent, even if nobody intended persistent access. This is a lifecycle problem as much as an authorisation problem. If access review, rotation, and offboarding are not built into the agent lifecycle, temporary trust turns into durable privilege. The blast radius then grows with every added integration.

Practical implication: Treat every agent integration as a lifecycle with expiry, not a one-time approval.

What makes SaaS-to-SaaS trust paths difficult to govern

SaaS-to-SaaS access creates indirect trust paths that are easy to overlook. An agent may not only reach one application, it may broker data and actions across several platforms through chained integrations. That means the identity boundary is no longer the individual app, but the entire trust path created by the agent, the token, and the connected services. Traditional IAM controls often focus on the first hop, while the actual risk sits in the second and third hops where visibility drops and permissions compound.

Practical implication: Review connected application chains as a single access path, not as isolated app permissions.

Threat narrative

Attacker objective: The objective is to turn an accepted AI agent into a durable privileged path that can move data and act across SaaS systems without close oversight.

1. Entry occurs when teams approve an AI agent through OAuth, API keys, service accounts, or MCP access during a rapid experiment.
2. Escalation happens when the agent keeps inherited scopes, long-lived tokens, or shared credentials after the original trial should have ended.
3. Impact follows when the agent continues to create records, move data, trigger workflows, or alter configurations with broader access than intended.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Temporary AI agent access is becoming a standing privilege problem. The article captures a pattern that IAM teams already know from service accounts and API keys, but the agentic layer makes it faster and harder to unwind. When experimentation is rewarded and review is deferred, temporary access becomes part of the production control plane. Practitioners should treat agent access as revocable by design, not by exception.

Identity blast radius is now the better risk measure for agent deployments. The issue is not only whether an agent is overprivileged, but how far it can move once it is trusted. A single agent can sit at the centre of OAuth grants, tokens, SaaS automation, and MCP sessions, which makes connected systems part of the same risk domain. Teams should measure where that blast radius starts and where it can expand.

Continuous discovery is the missing control for agentic SaaS environments. The article’s core point is that security often learns about an agent after the business has already committed to it. That is a visibility problem, but also a governance failure because access cannot be reviewed if it is not continuously inventoried. The practical conclusion is straightforward: if teams cannot enumerate agents and their trust paths, they cannot govern them.

Policy-controlled remediation is more defensible than blanket denial. The article correctly avoids framing security as anti-AI. The better model is controlled correction, where scopes can be reduced, credentials rotated, and risky integrations disabled without stopping useful automation. That approach aligns with least privilege and reduces the chance that agent adoption forces a false choice between productivity and control.

MCP adds a new layer of trust coupling that IAM teams cannot ignore. When AI agents use MCP sessions to reach tools and data sources, the protocol becomes part of the access story, not just the transport layer. That means governance has to extend from identity issuance to tool authorization and runtime oversight. Teams should treat MCP-connected agents as governed workloads, not as enhanced chat interfaces.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which is why agent access tends to persist after the original use case changes.
• That lifecycle gap is why teams should pair agent discovery with the NHI Lifecycle Management Guide and treat agent credentials as continuously governed assets.

What this signals

Identity blast radius is now the practical unit of control for agentic SaaS programmes. Once an agent can authenticate, call tools, and move data across applications, the main question becomes how far a compromised or over-scoped agent can travel before controls intervene. Teams should build policy around scope, reach, and revocation speed, not around whether the agent was approved at launch.

With 98% of organisations planning to deploy more AI agents in the next 12 months, the governance burden will rise faster than manual review can keep up, according to SailPoint's AI Agents: The New Attack Surface report. That makes continuous discovery and runtime review the only scalable operating model for NHI and IAM teams.

The security programme should now assume that agentic access will expand unless constrained by lifecycle controls. That means pairing SaaS visibility with lifecycle management, scope reduction, and offboarding workflows that can be executed as soon as an experiment becomes production.

For practitioners

• Inventory every AI agent and integration path Build a live inventory of agents, OAuth grants, API tokens, shared accounts, and MCP sessions so review starts from actual exposure rather than assumed ownership.
• Set expiry on experimental access Require time-bound approval for pilot agents, then force renewal before an agent can keep access, especially where long-lived tokens or broad scopes are involved.
• Reduce scopes before agents reach production Reassess scopes, roles, and entitlements before turning a trial into an operational workflow, and remove any downstream permissions the agent does not need.
• Tie remediation to identity lifecycle controls Use rotation, revocation, and offboarding steps for agent credentials so abandoned experiments do not remain active in SaaS environments.

Key takeaways

• AI agents are turning SaaS integrations into persistent non-human identity relationships, which makes access review a lifecycle issue rather than a one-time approval.
• The main risk is not experimentation itself, but temporary trust that hardens into standing privilege through broad scopes, long-lived tokens, and reused credentials.
• Practitioners should respond with continuous discovery, expiring access, and controlled remediation so agent adoption does not outrun governance.

Key terms

• Non-Human Identity: A non-human identity is any machine- or software-based account that authenticates to systems and performs actions on behalf of a process, workload, or agent. In practice, it includes service accounts, API keys, tokens, certificates, and AI agents with execution authority.
• SaaS-to-SaaS Trust Path: A SaaS-to-SaaS trust path is the chain of delegated permissions that lets one application, integration, or agent reach another. The risk is cumulative because each hop can expand data access, action scope, and the eventual blast radius if the chain is compromised.
• Identity Blast Radius: Identity blast radius is the amount of damage an identity can cause if it is misused, overprivileged, or compromised. For AI agents and other NHIs, it is shaped by scopes, token lifetimes, connected systems, and whether the access can be revoked quickly enough.

Deepen your knowledge

AI agents, SaaS integrations, and NHI lifecycle controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is already dealing with agent sprawl and delegated SaaS access, it is a useful place to build the governance baseline.

This post draws on content published by Valence Security: Love is in the Air and So Are Your AI Agents. Read the original.