Approved tool, unapproved capability: the 2026 shadow-AI gap your discovery playbook does not see

The 2024 shadow-AI conversation assumed unsanctioned tools. An engineer pasted source code into a public ChatGPT window. A marketing director signed up for a personal Notion plan and built a product roadmap. A salesperson plugged a CRM export into a personal Claude account. The discovery playbook (AM-036) was scoped to that pattern: find the tools nobody approved, then govern them.

In 2026 the unsanctioned-tool problem is still real but it is no longer the dominant gap. The dominant gap is sanctioned tools that have shipped agentic capabilities the procurement team did not authorise. Microsoft 365 Copilot Studio inside an already-approved M365 tenant. Slack AI and Slack Agents inside an already-approved Slack workspace. Notion AI agents inside an already-approved Notion workspace. ServiceNow Now Assist inside an already-approved ITSM tenant. Atlassian Rovo inside an already-approved Jira and Confluence estate. Salesforce Agentforce inside an already-approved Sales Cloud and Service Cloud contract. Every one of these is an intra-vendor capability expansion that the enterprise’s SaaS approval process did not trigger a re-evaluation on. Discovery has to move from “which vendors” to “which capabilities inside the approved vendors”. The 2024 playbook is the right tool for the wrong half of the problem.

What changed structurally between 2024 and 2026

The enterprise SaaS approval process, the one most procurement and security functions ran through 2023 and 2024, has three load-bearing checks. It governs who the vendor is (legal entity, jurisdiction, financial stability, references). It governs what data classes can go into the vendor’s product (public, internal, confidential, regulated, PII, PCI, PHI). It governs how the vendor handles the data (encryption at rest and in transit, sub-processors, data residency, retention, deletion, breach notification).

The process does not, in general, govern what the vendor adds to the product after the original approval. The implicit assumption was that material changes to a SaaS product would either go through a contract amendment (triggering re-evaluation), be billed under a new SKU (triggering procurement), or arrive as a new product the customer would separately evaluate.

Through 2024 and 2025, the major enterprise SaaS vendors with already-approved tenants in most large enterprises rebuilt their products around agentic capability. The capabilities arrived not as new vendors, not as new contracts, not always as new SKUs, they arrived as new entitlements inside existing licence paths or as default-on features of existing products. The procurement function did not get a re-evaluation trigger because the trigger conditions the process listened for were not met. The vendor did not change. The contract did not change. The headline SKU did not change. The data classes nominally did not change.

The capability surface changed, materially. The implicit assumption that change-of-capability would arrive as change-of-contract no longer holds.

The four canonical 2026 cases

Microsoft 365 Copilot Studio. Reached general availability in November 2023 and is now bundled into the standard Microsoft 365 Copilot licence path. Any business-user with the right entitlement can build an agent that reads from SharePoint, Outlook, Teams, OneDrive, and any connected line-of-business data source, and writes to Power Automate flows, Dataverse, or back into Microsoft 365 surfaces. The agent runs inside the customer’s M365 tenant under the user’s identity. From the customer’s perspective, no new vendor was approved; from the capability-surface perspective, business-user-built agentic automations with broad tenant-data access went from zero to entitled-user-many in a single licensing change.

Slack AI and the Slack agent platform. Slack’s agent and Workflow Builder ecosystem extends inside the customer’s already-approved Slack workspace, with the agent inheriting the workspace’s data scope (every channel and DM accessible to the user who provisioned the agent, by default). Slack’s Agentforce-integration path further extends to Salesforce data. The customer’s approval of Slack as a messaging tool predates the agent surface; the messaging-tool approval does not pass-through to agent-tool approval, but the technical entitlement does.

Notion AI agents. Notion’s AI agents hub surfaces an agent-building capability inside every approved Notion workspace on the eligible plan. The agent can read from any page or database the building user has access to, and can write to pages and databases the same user has access to. As with M365 Copilot Studio, the identity scope is the user’s, but the capability is a step change beyond the document-editing surface the customer originally approved.

ServiceNow Now Assist. Now Assist is GA inside the customer’s already-approved ServiceNow tenant across ITSM, HR Service Delivery, Customer Service Management, and the IT Operations Management portfolio. The agentic features run against the customer’s existing tickets, knowledge base, CMDB, and workflow data. Now Assist is a SKU expansion, but the customer-side approval process for new ServiceNow SKUs is typically lighter than the original ServiceNow procurement because the vendor relationship is established.

The four cases differ in licensing detail; they share the structural property that the customer’s existing procurement process did not detect the capability expansion.

Why DLP and tenant-level access controls miss this

Data-loss prevention tooling is designed to detect data leaving the enterprise through specified egress channels. The egress channels DLP enumerates are email attachments, web uploads to unapproved domains, removable media, instant-message file transfers, cloud-storage uploads to unsanctioned tenants. An intra-vendor agent does not traverse any of these. M365 Copilot Studio reading from a SharePoint document and writing back to a Power Automate flow stays entirely inside the customer’s M365 tenant; nothing crosses an egress boundary the DLP is configured to inspect. The data is being processed by a new agentic surface inside an already-approved vendor boundary, which DLP treats as in-policy because the vendor is in-policy.

Tenant-level access controls have a parallel limitation. The customer’s identity provider (Entra ID, Okta, Google Workspace) governs which users can access which tenants and which roles within those tenants. It does not govern which entitlements within an approved tenant a user can exercise. A user entitled to M365 Copilot Studio inherits the agent-build capability whether or not the security team intended that outcome.

