AI agents are rewriting SaaS security and exposure models

At a glance

What this is: This is an analysis of how AI agents are changing SaaS security by expanding access, accelerating data movement, and amplifying the blast radius of compromised integrations.

Why it matters: It matters because IAM and security teams now have to govern non-human identities inside SaaS with the same rigor they apply to privileged human access, but at much higher speed and scale.

By the numbers:

• Agents move 16x more data than human users.
• Agents are routinely over-permissioned by 10x.
• A single Glean agent downloaded over 16 million files while every other user and app combined accounted for just one million.
• The Salesloft compromise affected more than 700 organizations and counting.

Context

AI agents are software entities that can take actions inside business systems, not just generate text or recommendations. In SaaS environments, that means they inherit permissions, move data, and chain workflows across multiple applications, which turns access design into a governance problem rather than a simple automation question.

The security gap is that traditional SaaS controls were built around human users and static integrations, while agents operate continuously and at machine speed. Where access reviews, manual approval flows, and coarse SaaS defaults once seemed adequate, they now leave too much room for over-permissioned non-human identities to move laterally and expose data.

Obsidian Security's article treats this as a SaaS governance issue with a clear identity dimension: the real control gap is not the existence of agents, but the absence of lifecycle oversight, least privilege, and auditable entitlements for machine actors inside SaaS.

Key questions

Q: What breaks when AI agents are granted broad execution rights inside SaaS workflows?

A: The failure mode is that the agent can combine API calls, record changes and follow-on actions faster than any human can intervene. If the initial permission set is too broad, the workflow becomes a business-action engine rather than a controlled identity, and post-execution review arrives after the damage is already done.

Q: Why do over-permissioned AI platform identities increase breach risk?

A: Because they turn a single workload compromise into an identity pivot. When an AI service account can create jobs, access metadata, and reach data stores, attackers can move from execution to credential reuse and exfiltration without needing to break the AI model itself. That is a privilege design failure, not an AI model failure.

Q: When does AI agent access become a governance risk instead of an automation benefit?

A: AI agent access becomes a governance risk when the agent can act beyond a single task, reuse credentials, or reach systems that were never explicitly approved for that workflow. At that point, the issue is not productivity. It is whether the organisation can prove scope, ownership, and containment.

Q: How should teams govern SaaS access when bots and AI agents are also active?

A: Treat bots and AI agents as governed identities, not exceptions inside the SaaS stack. Assign ownership, lifecycle rules, and revocation paths for each non-human actor, then make sure review workflows can surface them separately from employee access. If the platform cannot distinguish those actors, governance is incomplete.

Technical breakdown

Why AI agents change SaaS trust boundaries

AI agents are not passive integrations. They authenticate into SaaS apps, inherit entitlements, and then execute workflows across systems that were never designed to assume non-human actors would act at high frequency and high volume. That breaks the old trust model where access could be understood by user role and reviewed on a human cadence. In practice, each agent becomes a persistent identity path into customer, finance, support, and collaboration data, often with broader reach than the task actually requires. The issue is not just automation, but delegated authority without sufficient containment.

Practical implication: Treat every agent as a governed identity with explicit scope, not as a convenience layer attached to SaaS automation.

How over-permissioning turns one agent into an ecosystem risk

The article's examples show the classic failure mode of excessive SaaS entitlements. Many platforms default to broad read access because it reduces friction, but that logic becomes dangerous when an agent inherits the same scope and then runs continuously. Over-permissioning converts a single compromise into mass exposure because the agent can traverse many objects, files, and applications without a human in the loop. In SaaS, the problem is amplified by integration chains, where one identity can reach multiple downstream services through trusted connections and tokens.

Practical implication: Constrain each agent to the minimum object, app, and workflow scope needed for the task it performs.

Why auditability and lifecycle control matter more than simple authentication

The article points out that some agents are created with no password requirements or are otherwise easy to reach if a URL is exposed. That is a governance failure, but the deeper issue is that authentication alone does not explain what the identity can do once inside. Continuous audit trails, correlated entitlements, and lifecycle oversight are needed because agents can be spun up, reused, and left active with no meaningful ownership. Without those controls, the security team sees activity only after sensitive data has already moved.

Practical implication: Bind agent creation, review, revocation, and logging to a formal lifecycle process rather than relying on initial login controls.

Threat narrative

Attacker objective: The attacker wants to turn one compromised non-human identity or integration into broad SaaS data access and rapid exfiltration across multiple connected services.

