SaaS security defaults are becoming an identity governance problem

At a glance

What this is: This is an editorial argument that SaaS should move toward security by default, with a shared control baseline, better telemetry, and stronger accountability for OAuth-connected apps and AI agents.

Why it matters: For IAM and NHI practitioners, the core issue is that inconsistent SaaS controls turn identity and access governance into a vendor-by-vendor exception process that is hard to scale or audit.

By the numbers:

• Obsidian Security states that 90% of AI agents are over-permissioned in SaaS.
• Obsidian researchers found the blast radius of this supply chain attack was 10x greater than previous incidents.
• The SSAF control baseline defines 41 essential security controls across 6 domains.

👉 Read Obsidian Security's analysis of SaaS security defaults and OAuth risk

Context

SaaS security has become an identity governance problem because access is now mediated through dozens or hundreds of connected applications, OAuth integrations, and machine-driven workflows. When security settings differ by app and telemetry is incomplete, IAM teams lose the ability to enforce consistent least privilege, review entitlements, or investigate misuse at scale.

Obsidian Security frames the issue around shared standards and vendor accountability, but the underlying gap is broader: organisations are being asked to govern NHI-style access paths without a stable control baseline. That makes SaaS risk management depend on exceptions, manual review, and whatever visibility each vendor chooses to expose. This pattern is now typical, not edge case behaviour.

Key questions

Q: How should security teams govern SaaS OAuth integrations?

A: Treat each OAuth integration as a governed non-human identity with an owner, a business purpose, scoped permissions, and a review cycle. If an integration can read, write, or export data across systems, it needs the same scrutiny as a privileged service account. Teams should revoke broad or unused grants, especially where the app lacks strong telemetry.

Q: What is the difference between a SaaS feature and a security control?

A: A SaaS feature helps users do work, while a security control lets the customer verify, restrict, or audit that work. If an app cannot expose logs, configuration state, or permission boundaries, it may be functional but still ungovernable. Practitioners should not confuse product convenience with enforceable security.

Q: Why do SaaS applications create blind spots for IAM teams?

A: SaaS platforms often use vendor-specific permission models, limited logs, and inconsistent admin APIs, so IAM teams cannot apply one policy across the portfolio. That forces security operations into manual exception handling and weakens access review. The blind spot grows when AI agents and OAuth apps inherit delegated access across multiple systems.

Q: Should organisations require security telemetry before adopting SaaS tools?

A: Yes. Telemetry is what makes SaaS access governable after deployment, because without logs and exportable events the team cannot investigate abuse or validate least privilege. Organisations should require auditable logs, configuration visibility, and incident support as part of their minimum security standard for any sensitive application.

Technical breakdown

Why OAuth-connected SaaS apps create a privilege blind spot

OAuth integrations sit between users, applications, and automated workflows, but their permission model often bypasses the controls IAM teams expect from human authentication. Scope decisions are frequently broad, static, and difficult to compare across vendors, which means a single consented app can inherit more access than the business intended. When those integrations also power agentic workflows, the trust boundary becomes even harder to define because machines can act at scale without a human-in-the-loop at each step. The technical problem is not OAuth itself, but the mismatch between delegation and governance.

Practical implication: Map every OAuth grant to an owner, an expiry, and a business purpose.

How missing telemetry breaks security investigation and access review

Security telemetry is the evidence layer for identity governance. If SaaS logs are incomplete, delayed, or inconsistent, teams cannot reconstruct who accessed what, when, or through which connector. That creates problems for incident response, but it also weakens preventative controls like access review, anomaly detection, and policy tuning. For NHI and agentic AI use cases, the issue is sharper because automated actors can generate high-volume, cross-app activity that looks normal unless telemetry is rich enough to correlate identity, scope, and action across systems.

Practical implication: Require event logs and configuration APIs before allowing critical SaaS adoption.

What a shared SaaS security baseline changes architecturally

A shared control baseline gives practitioners a common language for evaluating whether a SaaS platform can support governance, not just functionality. In practice, that means checking for configuration visibility, auditability, permission scoping, and security-relevant APIs before the app enters production. Without those controls, each deployment becomes a custom security project. With them, teams can enforce repeatable policy across vendors, which is the only workable model when SaaS portfolios are large and AI agents can traverse them in seconds.

Practical implication: Use baseline controls as a procurement gate, not a post-deployment checklist.

Threat narrative

Attacker objective: The attacker wants to turn legitimate SaaS delegation into a scalable data exfiltration path with minimal detection.

1. Entry occurs through a compromised or over-broad OAuth integration that already trusts a downstream SaaS environment.
2. Escalation follows when the integration inherits access to mail, CRM, file, or workspace data beyond its operational need.
3. Impact occurs when attackers or rogue agents use the delegated path to exfiltrate data across multiple connected SaaS environments.

Breaches seen in the wild

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

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

NHI Mgmt Group analysis