The defensive gap is not a tooling failure. It is a category mismatch. The 2024 defensive stack was built around vendor-discovery and egress-detection because the 2024 threat model was unsanctioned-tool adoption. The 2026 threat model includes capability expansion inside sanctioned tools, which the existing stack is structurally unequipped to surface.

The procurement-side instrument

The instrument is a re-evaluation trigger added to the SaaS approval policy. The policy text:

Any vendor with an approved enterprise tenant in our environment that ships a new agentic or generative-AI capability inside the existing licence path triggers a re-evaluation of the original approval. The re-evaluation runs the original data-class and risk-assessment workflow against the new capability surface within 30 days of the capability becoming available to entitled users in our environment.

The trigger is operationalised through a vendor-watch list maintained by procurement and security jointly. The named vendors are subscribed to via release-notes RSS feeds, customer-success channels, and product-change notification feeds. The named platforms are monitored quarterly for new capability surfaces. The re-evaluation runs whenever a new agentic SKU or entitlement lands inside an approved vendor. The re-evaluation outputs are: the capability surface description, the new data classes it can reach, the new identity primitive (if applicable, links into the NHI procurement clause gap at AM-167), the new audit obligation, and the customer’s go-forward stance (allow, allow-with-restriction, disable for non-admin users, contract addendum required).

The cost is light at steady state, the re-evaluation is faster than the original approval because the vendor relationship is already known. The cost at backlog clearance is heavier: most enterprises in 2026 have a backlog of two to three years’ worth of unevaluated capability expansions to work through. The backlog is the work; the steady-state cost is then bounded.

The discovery instrument when the trigger has already been missed

Three places to look.

The first is the identity provider. Query Entra ID, Okta, or the equivalent for OAuth grant patterns showing the new agentic SKU’s app registration receiving consent in the customer tenant. The grant date is the capability-activation date. The grant scope describes the data the capability is entitled to reach. The grants that arrived after the original vendor approval are the inventory of intra-vendor agent surfaces.

The second is the vendor’s own admin console. M365 Copilot usage analytics, Slack Enterprise audit logs, Notion workspace activity reports, ServiceNow Now Assist consumption dashboards. The vendor’s admin telemetry will show capability usage even where DLP does not. The audit is straightforward but requires admin-side cooperation across each vendor relationship.

The third is financial. Licence-true-up reports and SaaS-spend-management platforms (Zylo, Productiv, BetterCloud, Torii) surface SKU changes inside approved vendors that procurement did not authorise. The spend signal is sometimes the earliest signal because the licensing change precedes the usage change.

Combining the three produces an inventory of intra-vendor agent capabilities actually in use, against which the re-evaluation policy can be applied retrospectively. The inventory is the artefact the audit needs.

The audit consequence

ISO 27001:2022 Annex A 5.23 (information security for use of cloud services) and Annex A 8.30 (outsourced development) require ongoing evaluation of cloud services against the customer’s security requirements. The requirement is not a one-time evaluation at procurement. A vendor that shipped a new agentic capability inside an already-approved tenant changed the service the customer is consuming; the audit question is what the customer’s process is for detecting and re-evaluating that change. The Q4 2026 and Q1 2027 ISO surveillance audits will surface this for any enterprise that ran the 2024 SaaS approval process unchanged through the 2025-2026 vendor-side agent rollout.

SOC 2 CC9.2 (vendor management) is the parallel SOC pathway and the most common control to fail on this gap. The auditor’s evidence request is the vendor-watch list, the re-evaluation trigger policy, the inventory of capability changes in the audit period, and the re-evaluation outputs. An enterprise that has run the trigger consistently passes on documented operation; an enterprise that has not is in deficiency-remediation mode for the next reporting cycle.

What this means for the IT leadership agenda

The first action is the backlog inventory pass. The three sources (identity provider OAuth grants, vendor admin consoles, SaaS-spend platforms) jointly produce the list of intra-vendor agent capabilities active in the environment today. The list is the procurement function’s input to the re-evaluation queue. Highest-risk items (agents with transaction authority, agents with broad data scope, agents in regulated workflows) lead the queue.

The second action is the policy text. The re-evaluation-trigger paragraph above is the minimum viable version. Procurement counsel and security jointly own the language; the policy attaches to the existing SaaS approval framework rather than replacing it.

The third action is the monitoring discipline. The named vendors (Microsoft, Slack/Salesforce, Notion, ServiceNow, Atlassian, Google Workspace, Box, Asana, plus the customer’s specific enterprise vendors with active capability roadmaps) are the vendor-watch list. The monitoring cadence is quarterly at minimum, with release-notes subscriptions for monthly signal. The output of the monitoring is the inbound queue for the re-evaluation trigger.

The 2024 shadow-AI question was “which AI tools is the organisation using that procurement does not know about”. The 2026 shadow-AI question is “which AI capabilities are running inside the tools procurement already approved, that procurement did not separately evaluate”. The 2024 playbook (AM-036) and the Samsung detection-lag reading (AM-156) cover the prior version. This piece covers the version most enterprises are currently exposed to and most discovery efforts are not finding. The re-evaluation trigger is the procurement instrument; the backlog inventory is the operational starting point.