Embedded AI in SaaS vs Standalone AI Tools: One Governance Model for Both Paths

AI now reaches company data by two very different routes, a feature switched on inside a SaaS application you already approved, or a separate AI tool someone signs up for, and a governance programme built for only one of them misses half the exposure. Standalone tools are the classic shadow AI problem: a new supplier, a new account and data copied out of your estate. Embedded features arrive through a trusted supplier, inherit existing permissions and often bypass procurement entirely. This guide compares the two paths on the four questions that decide the risk: how the capability is procured, what the data-use terms say, which permissions it exposes and how you discover it. It then gives a threat model, failure modes, controls and decision criteria for each, and a worked scenario. It is written for security, privacy and procurement leads who own AI use policy. Vendor-specific admin settings are covered in the Embedded AI in SaaS Guide and are not repeated here.

Key takeaways

• Same goal, different choke points. Standalone AI is governed at the network, identity and procurement edge; embedded AI is governed in the admin console of each SaaS application and in its contract.
• Embedded AI turns oversharing into disclosure. An assistant that respects existing permissions will still surface everything a user can technically open, so permission hygiene is the main control.
• Standalone AI turns copy and paste into a transfer. Data leaves your estate to a supplier you may never have assessed, under terms that differ by plan and by account type.
• Discovery uses different signals. Proxy, DNS and OAuth logs find standalone tools; admin audit logs, release notes and contract change notices find embedded features.
• One register, two intake routes. Track both paths in a single AI use register with the same risk questions, so a decision on one route does not quietly shift use to the other.

The short answer

Treat a new embedded AI feature as a change to an existing supplier relationship and a standalone AI tool as a new supplier. For embedded features, the work is permission clean-up, contract and data processing addendum (DPA) review, and controlling auto-enablement. For standalone tools, the work is discovery, a sanctioned alternative, identity control over who can sign in, and blocking or coaching for the rest; the Block vs Sanction vs Coach guide covers those stances. Neither path should be blocked wholesale: both are now part of how work gets done, and blocking one pushes demand to the other.

The governance comparison table

This table is the core of the guide. Use it in your AI use register so every request or detected use is assessed on the same four dimensions.

Embedded AI: threat model, architecture and failure modes

Architecture in words: a user asks the assistant inside the application. The vendor's service retrieves content the user can access (documents, messages, records, sometimes content from connected applications or the web), adds it to a prompt, sends it to a model run by the vendor or a subprocessor, and returns the answer, sometimes storing the interaction. Agentic features can then act: send, create or update records.

Threat model:

• Oversharing becomes discoverable: retrieval is permission-trimmed, so the assistant shows only what the user can access. But sites shared with everyone, stale group memberships and broad channel access were tolerable when nobody searched them; an assistant surfaces them in seconds. OWASP LLM02:2025 Sensitive Information Disclosure describes how LLMs embedded in applications can expose confidential data through output.
• Indirect prompt injection: the assistant reads content an outsider wrote (email, shared documents, tickets) and can be steered by instructions hidden in it (OWASP LLM01:2025, MITRE ATLAS AML.T0051). The EchoLeak disclosure showed a crafted email pulled into an assistant's context during a routine question, with the assistant acting under the user's own delegated access.
• Excessive agency: features that can send or change records turn a disclosure problem into an integrity problem (OWASP LLM06:2025 Excessive Agency).
• Silent scope change: a feature enabled for one product may reach data in sibling products on the same platform, and new features can arrive on by default.
• Processing chain change: new model subprocessors and processing locations, which under GDPR Article 28(2) require the processor to inform the controller of intended changes where a general authorisation is in place, giving the controller the chance to object.

Failure modes: features found months after release; a DPA that predates the AI terms; an assistant licensed to everyone in a tenant where half of the file shares are open to the whole organisation; stored AI interactions never included in retention or eDiscovery scope.

Controls:

• Permission clean-up first: fix organisation-wide links, public spaces and stale groups in the sources the assistant reads before enabling it. See the Enterprise AI Copilot Security Guide.
• Scope and pilot: enable by group or licence, starting with a pilot ring whose data is clean.
• Turn off auto-enablement of future AI features where the platform offers it, and lock user-level toggles.
• Restrict reach: turn off web grounding, file use and third-party connectors in AI features unless the use case needs them.
• Contract: AI addendum covering training use, retention, processing location, subprocessor change notice and AI feature change notice.
• Logging: include stored prompts and responses in retention, legal hold and audit search.

