SaaS security defaults are becoming an identity governance problem

At a glance

What this is: This is an open letter arguing that SaaS security has become a governance problem because inconsistent defaults, weak telemetry, and broad integrations create blind spots across connected applications and AI agents.

Why it matters: It matters because IAM and NHI teams now have to govern access paths that span SaaS platforms, OAuth tokens, and autonomous agents, not just human users and traditional admin controls.

By the numbers:

• Obsidian Security says 90% of AI agents are over-permissioned in SaaS.

Context

SaaS security has moved beyond isolated application hardening. When every vendor exposes different controls, logging depth, and configuration surfaces, security teams lose the ability to apply a consistent governance model across the application estate. The primary problem is not simply misconfiguration; it is the absence of a shared baseline for identity, access, and telemetry across interconnected SaaS services.

That gap becomes more consequential as OAuth integrations and AI agents expand the number of non-human access paths inside enterprise SaaS. These identities can read, write, and export data across multiple applications quickly, but they often sit outside the human-centric controls that security teams already know how to operate. The result is a governance problem for SaaS, machine identity, and emerging agentic workflows at the same time.

Key questions

Q: How do security teams govern SaaS applications with inconsistent security defaults?

A: Start by defining a minimum control baseline for logging, configuration visibility, access scope, and revocation across every critical application. Then require each vendor to prove it can meet that baseline before approval. Without that common floor, teams end up compensating manually for every product’s gaps, which does not scale and creates uneven risk.

Q: Why do OAuth tokens and SaaS integrations create outsized breach risk in connected environments?

A: OAuth tokens can grant persistent, authorized access that looks normal to security controls. Once a token is stolen or a malicious app is approved, attackers can move through connected SaaS apps and extract data through sanctioned channels. The risk grows because one compromise can extend across downstream systems without triggering the alarms teams expect from direct intrusion.

Q: What breaks when SaaS vendors do not expose enough telemetry?

A: Investigation slows because teams cannot quickly reconstruct what changed, which account acted, or which data moved. In practice, weak logs and limited admin APIs turn containment into guesswork and make revocation harder to validate. The result is delayed response, weaker forensics, and a higher chance that compromised access persists unnoticed.

Q: Should organisations treat AI agents and service accounts differently in SaaS governance?

A: They should govern them with the same relationship-aware discipline but not the same assumptions. Service accounts usually have more stable ownership and scope, while AI agents can chain access across workflows and integrations in ways that change during execution. That means both need inventory, lifecycle control, and blast-radius analysis, but agent behaviour deserves closer runtime scrutiny.

Technical breakdown

Why SaaS defaults create governance blind spots

SaaS platforms often expose different security settings, permission models, and event data, which makes cross-application governance inconsistent by design. A security team may think it is enforcing the same policy everywhere, but the underlying control surfaces vary enough that posture and detection become uneven. This is especially important in SaaS estates where identity is the control plane: access scope, logging depth, and API visibility determine how quickly a team can see and contain misuse.

Practical implication: define a minimum SaaS control baseline and verify that every critical application can actually support it.

How OAuth integrations expand the identity attack surface

OAuth is designed to let applications act on behalf of a user or service with delegated access, but the risk comes from scope, persistence, and downstream trust. If an integration is overbroad or compromised, it can inherit access to data and workflows far beyond the original use case. In SaaS environments, that means one token or connected app can become a pivot point into multiple systems, especially when visibility into grants and revocation is weak.

Practical implication: inventory OAuth grants by scope and business impact, then treat connected apps as governed identities.

Why agentic AI changes SaaS security assumptions

Agentic AI SaaS tools can execute actions across multiple applications without the slower decision loops that traditional governance models assume. That creates a different problem from ordinary automation: the identity is not just using access, it is selecting actions, moving data, and chaining privileges across systems at runtime. In that setting, over-permissioned access is not a theoretical concern. It becomes a direct path to data exposure, because the agent can amplify one bad grant across the whole SaaS estate.

Practical implication: tie agent permissions to explicit business tasks and verify that each action is constrained to the smallest workable scope.

Threat narrative

Attacker objective: The objective is to turn a trusted SaaS integration into a high-privilege path for large-scale data access and exfiltration.

1. Entry occurs through a compromised third-party SaaS integration, such as an OAuth-connected application that already has delegated access into core systems.
2. Credential or token abuse follows when the attacker reuses the integration’s OAuth privileges to operate as a trusted connected app.
3. Escalation happens as that access is used to pivot into downstream SaaS environments and extract data at scale.
4. Impact is broad data exposure across multiple SaaS tenants and delayed investigation because logs and telemetry are incomplete.

