Shadow AI is unsanctioned AI adoption by users or teams outside central control. Embedded AI is when a trusted SaaS platform adds AI functions that change how the application processes data or permissions. Both create governance risk, but embedded AI is harder to spot because it hides inside approved software.
Why This Matters for Security Teams
shadow ai and embedded ai both expand the attack surface, but they fail governance in different ways. Shadow AI is visible only after someone bypasses approved tools, while embedded AI can hide inside sanctioned SaaS and inherit trust from the parent application. That makes embedded AI harder to inventory, harder to assess for data exposure, and easier to miss in access reviews. Security teams should treat both as NHI governance issues because each can introduce new identities, tokens, and data flows without clear ownership.
Current guidance suggests using the same discipline applied to non-human identities, secrets, and SaaS risk: identify where the AI function runs, what data it can reach, and which permissions it can exercise. The NIST Cybersecurity Framework 2.0 is useful here because the core problem is still asset visibility, access control, and ongoing monitoring. For breach patterns, the Snowflake breach and Salesloft OAuth token breach show how trusted integrations and stolen credentials can turn approved platforms into exfiltration paths. In practice, many security teams encounter embedded AI only after data has already moved through a trusted SaaS workflow, rather than through intentional discovery.
How It Works in Practice
The practical difference comes down to control surface. Shadow AI usually appears as a user-driven tool, browser plugin, personal account, or unsanctioned workflow that bypasses procurement and policy. Embedded AI, by contrast, is shipped by the SaaS vendor inside a product the business already trusts. That means the application may start summarising records, generating content, classifying cases, or recommending actions without a corresponding change in the organisation’s approval model. The AI feature can inherit the SaaS app’s authentication, but not necessarily its governance boundaries.
Teams should therefore examine four things: where the feature sits in the workflow, what data it can ingest, whether it changes access decisions, and whether it introduces new machine identities or third-party model calls. The Ultimate Guide to NHIs — What are Non-Human Identities helps frame the identity side of that review, while the NIST Cybersecurity Framework 2.0 supports the operational steps: identify, protect, detect, and respond. For SaaS-specific risk, security teams should verify whether the AI feature uses customer data for inference, retains prompts, exposes outputs to broader roles, or creates hidden API calls to external models.
- Inventory AI functions separately from the parent SaaS application.
- Map each feature to the data it can read, write, or summarise.
- Review whether the feature introduces new tokens, connectors, or service accounts.
- Confirm whether administrators can disable or constrain the AI function.
The DeepSeek breach is a reminder that AI systems can expose sensitive data at scale when training, logging, or backend controls are weak. These controls tend to break down when SaaS vendors silently enable AI features across tenants because the organisation’s normal approval process does not see a new application, only a changed one.
Common Variations and Edge Cases
Tighter control often increases review overhead, requiring organisations to balance faster SaaS adoption against the risk of hidden AI functionality. That tradeoff becomes sharper when a vendor allows AI to be enabled per workspace, per role, or per tenant with limited visibility for administrators.
One common edge case is “embedded but optional” AI, where the feature is off by default but can be activated by a business owner without a formal security review. Another is “embedded and dependent,” where the SaaS workflow breaks if AI is removed, making the feature harder to govern after deployment. There is no universal standard for this yet, so current guidance suggests treating any AI function that changes data handling, permissions, or retention as a material control change, not a cosmetic feature update. The BeyondTrust API key breach is relevant because exposed secrets and trusted integrations can make approved tooling the easiest path into sensitive environments. For governance, teams should also watch for role creep: if embedded AI suggestions influence approvals, routing, or access decisions, RBAC alone may not be enough without explicit human review and logging. The most difficult cases are enterprise SaaS platforms with opaque model routing and shared backend services, because the AI component may be impossible to isolate cleanly from the rest of the application.
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 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Embedded AI often introduces unmanaged non-human identities and tokens. |
| CSA MAESTRO | M1 | Covers governance for autonomous and embedded AI-driven workflows. |
| NIST AI RMF | AI RMF helps assess and monitor risks from hidden AI features in trusted software. |
Inventory every SaaS AI token, connector, and service account before allowing production use.