Standalone AI tools: threat model, architecture and failure modes

Architecture in words: a user opens a separate AI service in a browser, desktop app, mobile app or IDE plugin, signs in with a corporate or personal identity, and pastes, uploads or connects data. With an OAuth connection the tool's backend holds tokens to mail, files, code or CRM and can read them without the user present.

Threat model:

• Uncontrolled transfer: data leaves to a supplier with no assessment and terms that may allow training on inputs or long retention, particularly on consumer plans.
• Personal accounts on approved services: even where an enterprise tenant exists, users signed in with personal accounts fall outside its contract and logs.
• OAuth grants and connectors: a connected tool becomes an integration with standing tokens. Theft of those tokens from the provider gives access to your data without touching your users (MITRE ATT&CK T1528 Steal Application Access Token). The Salesloft Drift breach showed stolen OAuth access and refresh tokens from one chatbot integration being used to export CRM data from hundreds of organisations.
• Supply chain: browser extensions and IDE plugins marketed as AI assistants request broad permissions and can harvest content or keys.
• Displacement: blocking a tool without an alternative moves use to personal devices where you see nothing.

Failure modes: a blocklist that is always behind the market; an enterprise licence bought but sign-in not forced through SSO; OAuth grants given before the policy existed and never reviewed; expense-paid team plans no one knows about.

Controls:

• Discover: SWG, DNS and CASB logs for AI app categories, OAuth grant inventories in mail and file platforms, browser extension inventories and expense data. See the Shadow AI Discovery Guide.
• Sanction an alternative: one or two enterprise AI services with contract terms covering training, retention and residency, sign-in forced through corporate identity.
• Restrict instances: tenant or instance restrictions so only the corporate tenant of an approved tool is reachable from managed devices.
• Consent policy: require admin approval for OAuth apps requesting mail, file or code scopes. See the SaaS and OAuth App Governance Guide.
• DLP: inspect uploads and pastes to AI destinations for the data classes that must never leave. See the Generative AI Data Loss Prevention Guide.
• Coach the long tail: warn-and-justify for unknown tools rather than silently allowing or blocking.

Contract and DPA changes for each path

The contract work differs because the starting point differs. Embedded AI amends an existing agreement; standalone AI starts one or relies on click-through terms.

NIST AI 600-1, the Generative AI Profile, lists Value Chain and Component Integration among its twelve generative AI risks and suggests actions such as maintaining approved provider lists, contract clauses that allow evaluation of third-party processes, and incident response plans for third-party generative AI (GV-6.1 and GV-6.2). Where personal data is processed in a way likely to result in high risk, GDPR Article 35(1) requires a data protection impact assessment before processing starts. The interplay of contract and technical controls is covered in Contractual vs Technical Controls for Third-Party AI.

Discovering silently enabled features

Embedded features are the harder discovery problem because nothing new crosses the network edge: traffic goes to a domain you already allow, through a session you already trust. Build discovery from four sources:

1. Admin console sweep: for each SaaS application in the inventory, record which AI features exist, their state, who can use them and whether future features auto-enable. Repeat quarterly and after major releases.
2. Admin audit logs: alert on AI setting changes and licence assignments that grant AI add-ons.
3. Supplier notices: route subprocessor change notices, DPA updates and release notes to the application owner and privacy team, with a review trigger when a new model provider or data source appears.
4. Usage signals: where the platform reports AI usage, review it monthly for unexpected groups or volumes.

Standalone discovery is better tooled: proxy and DNS categorisation, CASB catalogues and OAuth inventories. The gap is unmanaged devices and personal accounts, which only a sanctioned alternative and clear policy close. The AI Gateway vs CASB/SSE for Controlling Shadow AI guide covers the enforcement options.

Where identity fits

Both paths are identity problems. Embedded assistants act with the user's delegated access, so least privilege for people (AC-6) is the main data control. Standalone tools connected by OAuth are non-human identities: each grant is a client with scopes, tokens and no owner unless you assign one. Inventory them, review scopes, and revoke tokens when a provider reports a breach. AI agents that act inside SaaS applications should be registered and reviewed as identities in their own right.

Decision criteria

A practical rule: if the same task can be done by an embedded feature over already-governed data or by pasting that data into a standalone tool, prefer the embedded feature once permissions are clean. The data stays inside a supplier you have already assessed. Prefer the standalone tool when the embedded feature would need to read far more data than the task requires.

Worked scenario: a professional services firm