Breaches seen in the wild

• 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 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

SaaS security defaults are now an identity governance problem: When vendors expose inconsistent controls, the real gap is no longer just hardening. It is the inability to govern access, telemetry, and accountability across a distributed identity surface. Security teams can no longer assume that one control model fits every application, because the control plane itself is fragmented. The practical conclusion is that SaaS must be governed as part of IAM, not treated as a separate admin concern.

OAuth connectors are governed identities, not convenience features: The article shows that delegated integrations now sit on the same risk path as service accounts and tokens. Once scopes are broad and visibility is limited, the connector becomes a durable access path with little operational oversight. That is a classic NHI governance failure, because the organisation trusts the grant but cannot reliably observe or constrain its downstream use. Practitioners should treat each high-value integration as an access-bearing identity with a lifecycle, not a one-time setup event.

AI agents expose the SaaS trust deficit: The article’s agentic examples matter because they reveal how quickly delegated access can scale when an autonomous system can read, write, and export across applications. In NHIMG terms, this is an overprivileged execution problem amplified by runtime decision-making. The control assumption that access is static enough to monitor breaks down when the actor can chain actions across SaaS tools in seconds. The implication is that current governance cadences are too slow for agent-driven identity use.

Standards are becoming the enforcement layer the market lacks: The call for a shared SaaS security baseline reflects a broader market shift toward measurable capability rather than vendor-by-vendor promises. A common control baseline helps customers compare telemetry, logging, access models, and API exposure across platforms, which reduces audit duplication and improves procurement discipline. For identity leaders, the point is straightforward: you cannot govern SaaS sprawl at scale without a standard for what secure-by-default actually means.

From our research library:

• 1 in 3 organisations encountered suspicious AI agent activity in 2025, and 99.4% experienced a SaaS or AI ecosystem incident.

What this signals

Identity governance now has to cover the SaaS perimeter: The practical shift for security programmes is that SaaS approval, review, and monitoring can no longer sit outside IAM and NHI governance. If a platform cannot expose enough telemetry or admin control to support review, it is not just a tooling gap. It is a governance gap that will eventually surface in incident response or audit.

Shared standards will matter more than individual vendor promises: The market is moving toward measurable SaaS security capability because customers need a common way to compare controls across applications. That matters for procurement, recertification, and incident triage alike. Programmes that continue to assess SaaS ad hoc will struggle to scale oversight across hundreds of connected apps and integrations.

OAuth grants should be treated as living access relationships: A delegated SaaS connection is not a static configuration item. It is an access path with scope, business context, and lifecycle risk, which means revocation, ownership, and periodic review belong in the same process as ordinary access governance.

For practitioners

• Establish a SaaS security baseline Define the minimum logging, configuration visibility, access control, and API exposure requirements every critical SaaS app must meet before approval.
• Inventory OAuth-connected applications Map every delegated SaaS integration to its scopes, business owner, and data reach so you can see which grants behave like standing access.
• Classify AI agents as governed identities Treat autonomous SaaS agents as access-bearing actors and review whether each one can read, write, export, or chain actions across multiple environments.
• Require vendor telemetry before expansion Block new SaaS rollouts when logs, alerts, and admin APIs are too limited to support investigation, revocation, and posture monitoring.
• Align procurement to control evidence Use the same control evidence set for every SaaS assessment so security review, audit, and renewal decisions all reference a shared baseline.

Key takeaways

• SaaS security defaults are no longer just a configuration issue because inconsistent controls and limited telemetry create governance gaps across connected applications.
• OAuth integrations and AI agents extend the identity attack surface by turning delegated access into a route for broad downstream exposure.
• A shared control baseline is becoming necessary so security, audit, and procurement teams can assess SaaS platforms with the same evidence model.

Key terms

• SaaS Security Baseline: A SaaS security baseline is the minimum set of controls an organisation requires before trusting a provider or integration. It usually includes MFA, SSO, logging, role separation, and revocation processes, all treated as conditions of access rather than optional hardening.
• OAuth Delegation: OAuth delegation is the act of granting an application access to systems or data on behalf of a user or organisation. It is common in modern integrations, but it can create broad downstream authority if scopes are too wide or the connected application is compromised.
• Agentic SaaS Identity: An agentic SaaS identity is an autonomous software actor that can read, write, and export data across applications at runtime. Unlike static automation, it can chain actions and expand its own operational reach, which makes privilege boundaries and review cycles much harder to enforce.
• Configuration Baseline: The approved reference state for a system, policy, or controlled asset. A baseline defines what the environment should look like after a legitimate change. Security teams use it to compare current state against intended state and to spot drift, tampering, or incomplete implementation.

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.