Enterprise security teams spent 2024 building AI governance policies. They spent 2025 discovering that those policies covered sanctioned tools and missed the other forty-seven that business units adopted without asking. In 2026, the gap between policy and practice is the primary AI risk facing most organisations — and the exposure is almost entirely in third-party tooling.
The risk is structural. When a developer connects an AI coding assistant to a repository, or when a finance analyst pastes a contract into a document summarisation tool, or when an executive uses a meeting intelligence platform that transcribes every board call, they are extending trust to a vendor whose data handling practices are rarely understood and less frequently contractually constrained. The question is not whether your organisation uses AI tools. It is whether the contracts governing those tools reflect the data they actually process.
The Five Risk Categories
1. Training data opt-out and model improvement clauses
Most AI SaaS vendors include a clause permitting them to use customer data to improve their models. For consumer-tier products, this is expected. For enterprise tools processing source code, legal documents, financial projections, or HR data, it is a data protection and intellectual property problem.
The risk is not abstract. In 2023, Samsung engineers used ChatGPT to debug proprietary semiconductor code; the inputs became training data. That incident triggered enterprise-wide bans at multiple large organisations. The same failure mode exists in every AI tool that defaults to training opt-in.
What to require in contracts: Explicit training data exclusion by default, not as an enterprise-tier upgrade. Prohibition on using customer inputs or outputs for model training, benchmarking, or product improvement. Audit rights to verify compliance.
2. Data residency and subprocessor chains
AI inference often involves a chain: the vendor’s application calls a third-party model API (OpenAI, Anthropic, Google, Cohere), which may itself invoke retrieval services, embeddings databases, or safety filtering systems. Each link is a subprocessor.
GDPR Article 28 requires that subprocessors be disclosed and subject to the same contractual obligations as the primary processor. Most AI vendor DPAs list model providers as subprocessors but treat the chain as fixed. When vendors switch model providers — which happens frequently as costs and capabilities shift — they may not trigger the DPA’s change notification requirements.
What to require in contracts: Complete subprocessor list with data residency for each. Contractual notification period (minimum 30 days) before new subprocessors are added. Right to object to subprocessor changes with a termination right if the objection is not resolved.
3. Prompt injection and data exfiltration via AI agents
AI tools with agentic capabilities — those that can read files, browse URLs, execute code, or take actions on behalf of users — introduce a prompt injection attack surface that traditional application security reviews do not cover.
The Miasma supply chain worm (June 2026) demonstrated this explicitly: malicious content embedded in cloned repositories executed automatically when opened in Claude Code, Cursor, or VS Code with AI extensions. The attack vector was the AI tool’s file system access, not the application itself. Any AI tool with “context awareness” or “workspace integration” features has an equivalent attack surface.
What to require in contracts: Vendor disclosure of all actions the tool can take autonomously (file reads, writes, API calls, web browsing). Contractual commitment to sandboxing and permission minimisation. Incident notification within 24 hours of any security event affecting customer data.
4. Access token and credential scope
AI productivity tools frequently request OAuth scopes far exceeding their stated function. A meeting summarisation tool that requests read access to your entire Google Drive to find “relevant documents” is over-privileged. A sales intelligence tool that requests contacts:write to “sync” data is over-privileged.
During the Miasma and Mini Shai-Hulud campaigns, initial access in several cases came through OAuth tokens granted to developer tools that had accumulated broad repository permissions over time. Token hygiene — reviewing and revoking over-privileged OAuth grants — is an underutilised control.
What to review in procurement: OAuth scope requested vs. scope required for the documented feature set. Token rotation and revocation procedures. Whether the vendor supports PKCE and short-lived tokens vs. long-lived refresh tokens.
5. Incident response and breach notification obligations
AI tools process data continuously. A breach at the vendor level — whether through their infrastructure, their subprocessors, or a supply chain compromise — may expose months of customer data. Most vendor DPAs include breach notification timelines of 72 hours (GDPR-minimum), but the practical question is what “notification” means: is it a formal written notice specifying what was compromised, or a generic advisory email?
What to require in contracts: Breach notification within 24 hours of the vendor becoming aware (not 72 hours from discovery, which allows 72-hour delays before the clock starts). Notification content requirements: affected data categories, volume, affected customers, and remediation steps taken. Contractual liability cap sufficient to cover actual damages, not a nominal amount.
The Governance Model
Policy alone does not work for AI tools. The deployment velocity is too high, the tools are too accessible, and business units have strong incentives to move before security can review.
Three controls that work together:
1. Sanctioned tool list with procurement bypass consequences
Publish a list of approved AI tools, refreshed quarterly. Make the procurement process for new tools fast enough (two-week SLA for standard review) that bypassing it is a choice, not a necessity. Treat shadow AI adoption as a policy violation with defined consequences — not to be punitive, but to make the risk visible.
2. Network-level monitoring
Deploy DNS or proxy logging that flags AI service domains. You cannot prevent employees from using personal devices, but you can identify which AI endpoints are being reached from corporate networks and surfaces. Abnormal data volumes to an AI SaaS endpoint are detectable.
3. Quarterly OAuth audit
Schedule a recurring review of OAuth grants across your SaaS ecosystem. Google Workspace and Microsoft 365 both support bulk export of OAuth grants; tools like Nudge Security automate this. Revoke grants to tools that are no longer in active use or have requested excessive scopes.
Contract Language Reference
These clauses address the highest-priority gaps:
Section X.1 — Training Data Exclusion
Vendor shall not use Customer Data, including any inputs submitted by
Customer users and any outputs generated therefrom, for the purpose of
training, fine-tuning, benchmarking, or otherwise improving Vendor's
models, products, or services, or any third-party models or services.
Section X.2 — Subprocessor Notification
Vendor shall provide Customer with at least thirty (30) days' prior
written notice before engaging any new Subprocessor that will process
Customer Data. Customer may object to any new Subprocessor by notifying
Vendor in writing within fifteen (15) days of receiving such notice. If
Vendor proceeds with the new Subprocessor over Customer's objection,
Customer may terminate the Agreement without penalty.
Section X.3 — Security Incident Notification
Vendor shall notify Customer of any Security Incident affecting Customer
Data within twenty-four (24) hours of Vendor becoming aware of such
incident. Initial notification shall include the date and time of
discovery, the nature of the incident, the categories and approximate
volume of Customer Data affected, and the immediate mitigation steps taken.Practical Priorities
If your organisation is starting from a position where AI tool governance is nascent, sequence your effort:
- Inventory first: Use proxy logs, expense reports, and business unit surveys to map what’s deployed. You cannot govern what you cannot see.
- Tier by data sensitivity: Tools that touch source code, financial projections, legal documents, or personal data get rigorous review. Productivity tools that only see meeting transcripts of non-sensitive discussions get a lighter-weight review.
- Retroactively review the top 10 by usage: The highest-usage tools are the highest-exposure tools. Review their contracts against the clauses above and prioritise renegotiation where gaps are significant.
- Build the review process before the next wave: Agentic AI tools — those that can take actions, not just answer questions — are deploying rapidly. The review process you build today needs to scale to cover them.
The foundational principle is straightforward: the data an AI tool processes is yours, and the contract governing that tool should reflect that clearly.