Ownership should sit across IAM, IGA, security engineering, and application platform teams. The risk is created by human behaviour but expressed through non-human identities and unmanaged tool access, so a single control owner will miss part of the chain. Governance needs one accountable process, not separate silos.
Why This Matters for Security Teams
shadow saas in engineering teams is not just a procurement problem. It creates unmanaged non-human identities, OAuth grants, API keys, service accounts, and automation paths that bypass normal approval and review. That means the risk lands in IAM, IGA, security engineering, and platform ownership at the same time. NHI Management Group’s Ultimate Guide to NHIs shows how quickly this breaks down in practice: 96% of organisations store secrets outside secrets managers, and 79% have experienced secrets leaks. Once engineering adopts a tool without central review, the access path often outlives the project that introduced it.
The right ownership model is therefore a governed process with one accountable risk owner, not a request to “just fix IAM.” NIST’s Cybersecurity Framework 2.0 reinforces that governance, risk, and access control must be coordinated across functions. In practice, many security teams encounter shadow SaaS only after tokens have already been reused, credentials exposed, or an abandoned integration has become the easiest path into production.
How It Works in Practice
Operational ownership usually works best as a three-layer model. First, an accountable business or engineering leader owns the risk decision for the tool itself. Second, security engineering owns the control design for discovery, detection, and containment. Third, IAM and IGA own the identity lifecycle for the human and non-human access that the tool creates. This avoids the common failure where no team owns the end-to-end chain from sign-up to secret sprawl to revocation.
For engineering environments, the mechanics should focus on finding and classifying the tool, then binding every related identity to policy. That includes:
- discovering SaaS usage from SSO logs, browser telemetry, CASB signals, and SaaS admin APIs
- mapping each app to its service accounts, OAuth grants, API keys, and webhook endpoints
- assigning a control owner for approval, review, and removal when the tool is no longer justified
- enforcing short-lived credentials and explicit rotation for any secrets the tool requires
- recording the integration in IGA so access can be certified and revoked on a schedule
The pattern is supported by NHI guidance in the Top 10 NHI Issues and by the publicised Salesloft OAuth token breach, which illustrates how trusted integrations can become a broad data-access path when grants are not tightly governed. Current guidance suggests treating shadow SaaS as an identity problem first, because the app name matters less than the standing access it silently creates. These controls tend to break down in fast-moving CI/CD environments where engineers can approve new tools and mint tokens without a central review step.
Common Variations and Edge Cases
Tighter control often increases friction for engineering, so organisations must balance delivery speed against the cost of unmanaged access. The hard cases are usually not the obvious SaaS purchases. They are browser extensions, AI coding assistants, ephemeral test environments, and team-owned automation that appear temporary but accumulate persistent permissions over time.
There is no universal standard for ownership of every shadow SaaS scenario yet, but current guidance suggests using a tiered decision model. Low-risk collaboration tools can be routed through standard procurement and IGA review. Higher-risk tools that touch code, production data, or secrets should require security engineering review and explicit lifecycle ownership. In regulated environments, the accountable owner should also be able to prove revocation, not merely approval.
Where this often gets missed is in tool sprawl across repositories and pipelines. A developer may disable an app, but the related API key, refresh token, or workflow automation remains active in another system. That is why ownership has to follow the identity chain, not the purchase request. The Ultimate Guide to NHIs notes that 91.6% of secrets remain valid five days after notification, which shows how slowly revocation often happens in real operations.
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 CSA MAESTRO address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Shadow SaaS often leaves long-lived NHI secrets unrotated and unowned. |
| CSA MAESTRO | MAESTRO covers governance for agentic and automated tool access paths. | |
| NIST AI RMF | AI RMF helps govern emergent tool risk from autonomous or AI-assisted workflows. | |
| NIST CSF 2.0 | PR.AA | Identity and access assurance is central to shadow SaaS containment. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust limits the blast radius of unsanctioned SaaS and NHI access. |
Use MAESTRO to define accountable owners for automated integrations and their permissions.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 1, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
