Treat embedded AI as a discovery and governance problem, not a simple allowlist problem. Approved software can switch on AI capabilities without a new intake, so teams need continuous recertification of features, data paths, and identity grants. The practical goal is to know which AI functions are active, who can use them, and what information they can reach.
Why Shadow AI Becomes a Feature-Governance Problem Inside Approved Software
When AI appears inside software your organisation already approved, the control question changes. The risk is no longer only whether a tool was purchased or blocked, but whether new AI-driven functions have been activated, what data they can see, and what identity or permission path makes them usable. That makes discovery continuous, not one-time.
Approved applications often evolve faster than procurement, and AI features may arrive through product updates, tenant settings, trial toggles, or third-party integrations. A team that only reviews the original software intake can miss a newly enabled model, plugin, connector, or assistant that changes the information flow or expands the blast radius.
Teams should therefore treat embedded AI as part of the application’s operational state. The practical unit of review is not just the app name, but the active feature set, the connected data sources, and the accounts or tokens that authorize access to those features.
What Needs to Be Recertified, Not Just Approved
The useful baseline is a recurring inventory of AI features inside sanctioned software, plus the controls around them. That inventory should answer three questions: which AI functions are live, which datasets or prompts they can reach, and which users, roles, or service connections can invoke them. Without those three answers, the organisation cannot judge whether the feature remains acceptable.
This recertification has to include identity grants as well as software status. If an application can be enabled by a tenant admin, a user consent flow, an OAuth grant, or a connected API token, then the governance team needs to review those paths with the same seriousness it would apply to any other privileged access path. The issue is not the label “AI”, it is the access route and the reachable data.
Approved software also needs feature-level ownership. Someone must be able to say whether the AI capability is supported, restricted, monitored, or disabled, and must be able to prove that decision after a vendor update. That is why governance should be anchored to product configuration, data classification, and access rights rather than to a static allowlist.
How to Operationalise Detection and Control Without Freezing the Business
A workable approach is to combine discovery, policy, and exception handling. Discovery finds AI capabilities in use, policy defines which data and identities may interact with them, and exception handling records the cases where a business owner accepts a narrower control set because the feature is genuinely needed.
For teams managing SaaS sprawl and federated access, NHIMG’s Shadow AI and AI Agent Discovery Guide is directly useful because it frames discovery around OAuth grants, API keys, cloud signals, and endpoint or network indicators rather than relying on procurement records alone. That is the right lens when a sanctioned product quietly becomes an AI platform through integration or consent.
Where the main exposure is data leakage through user behaviour inside approved tools, NHIMG’s Samsung ChatGPT leak 2023 is a useful reminder that approval of a tool does not mean approval of every way people will use it. The governance question is whether sensitive material can be entered, retained, or replicated in ways the original approval never contemplated.
For access paths and third-party integrations, NHIMG’s Vercel Context.ai OAuth Supply Chain Breach shows why consented connectivity needs review after initial approval. A trusted app can still become a data exposure path when a connected AI capability inherits more access than the business intended.
Risk and Threat Considerations
Embedded AI creates a drift risk: the organisation thinks it approved a software product, but the effective behaviour changed after deployment. That can expose confidential data, create unaudited third-party access, or let users move information into a model or connector the security team never assessed.
Failure mechanism: The failure usually happens when feature toggles, consented integrations, or token-based connections activate AI functionality without a new review of permissions, data paths, or retention behaviour. The control fails because the approval model is product-centric while the exposure is feature-centric.
Impact: Sensitive data can be disclosed, copied into external services, or made available to broader user populations than intended. In the worst case, the organisation inherits a hidden dependency on a vendor’s model behaviour, logging, or subcontractors without having updated its risk decision.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | AI features change access paths and should be limited to the minimum needed. |
| CM-8 — System Component Inventory | Embedded AI requires continuous inventory of active features and integrations. | |
| IA-5 — Authenticator Management | AI feature use often depends on tokens and consented credentials that need governance. | |
| Recommendation — Limit AI feature access to the minimum identities and data paths required. Inventory and recertify AI-capable software features and connections continuously. Review and rotate tokens or credentials that enable AI integrations. | ||
| NIST CSF 2.0 | GV.OC-03 — Roles, Responsibilities, and Authorities | Feature-level AI governance needs clear ownership and accountability. |
| ID.RA-05 — Threats, vulnerabilities, likelihoods, and impacts are used to understand inherent risk | Teams must assess the risk of newly activated AI functions and data paths. | |
| Recommendation — Assign ownership for approving, monitoring, and recertifying embedded AI features. Reassess risk whenever software updates change AI capability or access paths. | ||
Practitioner Guidance
What to prioritise: Start with software that already has broad data reach, such as collaboration, CRM, support, code, and document tools. Those systems are the most likely to hide AI features that can touch regulated, proprietary, or customer data.
What to verify: Confirm whether each AI feature is on by default, user-enabled, admin-enabled, or enabled through a connected app. Then verify what data sources, prompts, and exports the feature can access, because that is where the real governance boundary lives.
Decision rule: If a sanctioned application can reach sensitive data through an AI feature, treat it as a governed capability, not as a harmless enhancement. If you cannot explain the feature’s data path and identity grants in one review cycle, restrict it until you can.
Practitioner takeaway: shadow ai inside approved software is best managed as continuous feature control, not one-time software approval. The teams that stay ahead are the ones that recertify functionality, access, and data reach together.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org