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.
Why settings-only reviews miss the real control plane
Application settings are only the visible layer. The actual security question is who or what can act inside the SaaS tenant, what that actor can reach, and whether that access is still legitimate. A configuration check can look clean while the effective control plane remains wide open through consented apps, delegated permissions, service identities, or long-lived tokens.
That gap matters because many SaaS incidents are not caused by a bad toggle in the UI. They happen when an integration inherits trust, a token outlives the review cycle, or a previously valid connection keeps working after ownership changes. The review passes the screen, but the operational exposure remains.
In practice, the review must move from stated configuration to SaaS-to-SaaS and OAuth App Governance, because OAuth grants, scopes, and revocation state are where hidden access usually lives. For SaaS assessments, the control question is not only “is the setting correct?” but “what effective authority exists right now?”
What hidden access paths usually survive a settings review?
The most common blind spots are the identities and trust relationships that sit behind the application. OAuth apps can hold broad scopes even when the base application is configured correctly. Service accounts can keep operating after the human owner changes roles. AI agents can inherit tool access that was never revisited after initial deployment. Each of these can preserve data access without any obvious change in the application’s visible settings.
Those paths matter because they often bypass the reviewers’ mental model. Teams examine password policy, feature flags, or sharing settings, then assume the tenant is safe. But the stronger signal is effective permission: who can read, write, export, or impersonate, and whether that authority is bounded by business need.
That is why cloud governance frameworks treat identity and access as a core assessment domain, not a sub-check. The CSA Cloud Controls Matrix explicitly includes IAM and data protection controls that help assess whether access is actually constrained, while NIST Privacy Framework reinforces the need to understand how data flows and who can affect it.
What should a complete SaaS review verify instead?
A complete review should test four things: effective permissions, ownership, revocation, and necessity. Effective permissions tell you what the app, token, or agent can actually do. Ownership tells you who is accountable for that access. Revocation tells you whether access can be removed quickly when risk changes. Necessity tells you whether the access still serves a current business purpose.
That shifts the review from static configuration to lifecycle control. A passed settings review is not enough if the SaaS tenant still contains dormant grants, unmanaged API access, or privileged third-party integrations. The useful evidence is not just the screenshot of a setting, but the inventory of active grants, the approval chain, and the last verification that each access path was still required.
For access control and review discipline, a useful external reference point is NIST Cybersecurity Framework 2.0, especially its governance and protection functions, and NIST AI Risk Management Framework where AI agents are part of the SaaS trust chain. If an agent can act on behalf of a user or system, its permissions must be reviewed as an access decision, not just an application feature.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while CSA Cloud Controls Matrix, NIST SP 800-53 Rev 5 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | SaaS reviews hinge on who can access data and integrations. |
| Recommendation — Validate identities, entitlements, and delegated access before accepting the SaaS control posture. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Hidden SaaS access often persists through unmanaged accounts and grants. |
| IA-5 — Authenticator Management | Long-lived tokens and secrets often outlast settings-based reviews. | |
| Recommendation — Review and revoke inactive or excessive SaaS accounts and grants on a defined cadence. Track, rotate, and revoke SaaS authenticators and tokens with ownership and expiry. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Overbroad app or agent actions can bypass visible configuration controls. |
| Recommendation — Test whether each integration can perform only the functions it is meant to perform. | ||
| NIST SP 800-63 | Digital Identity Guidelines — Digital Identity Guidelines | Delegated and federated SaaS access depends on trustworthy identity and session assurance. |
| Recommendation — Use assurance and reauthentication requirements for high-impact SaaS access paths. | ||
Practitioner Guidance
What to prioritise: Start with the grants that can move data, not the settings that merely change appearance. High-scope OAuth consent, service identities with broad mailbox or file access, and agent/tool permissions deserve the first pass because they create the largest hidden blast radius.
What to verify: For every non-human or delegated access path, confirm the owner, the scope, the last use date, and the revocation path. If any of those are unknown, treat the control as unproven even if the application configuration looks compliant.
Common mistake: Treating a clean admin console as evidence of low risk. In SaaS, the dangerous condition is often “configuration approved, access still alive.”
Practitioner takeaway: The review is only complete when you can explain not just how the SaaS is configured, but who can still act through it and why that access remains justified.
Related resources from NHI Mgmt Group
- How should security teams run access reviews for non-human identities?
- What breaks when SaaS access reviews focus only on accounts instead of entitlements?
- What breaks when AI dependencies are not included in application security reviews?
- What breaks when application security depends on periodic audits and manual reviews?