Security by default in SaaS is now an identity control requirement, not a product preference. When applications expose different permissions models, logs, and APIs, customers cannot govern access consistently. That means every new SaaS deployment introduces another exception path into the identity fabric. The practical conclusion is straightforward: organisations should treat vendor-provided control depth as part of IAM architecture, not as a procurement afterthought.

OAuth integrations have become the most underestimated NHI pathway in SaaS. These connections often behave like non-human identities with delegated authority, yet they are reviewed with far less discipline than service accounts or privileged admins. The result is hidden standing access across CRM, collaboration, and data tools. Practitioners should classify OAuth apps as governed NHI assets, not just convenient integrations.

The control gap is structural because visibility and policy are fragmented by design. Each SaaS vendor exposes a different mix of audit logs, configuration options, and security APIs, so centralised governance is only as strong as the least transparent application. This creates identity blast radius, where one weakly governed tool can undermine the rest of the stack. Teams should measure blast radius per application and use that to prioritise control investment.

Shared standards will matter more as AI agents become native to SaaS workflows. Agentic systems can read, write, and export data across multiple platforms faster than human users can notice, which turns weak controls into compounding exposure. A standard such as the SaaS Security Capability Framework is valuable because it shifts the debate from vendor promise to verifiable capability. Practitioners should push for common control expectations before autonomous use cases scale.

Accountability must move upstream into vendor evaluation and not stay trapped in incident response. The article is right to argue for customer pressure, but the deeper lesson is that customers already own the blast radius if they adopt opaque SaaS at scale. That makes governance a continuous control problem, not a one-time assurance exercise. Security teams should refuse to separate SaaS selection from IAM and NHI policy enforcement.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• Only 13% of organisations feel extremely prepared for agentic AI, which shows that governance lag is already visible in operating teams.
• For the next step, review the 2026 Infrastructure Identity Survey for the broader access and readiness data behind these trends.

What this signals

Identity blast radius is becoming the right operating metric for SaaS programmes. When one application lacks logs or scoped permissions, it can undermine confidence in the rest of the portfolio. That is why SaaS governance now belongs in the same control conversation as NHI lifecycle management and privileged access review.

With 69% of security leaders saying identity management must fundamentally shift for agentic AI systems, the market is already signalling that static access models are inadequate. Teams should expect procurement, architecture, and security engineering to converge on shared expectations for auditability, delegation, and revocation.

The practical consequence is that SaaS vendors without usable security APIs will increasingly be treated as higher-risk exceptions. Security teams should prepare for more granular third-party assessment, stronger policy enforcement, and tighter integration between IAM, PAM, and application security workflows.

For practitioners

• Inventory every OAuth-connected app as an NHI asset Maintain a register of all OAuth grants, service-linked apps, and AI-driven integrations. Record scope, owner, business purpose, last review date, and revocation path so the security team can treat delegated access like any other privileged identity.
• Set minimum telemetry requirements before SaaS approval Require security-relevant logs, configuration visibility, and exportable audit data as preconditions for production use. If a vendor cannot provide configuration APIs and usable event records, the application should not host sensitive workflows.
• Use baseline control checks in procurement workflows Add a control baseline to the vendor assessment process, including permission scoping, admin auditability, and incident response support. This turns SaaS selection into a measurable governance decision instead of an informal feature comparison.
• Review AI agent permissions as if they were privileged service accounts Compare the access granted to AI agents with the access a human would receive for the same task, then reduce scope wherever the agent can function with less. Over-permissioned agents should be treated as identity risk, not productivity optimisation.

Key takeaways

• SaaS security has become an identity governance issue because delegated access, not just user login, defines the real blast radius.
• Over-permissioned AI agents and opaque OAuth paths are turning everyday integrations into non-human identity risks that standard controls struggle to contain.
• Organisations that cannot verify logs, scopes, and control depth across SaaS apps should treat those applications as exceptions until the governance gap is closed.

Key terms

• SaaS Security Capability Framework: A shared control baseline for SaaS platforms that describes the minimum security capabilities customers should be able to verify. In practice, it gives procurement, security, and audit teams a common way to compare logging, permissions, APIs, and incident support across vendors.
• OAuth Integration: A delegated access path that allows one application to act on behalf of a user or system in another application. In SaaS environments, these integrations can function like non-human identities and should be governed with the same scrutiny as privileged accounts.
• Identity Blast Radius: The range of systems and data that can be affected when one identity, integration, or credential is misused. In SaaS ecosystems, blast radius expands quickly because permissions, logs, and controls vary by vendor, making one weak app enough to create broad exposure.
• Security Telemetry: The logs, events, and configuration data that let defenders understand and prove what happened in a system. For SaaS governance, telemetry is what turns an application from a black box into something the security team can review, alert on, and investigate.

Deepen your knowledge

SaaS OAuth governance and AI agent access control are covered in the NHI Foundation Level course, the industry's only accredited NHI security programme. If your organisation is trying to govern delegated access across many SaaS tools, the course is a practical next step.

This post draws on content published by Obsidian Security: An Open Letter to the SaaS Industry on making security the default. Read the original.