A 1,200-person firm finds, during a quarterly review, three things at once: a meeting summary feature in its video platform switched on for everyone after a licence change; a document assistant in its collaboration suite available as a paid add-on that 40 partners bought on their own budgets; and 300 staff using a consumer chatbot, 60 of whom connected it to corporate mail by OAuth.

1. Register all three: each goes into the AI use register and is scored on procurement path, data-use terms, permission exposure and discovery source.
2. Meeting summaries (embedded): the privacy team confirms a new model subprocessor appeared in the vendor's notice two months earlier. Summaries are restricted to internal meetings and kept off for client-facing meeting groups until the DPA addendum is signed.
3. Document assistant (embedded add-on): a permission scan finds 18% of client folders shared organisation-wide. The add-on is paused for partners on matters with open sharing, folders are fixed, then the feature is re-enabled by group.
4. Consumer chatbot (standalone): the 60 OAuth grants are revoked, admin consent is required for mail scopes, and an enterprise plan of a sanctioned AI tool is rolled out with SSO and instance restrictions. Unknown AI destinations get a coaching page linking to it.
5. Measure: after a month, personal-account use falls as sanctioned use rises, and no AI feature is found on that was not already in the register.

How to implement

1. Create one AI use register with both intake routes and the four comparison dimensions as mandatory fields.
2. Sweep embedded features in the top SaaS applications by data sensitivity and record state, scope and terms.
3. Run standalone discovery from proxy, DNS, OAuth and expense data for 30 days before changing policy, so you know demand.
4. Fix permissions in the sources embedded assistants read, starting with organisation-wide sharing.
5. Stand up a sanctioned standalone option before tightening blocks.
6. Pilot changes: coaching mode before blocking, a pilot group before tenant-wide enablement, report-only consent policies where available.
7. Roll back cleanly: record the switch for each embedded feature and the propagation time; keep the coaching rule ready to replace a block that disrupts work.
8. Re-review on change: new model provider, new data source, new action capability or new terms reopens the entry.

Detection and measurement

• Embedded: AI setting changes in admin audit logs, AI licence assignments, assistant access to content labelled confidential, connector and web grounding use.
• Standalone: AI category traffic by app and instance, uploads blocked or coached by DLP, new OAuth grants with AI app publishers, personal-account sign-ins to sanctioned apps.

Metrics:

• Percentage of top SaaS applications with AI feature state recorded in the register.
• Number of AI features found enabled that were not in the register (target: falling to zero).
• Percentage of organisation-wide sharing links removed in sources read by assistants.
• Share of standalone AI traffic going to sanctioned tenants.
• Count of OAuth grants to AI apps without an owner or approval.
• Median days from supplier AI change notice to completed review.

Common failure patterns

• Governing only the edge: CASB policies for standalone tools while embedded assistants read every open file share.
• Assuming the existing DPA covers AI: new model subprocessors and processing locations appear without a review.
• Blocking standalone tools without an alternative: use moves to personal devices and personal accounts.
• Treating OAuth grants to AI tools as user choices: they are integrations with standing tokens that need owners and revocation plans.
• Enabling assistants tenant-wide before permission clean-up: the assistant becomes the fastest way to find overshared data.

Framework mapping

Practitioner checklist

• Keep one AI use register covering both embedded features and standalone tools.
• Score every entry on procurement path, data-use terms, permission exposure and discovery source.
• Turn off auto-enablement of new AI features where platforms allow it.
• Clean up organisation-wide sharing before enabling assistants that read it.
• Add AI training, retention, subprocessor and feature change terms to renewals.
• Provide a sanctioned standalone AI service with SSO before blocking others.
• Require admin approval for OAuth grants to AI apps requesting mail, file or code scopes.
• Route supplier AI change notices to a named reviewer with a deadline.
• Report the six metrics above to the AI governance group monthly.

Standards and references

• NIST: AI 600-1 Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
• EUR-Lex: Regulation (EU) 2016/679 General Data Protection Regulation
• OWASP: LLM02:2025 Sensitive Information Disclosure
• OWASP: LLM01:2025 Prompt Injection
• OWASP: LLM06:2025 Excessive Agency
• NCSC: Guidelines for secure AI system development
• MITRE ATT&CK: T1528 Steal Application Access Token

Related NHI Mgmt Group resources: Third-Party AI Risk Guide · AI Usage Control and Shadow AI · Enterprise AI Licences vs Consumer AI Tools · SaaS Security Guide