AI agent identity risk is outpacing SaaS governance controls

At a glance

What this is: This is an analysis of why AI agents embedded in SaaS are behaving like persistent non-human identities and exposing a governance gap that human-centric controls do not cover.

Why it matters: It matters because IAM, PAM, and SaaS security teams need to govern autonomous access, cross-application reach, and lifecycle ownership before agents become invisible standing privilege.

Context

AI agent identity risk is the governance problem created when autonomous software can act across SaaS systems with credentials or delegated access. Traditional SaaS controls still assume a person signs in, performs a bounded action, and later appears in a review cycle, which does not match how AI agents operate.

Valence Security argues that these agents now sit inside business workflows, expand across applications, and persist long enough to become part of the access estate rather than a transient automation layer. The operational question is not whether they are useful, but whether identity governance can discover, scope, and own them before they turn into standing privilege.

Key questions

Q: What breaks when AI agents are treated like standard human users?

A: You lose visibility into effective permissions, expected behaviour, and real blast radius. Human-centric controls can misclassify normal agent activity as compromise, or miss policy violations that happen entirely within legitimate access. The failure is not only technical, it is governance design that assumes a person is always behind the action.

Q: Why do AI agents increase access risk compared with traditional application integrations?

A: AI agents can make runtime decisions, chain tool calls, and reach multiple systems faster than a human operator. That expands the blast radius if identity controls are weak. Risk rises when credentials are reused, permissions are excessive, or session boundaries are unclear, because one compromised agent identity can touch data, APIs, and downstream workflows.

Q: What are the signs that an AI agent has gone out of scope?

A: Common signs include attempts to use unapproved tools, unexpected access to production data, spawning additional agents without a clear mandate, and repeated requests that expand beyond the original task. The key indicator is deviation from the declared lane, especially when the action is technically possible but operationally out of policy.

Q: Who should be accountable for governing access across SaaS apps, devices, and AI workflows?

A: Accountability should sit with security and identity governance leaders, working with application owners and platform teams. The control objective is to define policy, enforce device and app conditions, and maintain auditability across the full access path. Without clear ownership, gaps appear between authentication, authorisation, and lifecycle oversight.

Technical breakdown

Why AI agents behave more like identities than features

AI agents are not just AI features embedded in software. They hold credentials, use delegated access, and execute workflows continuously across SaaS systems without waiting for a human prompt. That makes them closer to service accounts than to traditional interactive users, but with one important difference: they make decisions and can expand their own operational reach over time. In identity terms, the subject is no longer a session or a login event. It is a persistent executor with action authority, data reach, and workflow influence that must be governed as an identity object, not as an application setting.

Practical implication: model every agent as an identity with scope, ownership, and lifecycle controls rather than as a feature toggle.

How cross-SaaS access expands the blast radius

AI agents often move between email, collaboration, CRM, ticketing, and file systems in a single workflow. That cross-SaaS reach creates a broader blast radius than a single application account because compromise, misconfiguration, or overpermissioning in one place can affect multiple systems at once. The technical issue is not simply that the agent can connect to more tools. It is that one identity can chain permissions across environments that were never designed to share one unified trust boundary. Once that chain exists, least privilege becomes harder to reason about because each new integration can add hidden downstream reach.

Practical implication: map each agent’s cross-application path before granting access, then reduce the reachable systems to the minimum set.

Why human-centric SaaS controls fail against autonomous behaviour

SSO, MFA, and periodic access reviews were built around human login patterns and explicit approval moments. AI agents break that model because they do not log in like users, they do not request access in predictable ways, and they do not pause for review before acting. The failure is architectural, not procedural. If a control depends on a person being present at the right time, it cannot govern an identity that acts continuously and asynchronously. This is why ownership, policy enforcement at issuance time, and ongoing discovery matter more than user-centric review cadences for agents.

Practical implication: shift governance from login-time human approval to continuous discovery, scope enforcement, and explicit ownership for each agent.

Threat narrative

Attacker objective: The objective is to exploit persistent non-human access inside SaaS workflows to move data, trigger actions, and expand influence across connected business systems.

1. Entry occurs when business users or operations teams create AI agents inside SaaS platforms and grant them delegated access, tokens, or credentials.
2. Credential exposure or abuse follows when those long-lived permissions remain active while the agent operates across multiple systems without security-owned review.
3. Escalation happens as the agent’s workflows expand, its access scope drifts, or a compromised agent inherits broader cross-SaaS reach than originally intended.
4. Impact is broad data movement, unauthorized workflow execution, and persistent standing privilege across connected SaaS environments.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• SalesBleed Salesforce Agentforce 2026: Three fixed Agentforce flaws let poisoned web leads make AI agents leak CRM data with zero clicks and send phishing under the agent's identity.

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

