AI agents are rewriting SaaS security and exposure models

At a glance

What this is: The article argues that AI agents are changing SaaS security by creating a faster, broader, and less visible access layer than traditional users.

Why it matters: IAM, PAM, and SaaS security teams need to treat AI agents as governed identities because over-permissioned automation can turn a single compromise into ecosystem-wide data exposure.

By the numbers:

• Agents move 16x more data than human users, and one Glean agent downloaded over 16 million files while every other user and app combined accounted for just one million.
• AI agents are routinely over-permissioned by 10x, which leaves them with far more access than their function requires.
• The Salesloft incident impacted more than 700 organizations and contributed to 1.5 billion records stolen across downstream systems.

👉 Read Obsidian Security's analysis of how AI agents are rewriting SaaS security

Context

AI agents are becoming a security problem because they combine automation, broad SaaS connectivity, and persistent access to sensitive business data. Traditional controls were built around human users, individual sessions, and clearer accountability boundaries, but agents can chain actions across systems faster than review and approval workflows can keep up.

In identity terms, that means AI agents behave like non-human identities that need lifecycle oversight, privilege scoping, and continuous audit trails. The article's central point is that SaaS security breaks down when agent access is treated like ordinary user access, which is typical in early deployments and increasingly unsafe at scale.

Key questions

Q: How should security teams govern AI features embedded in SaaS applications?

A: Treat embedded AI as a machine identity problem with data access implications. Inventory the feature, map the connected permissions, define what data it may use, and monitor retention and sharing paths. If the AI feature can read corporate content, it needs explicit approval, logging, and periodic review like any other privileged integration.

Q: Why do AI agents increase the blast radius of SaaS compromises?

A: AI agents increase blast radius because they often inherit broad delegated permissions and can execute many actions across connected applications in a short time. If one agent or integration is compromised, the attacker can reuse that trust to reach multiple systems, move data quickly, and escalate from one app to an ecosystem.

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: Who is accountable when an AI agent performs an unauthorized action in a SaaS product?

A: Accountability stays with the organisation that granted the agent authority, but investigators need evidence to prove what the actor was allowed to do and what it actually did. That is why audit logs, scope controls, and session-level attribution matter across human, service, and agent activity.

Technical breakdown

Why SaaS integrations amplify AI agent risk

AI agents derive much of their power from the SaaS integrations they can invoke. Each connection widens the trust boundary, because the agent can move from one application to another using delegated permissions, tokens, or shared workflows. When those integrations are broad by default, a compromise is not confined to one app. It can cascade into connected systems, data stores, and collaboration tools. This is why SaaS becomes the natural attack surface for agentic automation: it concentrates business context, credentials, and high-value records in one place.

Practical implication: map every agent to the SaaS integrations and delegated scopes it can reach before it is allowed into production.

How over-permissioned agents create blast radius

Over-permissioning is the core technical failure described in the article. If an agent receives access to entire datasets or multiple folders when it only needs a narrow workflow, every token compromise becomes a high-impact event. That is a classic least-privilege failure, but it is more dangerous for agents because they can execute many more actions per minute than a human. The result is not just broader exposure. It is faster exposure, with less chance to notice misuse before data moves or changes state.

Practical implication: apply task-scoped entitlements and shorten credential scope so a single agent cannot traverse unnecessary records or applications.

Why auditability must follow each agent action

The article stresses continuous observability because agent access without traceability is operationally opaque. For security and compliance teams, the important question is not simply which agent exists, but what data it touched, which actions it took, and which entitlements enabled those actions. That requires correlated audit trails that bind identity, access, and execution together. Without that linkage, investigations become guesswork and governance reviews cannot prove whether an agent stayed inside its intended boundary.

Practical implication: require per-agent logging that ties each execution to a specific entitlement, dataset, and downstream action.

Threat narrative

Attacker objective: The attacker wants to turn one trusted SaaS integration or agent into rapid, ecosystem-wide data access and exfiltration.

1. Entry occurs when attackers exploit exposed URLs, malicious OAuth connected apps, or compromised SaaS integrations to reach agent-connected environments.
2. Escalation happens when the agent already holds broad delegated permissions, allowing the attacker to move from one SaaS application to many downstream systems.
3. Impact follows when the compromised agent or integration is used to extract large volumes of data across SaaS ecosystems and collaboration platforms.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

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 are becoming non-human identities with human-scale business impact. Once agents can execute workflows, touch data, and chain SaaS actions, they stop being a simple automation feature and become governed identities. That creates a direct identity security problem, not just an application feature problem. IAM and PAM teams should treat every agent as a lifecycle-managed subject with scoped access and revocation paths.

