When AI is isolated as its own silo, teams miss the shared foundations underneath it. The same users, non-human identities, permissions, applications, and integrations often drive both SaaS and AI risk. Treating them separately obscures trust relationships, slows prioritisation, and makes it harder to understand how embedded AI changes the enterprise security posture.
Why the Separation Creates Blind Spots in the Control Model
AI governance rarely sits on a clean boundary. In practice, embedded AI, SaaS workflows, and identity controls share the same access paths, data flows, and approval chains. If AI is governed in isolation, teams tend to review models and policies without tracing the users, non-human identities, permissions, and integrations that actually make the system usable and risky.
That creates a control gap at the point where governance should connect to operational reality. The question is not only whether the AI use case is approved, but whether the surrounding access model still reflects who can invoke it, what it can reach, and which downstream systems it can affect.
A useful way to think about this is to anchor governance in the shared enterprise substrate, especially Identity Security Programme Guide and IAM and IGA Basics. Those controls help practitioners avoid treating AI as a standalone policy domain when it is really another consumer of access, entitlements, and trust relationships.
Where SaaS, AI, and Identity Risks Actually Overlap
When organisations separate AI governance from SaaS security, they often miss that the same account, token, or service integration can span both environments. A user may access a SaaS application, trigger an embedded AI feature, and move sensitive data through a third-party workflow without any new authentication event. That is why Top 10 NHI Issues is directly relevant here: the risk is not abstract AI risk, but overprivileged identities, stale credentials, and unmanaged integrations that cross application boundaries.
The same pattern also complicates prioritisation. Security teams may separately track SaaS misconfiguration, identity sprawl, and AI use cases, yet the real exposure comes from their combination. If an AI feature inherits excessive SaaS permissions, or if a non-human identity can call both business data and external model services, the blast radius is defined by the shared access model, not by any one product category.
That is why lifecycle and offboarding matter as much as policy approval. NHI Lifecycle Management Guide and Ultimate Guide to NHIs, Key Challenges and Risks both reinforce the same operational reality: if you cannot discover, classify, rotate, and retire the identities behind SaaS and AI integrations, governance becomes a paper exercise.
How to Govern Embedded AI Without Creating Another Silo
Embedded AI should be governed through the same control plane that governs enterprise access, with AI-specific review layered on top rather than separated from it. In practical terms, that means mapping the AI feature to the owning application, the identities it uses, the permissions it inherits, and the data paths it can touch. If those elements are unknown, the governance decision is incomplete no matter how strong the AI policy appears on paper.
This is also where cloud and platform governance become useful because many AI features ride on SaaS, APIs, and cloud integrations rather than on bespoke AI infrastructure. CSA Cloud Controls Matrix is helpful for framing this as a control-domain issue across IAM, data security, and operational governance, while NIST AI Risk Management Framework gives a governance lens for AI-specific risk treatment.
For organisations that need a more concrete operating model, the practical move is to align AI approval, SaaS review, and identity governance into one intake and one exception path. That does not mean one team owns everything. It means one decision record should show who owns the integration, who owns the identity, who owns the data exposure, and who accepts the residual risk.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST AI RMF, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | GV — Govern | AI governance decisions need enterprise risk treatment and ownership. |
| Recommendation — Embed AI review in governance, risk, and accountability processes before approval. | ||
| CIS Controls v8 | CIS-5 — Account Management | Shared SaaS and AI risks depend on controlling user and service accounts. |
| CIS-6 — Access Control Management | The issue centers on inherited permissions across SaaS and AI workflows. | |
| Recommendation — Inventory, govern, and remove unnecessary accounts and integrations. Review and restrict permissions that let SaaS or AI features reach sensitive data. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Separate AI and SaaS governance fails when accounts and their ownership are unclear. |
| IA-5 — Authenticator Management | AI and SaaS integrations often depend on tokens, keys, and other authenticators. | |
| Recommendation — Maintain authoritative account inventories and retire unused access promptly. Rotate and revoke authenticators that enable cross-system access. | ||
Practitioner Guidance
What to prioritise: Start with the identities and permissions that bridge SaaS and AI, not with the AI policy document itself. If the same service account, API key, or delegated user scope can reach both business data and an AI feature, that is the control point that needs review first.
What to verify: Confirm that every embedded AI capability has an identified business owner, an inventory of the underlying non-human identities, and a documented offboarding path. If any of those are missing, the governance model is not yet operational.
Common mistake: Teams often approve AI use cases as if they were isolated tooling decisions. In reality, the material risk usually comes from inherited SaaS entitlements, standing privileges, and opaque integrations that were never designed with AI in mind.
Practitioner takeaway: Treat AI governance as an extension of your existing SaaS and identity control model, because that is where the actual authority, exposure, and revocation power already live.
Related resources from NHI Mgmt Group
- Why is single-provider AI agent governance not enough for enterprise security?
- What is the difference between endpoint security and SaaS identity governance for AI agents?
- What are the emerging security controls needed for Agentic AI identity governance?
- What makes agentic AI an NHI governance issue?