NHI Mgmt Group analysis

AI agents should be treated as persistent non-human identities, not as feature-level automations. The article’s central lesson is that these systems now hold credentials, act continuously, and influence multiple SaaS services at once. That combination changes the governance problem from application usage to identity lifecycle and access scope. Practitioners should stop asking whether the workflow is automated and start asking who owns the identity that executes it.

Cross-SaaS reach creates identity blast radius, not just convenience. One agent can touch email, CRM, collaboration, and storage in a single chain of action, so a single access decision can propagate across several trust boundaries. That means the real control question is not whether the agent is authorized somewhere. It is how far that authorization can travel before oversight disappears. Practitioners need to govern reachable systems, not just granted permissions.

Human-centric access review assumes a reviewable actor, and that assumption fails here. Access review processes were designed for access that persists long enough to be observed, certified, and revoked on a schedule. That assumption fails when the actor is an AI agent that can acquire, use, and expand access continuously outside a human-paced approval loop. The implication is that governance must move upstream to discovery and issuance, because review after the fact cannot see what was never tied to a stable human account.

Undefined ownership is the hidden control gap behind agent sprawl. The article shows that agents are often created by users or operations teams rather than security, which leaves no durable accountability when behaviour changes or access needs to be reduced. Without a named owner, the identity exists in the environment but not in the governance model. Practitioners should treat ownership as a mandatory control, not a documentation exercise.

Ephemeral-looking automation can still become standing privilege. Agents may appear temporary because their purpose is task-based, but the credentials and delegated rights often persist long after the original workflow was created. That creates a governance debt that looks like convenience at deployment time and entitlement accumulation later. Practitioners need to recognize that agent persistence is a lifecycle issue, not a tooling issue.

From our research library:

• 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
• 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Guide

What this signals

Agent governance will move from optional hygiene to core SaaS identity control. Security teams can no longer treat AI agents as incidental workflow helpers because their behaviour changes the access model itself. Discovery, ownership, and scope reduction need to sit inside the same control plane as SaaS access review and entitlement management.

Autonomous access creates governance debt as soon as it is deployed. If an agent can operate continuously without human approval, then every extra permission becomes a liability that persists until someone actively removes it. That changes the programme priority from periodic review to continuous inventory and lifecycle discipline.

Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey. The gap between intent and implementation is now large enough that teams should assume unmanaged agents already exist in their SaaS estate.

For practitioners

• Discover every AI agent in SaaS Inventory agents, automated workflows, and AI-driven integrations across collaboration, CRM, ticketing, and file systems. Include anything created outside security-owned processes, then assign a business owner before access is allowed to persist.
• Map delegated access and cross-SaaS scope Document which credentials, tokens, or delegated permissions each agent holds, which systems it can reach, and which data it can move. Reduce each agent to the minimum set of applications required for its business function.
• Replace user-centric review with agent governance Move from periodic human access reviews to continuous monitoring of agent behaviour, scope drift, and ownership changes. Review what the agent actually does across systems, not what its original prompt or workflow description claimed.
• Enforce lifecycle ownership for every agent Require explicit approval, documented business justification, and revocation responsibility for each AI agent. Offboarding must remove access, revoke tokens, and delete inactive integrations when the business need ends.

Key takeaways

• AI agents inside SaaS behave like persistent non-human identities, which means governance has to start with identity ownership rather than with application feature control.
• Their cross-SaaS reach can turn one permission decision into broad blast radius across email, CRM, collaboration, and storage systems.
• The practical control failure is not just missing review, but using review cycles for actors that can act and drift long before the next review window.

Key terms

• AI Agents: AI agents are autonomous software entities that act within organisational environments and make runtime decisions within assigned boundaries. They can hold identities, authenticate to systems, and exercise permissions, which makes them comparable to other non-human identities that require inventory, governance, and continuous activity monitoring.
• Cross-SaaS Risk: Cross-SaaS risk is exposure created when one identity can move actions or data across multiple software-as-a-service platforms. It increases the blast radius of a compromise because a single agent can influence email, collaboration, CRM, storage, and ticketing systems at once.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• Behavioural Drift: Behavioural drift is the gradual change in what an identity does compared with what it was originally approved to do. For AI agents, drift can come from prompt changes, model updates, expanded integrations, or altered workflows, which makes access review alone an incomplete control.

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 building or maturing an IAM programme, it is worth exploring.