Over-permissioned SaaS access has become a blast-radius multiplier for agentic systems. The article shows that the security issue is not only compromise, but the amount of authority an agent inherits at the moment of compromise. That is a governance failure around standing access, delegated tokens, and default scopes. The field needs to stop measuring agent adoption and start measuring the size of the access window each agent creates.

SaaS security now depends on NHI governance, not just user governance. AI agents operate across applications in ways that mirror service accounts, API keys, and workload identities, but with higher execution speed and broader context. That makes agent identity a first-class control plane issue for identity programs. Organisations that do not extend NHI controls into SaaS workflows will keep confusing convenience with control.

Continuous observability is the named concept that matters here because agent activity is only secure when identity, entitlement, and action stay linked. The article's strongest lesson is that access review alone is too slow for systems that can act in seconds. Security teams need policies that tie every agent to traceable execution history and clear business ownership. Without that linkage, AI agent governance remains mostly theoretical.

The market signal is that SaaS vendors and buyers are converging on the same problem from different sides. Vendors are beginning to package agent visibility and access cleanup, while buyers are being forced to ask whether current IAM, CASB, and SaaS security tools can actually govern autonomous behavior. The important move is not choosing another point control, but deciding which identity layer owns agent accountability.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• For a deeper governance angle, see OWASP NHI Top 10 for the control patterns most relevant to agentic risk.

What this signals

Continuous agent observability will become a baseline requirement for SaaS security programmes. If organisations cannot tie an AI agent's identity to the data it touched and the permissions it used, they will struggle to investigate misuse or demonstrate control. That is why the practical challenge is not simply adopting agents, but proving that they operate inside a governed boundary.

Agent identity is now part of the NHI problem set. Once a system can act, chain workflows, and touch sensitive data on its own, it needs the same kind of governance discipline applied to service accounts and workload identities. For identity leaders, that means extending lifecycle management, access review, and entitlement cleanup into SaaS automation.

The governance gap is moving from detection to entitlement design. The key issue is no longer whether agents exist, but whether they were ever granted more access than their workflow requires. Security teams should expect tighter scrutiny of default scopes, token lifetimes, and delegated app permissions across their SaaS estate.

For practitioners

• Inventory every AI agent and its delegated scopes Build a live register of agents, linked SaaS apps, token types, and effective permissions so you can see which identities can move across systems.
• Shrink SaaS permissions to task-level access Replace broad read-all or tenant-wide access with narrowly scoped entitlements that match the agent's specific workflow and revoke anything not used in production.
• Bind agent actions to immutable audit trails Log each execution with the agent identity, the entitlement used, the dataset touched, and the downstream action so investigations can reconstruct the chain quickly.
• Treat exposed agent URLs as active security incidents Assume that an unprotected agent endpoint can be discovered and abused without brute force, then force authentication, ownership, and monitoring before deployment.

Key takeaways

• AI agents create a new SaaS security exposure because they can act faster, broader, and with less supervision than human users.
• The evidence points to scale, not edge cases: agents can move far more data than humans and are frequently granted far more access than they need.
• The control priority is governance of agent identity, permissions, and auditability, not simply more monitoring after the fact.

Key terms

• AI Agent Identity: The digital identity used by an autonomous AI agent to authenticate to external systems, APIs, and services. Managing AI agent identities is an emerging and rapidly evolving area of NHI security.
• 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.
• 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.
• 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.

What's in the full article

Obsidian Security's full blog post covers the operational detail this post intentionally leaves for the source:

• Agent visibility workflows for inventorying AI agents, their SaaS connections, and their effective privileges.
• Continuous observability examples that tie each agent action to the specific entitlement and dataset involved.
• Misuse detection patterns for trust-chain abuse, privilege escalation, and risky downstream access.
• Practical mitigation detail for cleaning up excessive access across connected SaaS environments.

👉 The full Obsidian Security post covers the agent inventory, access cleanup, and misuse detection detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle controls. It is designed for practitioners who need to extend identity discipline into automation, SaaS, and agentic environments.