TL;DR: SaaS misconfiguration detection now has to follow identities, OAuth grants, service accounts, and AI agents as much as application settings, because modern SaaS risk is increasingly driven by trust relationships and changing access paths, according to Grip Security. That shift makes continuous visibility and remediation a governance problem, not a periodic configuration review.
At a glance
What this is: Grip Security says SaaS misconfiguration detection has moved beyond settings to the identities, grants, service accounts, and AI agents that determine real access.
Why it matters: This matters because IAM, NHI, and SaaS security teams need continuous visibility into who or what can reach data, not just whether an app looks correctly configured.
By the numbers:
- 54% of enterprise applications now contain AI functionality, according to Grip Security.
- The average identity is exposed to 33.5 AI-enabled applications, according to Grip Security.
- The average Grip customer has 1,017 AI-enabled applications in its environment, according to Grip Security.
- Organizations now have approximately one AI agent for every 17 identities, according to Grip Security.
Context
SaaS misconfiguration detection is a control problem, not just a configuration problem. Once identities, OAuth grants, service accounts, integrations, and AI agents can change access without a traditional admin workflow, point-in-time settings checks stop describing the real exposure.
The identity angle is material because SaaS access is increasingly mediated by delegated trust, not only by local application settings. For IAM and NHI teams, that means the security boundary now includes who authorised the access, what scope was granted, and whether the relationship is still justified.
Key questions
Q: What breaks when SaaS security reviews focus only on application settings?
A: When reviews stop at settings, teams miss the identities and trust relationships that actually move data. An app can pass a configuration check while an OAuth grant, service account, or AI agent still has excessive access. The result is hidden exposure that persists until someone evaluates effective permissions, ownership, and whether the access is still required.
Q: Why do OAuth apps and service accounts create more risk than their user-facing setup suggests?
A: They create risk because the visible installation is usually less important than the permissions behind it. A single OAuth grant or service account can silently inherit access to mail, source code, tickets, or cloud resources. If those permissions are broad or poorly tracked, an attacker who steals the token gets immediate operational reach.
Q: What are the signs that identity-driven SaaS misconfiguration is getting out of control?
A: Look for many apps with overlapping scopes, unclear ownership for integrations, dormant accounts that still authorize access, and AI-enabled tools connected to sensitive data without a current business justification. Those signals indicate the environment is accumulating trust paths faster than security teams can review or revoke them.
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.
Technical breakdown
Why identity-driven SaaS misconfigurations are different
Traditional SaaS misconfiguration checks focus on whether a setting is insecure, such as public sharing or disabled MFA. Identity-driven misconfigurations are different because the application may be configured exactly as intended while the effective access path is still excessive. OAuth grants, service accounts, and AI agents can inherit scopes that persist beyond the original business need. That means the control problem shifts from static settings to dynamic authorisation relationships, where the risk sits in who can act, what they can reach, and how long that trust remains valid.
Practical implication: review access relationships, not only application settings, when assessing SaaS posture.
How OAuth grants and service accounts expand the attack surface
OAuth authorisations and service accounts are not just connectivity mechanisms. They are trust brokers that can carry broad, durable access into applications and data stores, often outside central provisioning. If a user authorises a new app or an integration is created with excessive scope, the resulting path can remain active long after the original action is forgotten. In NHI terms, this is a lifecycle problem: the identity exists, the permissions persist, and the organisation may lack clear ownership or offboarding discipline. The exposure grows when these identities are unmanaged or when their purpose cannot be tied back to a current business requirement.
Practical implication: tie OAuth and service-account governance to ownership, scope review, and revocation workflows.
Why AI-enabled applications and agents raise governance pressure
AI-enabled applications multiply the number of trust relationships that security teams must govern. They may embed AI functionality inside existing SaaS products, or introduce agents that act on behalf of users and inherit their permissions. The result is a larger and less visible permission mesh, especially when agents can invoke APIs, access regulated data, or chain together multiple apps. This is where SaaS governance meets agentic AI security: the risk is not only what the application does, but what the agent or embedded capability can do with delegated access. Static review models struggle because the environment changes faster than the audit cycle.
Practical implication: extend SaaS governance to AI features and agents before they become untracked privilege carriers.
Threat narrative
Attacker objective: The objective is to turn ordinary SaaS trust relationships into durable access paths that expose data or administrative capability without triggering obvious configuration alarms.
- Entry occurs when a user, integration, or AI-enabled application authorizes access with broader permissions than the business needs.
- Credential or token abuse follows when the granted OAuth scope, service-account credential, or inherited identity trust is reused outside its intended context.
- Escalation happens when that access reaches sensitive SaaS data, additional applications, or administrative functions that were never meant to sit behind the original trust relationship.
- Impact is unauthorized exposure or manipulation of SaaS data and related systems through a misconfiguration that looked acceptable at the settings layer.
Breaches seen in the wild
- EmeraldWhale Git config credential theft: Tokens in exposed .git/config files let EMERALDWHALE clone private repositories and steal more than 15,000 cloud credentials.
- Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
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
Identity-driven misconfiguration is now the dominant SaaS control problem: the risk is increasingly the trust relationship, not the setting. A SaaS app can look compliant at the configuration layer while still exposing sensitive data through overbroad OAuth grants, service accounts, or AI-mediated access. Practitioners should treat authorisation context as part of the misconfiguration surface, not as a separate IAM concern.
AI has turned SaaS posture into a moving target: once AI-enabled applications and agents sit inside the SaaS estate, the number of effective identities rises faster than manual review can keep up. Grip Security's figures on AI penetration and agent density point to a governance model that must see both human and non-human access paths. The practitioner conclusion is that continuous visibility is now a baseline control, not an enhancement.
NHI governance must extend into SaaS posture management: service accounts, tokens, and delegated app access are now part of the same exposure chain. If teams only govern human identities, they will miss the machine and delegated identities that preserve access after the original workflow is forgotten. The right operating model unifies ownership, scope, and offboarding across human and non-human access paths.
Identity sprawl in SaaS is the new misconfiguration boundary: the practical problem is not just too many apps, but too many trust relationships with unclear lifecycle control. That includes OAuth authorisations, embedded AI capabilities, and unmanaged integrations that can change access without a ticket or review. Security teams should treat identity sprawl as a posture issue with direct governance consequences.
From our research library:
- 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data, according to the Ultimate Guide to NHIs.
- 1 in 3 organisations encountered suspicious AI agent activity in 2025, and 99.4% experienced a SaaS or AI ecosystem incident.
- Read next: SaaS-to-SaaS and OAuth App Governance Guide
What this signals
AI sprawl changes the control boundary: security teams no longer manage only applications, but also the identities and delegated permissions that AI-enabled SaaS features consume. That makes access graph visibility a prerequisite for any workable posture programme.
The governance question is now lifecycle, not inventory alone. If an OAuth grant, service account, or agent can retain access after the original need has passed, then revocation, ownership, and recertification need to operate continuously rather than on a quarterly cadence.
For practitioners
- Build a unified SaaS and identity inventory Include sanctioned apps, shadow apps, OAuth grants, service accounts, AI-enabled applications, and AI agents in one living inventory so you can see the full access graph.
- Review effective access, not just settings For each high-risk app, document which identity authorised it, what scopes it holds, what data it can reach, and whether the access still matches the business need.
- Revoke stale delegated access on a schedule Create a revocation workflow for dormant OAuth grants, unused integrations, and service accounts whose owners cannot justify the current permissions.
- Extend governance to AI-enabled SaaS features Require security review for embedded AI functions and external agents before they inherit user permissions or connect to regulated data stores.
Key takeaways
- SaaS misconfiguration detection now has to account for identity relationships, delegated access, and AI-mediated permissions, not just local application settings.
- The operational evidence points to rapid expansion in AI-enabled SaaS exposure, which makes point-in-time review increasingly incomplete.
- Teams that do not govern OAuth grants, service accounts, and AI agents together will miss the access paths that matter most.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | OAuth grants and service accounts expand exposure in ways that behave like leaked or overexposed non-human access. |
| NHI-05 — Overprivileged NHI | The article's core problem is excessive access held by service accounts, integrations, and AI agents. | |
| NHI-09 — NHI Reuse | Repeated use of the same delegated trust paths across apps and agents creates hidden cumulative risk. | |
| Recommendation — Scan SaaS integrations for exposed or overbroad non-human access and revoke any grant that exceeds current need. Map non-human identities to least-privilege scopes and remove permissions that are not tied to an active workload. Track reused credentials and delegated access paths across SaaS apps so the same trust path is not inherited everywhere. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Misconfigured SaaS access paths can enable credential reuse and movement across connected applications. |
| Recommendation — Map risky SaaS trust paths to TA0006 and TA0008 to prioritise detection around credential exposure and movement. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about governing who or what can access SaaS resources. |
| Recommendation — Apply PR.AA-05 to continuously review entitlements across users, integrations, and AI agents. | ||
Key terms
- Identity-Driven Misconfiguration: An identity-driven misconfiguration is a condition where access is technically permitted but operationally excessive, stale, or poorly governed. In SaaS environments, the problem often comes from OAuth grants, service accounts, integrations, or AI agents that keep privileges after the original business need has changed.
- 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 posture management: SaaS posture management is the continuous discovery, classification, and policy enforcement of cloud application risk. For AI-enabled SaaS, it extends beyond configuration checks to include data retention, model training permissions, delegated access, and automated remediation when behaviour drifts from policy.
- 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.
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 connect delegated access, ownership, and lifecycle control to real-world identity risk.
Published by the NHIMG editorial team on August 15, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org