1. Entry occurs when an attacker reaches an exposed or weakly controlled AI agent, or abuses a compromised integration path into SaaS.
2. Credential or token abuse follows when the agent's OAuth grants, broad entitlements, or inherited permissions are used to access connected applications.
3. Escalation happens as the agent chains workflows across SaaS services, expanding from one account or integration into multiple downstream systems.
4. Impact is large-scale data exposure, because the agent can move customer, business, and operational records at machine speed across the ecosystem.

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.
• AI agent retail card theft campaign 2026: AI agents breached 27+ retailers for about $25 each, used cloud keys and a Secrets Manager dump, and stole 600,000+ payment cards.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI agents create a new non-human identity governance problem inside SaaS. The core issue is not whether an agent is useful, but whether its access can be bounded, reviewed, and revoked like any other identity. Traditional SaaS governance assumes users are visible, relatively slow, and accountable through familiar lifecycle processes. Agents break that assumption because they can operate continuously, across multiple apps, with delegated authority that outpaces human review.

Over-permissioning is now a blast-radius problem, not just an entitlement problem. When an agent inherits read-all or broad workflow access, one compromise can expose data across customer, support, finance, and collaboration systems. That is why the named concept here is agentic SaaS blast radius: the scope of downstream exposure created when a single machine actor is allowed to roam through trusted SaaS relationships. Practitioners should treat scope design as the first control, not an afterthought.

Continuous observability has become a governance requirement for SaaS-linked AI agents. Access reviews alone are too slow for identities that can be created, used, and abused inside a short automation cycle. The control question has shifted from who approved the agent to what the agent touched, whether that action was expected, and how quickly the privilege can be removed. For IAM and SaaS security teams, lifecycle telemetry is now as important as initial authorization.

SaaS supply chain risk now includes the identities that move through it. The article shows that compromised integrations can spread access into multiple downstream environments, which means third-party access governance must include non-human identities, not only vendors and employees. That widens the scope of entitlement management, offboarding, and monitoring across SaaS ecosystems. Practitioners should treat connected-app sprawl as an identity control issue, not just a platform risk.

From our research library:

• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
• Gartner predicts that more than 50% of successful cyberattacks against AI agents through 2029 will exploit access control weaknesses.
• Read next: AI Agent Authorisation Guide

What this signals

Agentic SaaS blast radius: the practical risk is not that agents exist, but that a single over-scoped identity can traverse SaaS workflows faster than review processes can react. That shifts governance from periodic certification to issuance-time restraint and continuous entitlement monitoring.

Security teams should expect SaaS control planes to absorb more non-human identities, more delegated access, and more third-party workflow chaining as agent adoption grows. That makes the combination of least privilege, correlated audit trails, and fast revocation the decisive control set for the next phase of SaaS governance.

The next programme gap is not visibility alone but decision quality: teams must distinguish useful automation from identities that are silently accumulating trust. When agents can act across customer and collaboration systems, scope discipline becomes a resilience control, not just an access-control preference.

For practitioners

• Inventory every AI agent and connected app Create a complete register of agents, the SaaS systems they touch, and the tokens or OAuth grants they use so no shadow agent sits outside governance.
• Re-scope agent permissions to task minimums Remove broad defaults such as read-all access and replace them with object-level and workflow-level entitlements tied to the specific task the agent performs.
• Tie agent actions to correlated audit trails Capture which entitlement enabled each action, which data objects were touched, and which downstream systems were reached so you can reconstruct agent behaviour quickly.
• Build revocation paths for exposed SaaS integrations Be able to disable a compromised integration, revoke its OAuth tokens, and cut off downstream access without waiting for a broader tenant cleanup.
• Review third-party access as an identity lifecycle Treat connected apps, bot accounts, and automation identities as offboarding candidates when ownership changes, usage drops, or trust conditions no longer hold.

Key takeaways

• AI agents are changing SaaS security because they behave like identities with delegated authority, not like passive integrations.
• The most dangerous failure mode is over-permissioning, which can turn one agent or token into ecosystem-wide data exposure.
• Security teams need lifecycle oversight, least privilege, and auditability for non-human access before agent adoption scales further.

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.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Overprivileged access: Overprivileged access is permission that exceeds the minimum needed for a task or role. In directory governance, it often persists because access is inherited, forgotten, or never reviewed after organisational change, which turns old entitlements into standing risk.
• SaaS Supply Chain: A SaaS supply chain is the network of third-party applications, integrations, and delegated permissions that connect cloud services to each other. It creates operational efficiency, but it also creates inherited trust paths where a compromise in one system can quickly affect many others.

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 practitioners translate identity controls into operational discipline for human, machine, and agentic access.