Due diligence for the AI features already inside your SaaS

Most organizations have more AI in production than their inventory shows, and much of it was never purchased. It arrived as a release note: an assistant in the CRM sidebar, a summarize button in the document editor, a reply drafter in the ticketing tool, a recap feature in chat. The vendor is one you approved years ago. The feature changes the risk you approved.

This guide is a playbook for reviewing those features with the same rigor you would apply to a new vendor, without turning it into a six-month procurement exercise. It assumes you cannot inspect the vendor's systems, so the work is asking precise questions, recognizing weak answers, and holding the vendor to the strong ones in writing.

What an embedded assistant changes about a vendor you already approved

An embedded AI feature changes three things at once, and a standard questionnaire usually catches none of them.

• Reach. An assistant typically retrieves across everything the signed-in user can see. Permissions that were loose but harmless when finding a file took effort become a problem when a question returns the answer in seconds.
• Destinations. Prompts and retrieved content go to a model, often operated by a subprocessor you have never assessed, possibly in a region you did not agree to, with its own retention.
• Control. Anyone who can put content into your tenant, such as an external sender, a guest editing a shared document or a customer filing a ticket, can now address instructions to a model that acts for your users.

Consider Halvorsen Freight, a fictional logistics company of 3,000 people. In one month its helpdesk vendor enabled an AI reply drafter, its CRM vendor launched an account-summary assistant, and its document platform added an assistant that answers questions across the whole workspace. None went through review. Two were on by default for all users. The rest of this guide follows Halvorsen's security team through the review it should have done before enablement.

Follow the data through the vendor, hop by hop

Start with the path, because every later question depends on it. Ask the vendor to describe, in writing, each system your data passes through when a user invokes the feature, and what is stored at each step.

There are usually four places a copy can live. App storage holds the feature's outputs, such as summaries and drafts, often as new records with their own retention. Prompt logs hold the assembled prompts, including retrieved content, which the vendor may keep for debugging or quality review. Abuse monitoring is the copy most often missed: model providers commonly keep prompts and outputs for a period to detect misuse, separately from any zero-retention promise for the main path. Subprocessor retention covers whatever the model provider keeps under its own terms.

OWASP's Sensitive Information Disclosure entry recommends clear policies on data retention, usage and deletion, and letting users opt out of having their data used for training [2]. Use it as a floor for what the vendor should be able to state. For Halvorsen, the CRM vendor's answer was clear on app storage and training, silent on abuse monitoring, and named its model provider only in a subprocessor list last updated before the feature launched.

Prompt injection from inside your own tenant

The threat that is new for these features is not the vendor misusing your data. It is outsiders steering the assistant through content that lands in your tenant. Indirect prompt injection occurs when a model takes in content from external sources, such as websites or files, that contains instructions [1]. In a SaaS tenant, those sources include inbound email, shared documents, ticket bodies, calendar invitations and chat messages from external guests.

The canonical example is CVE-2025-32711, published by NVD in June 2025 and widely known as EchoLeak. Its description reads: “AI command injection in M365 Copilot allows an unauthorized attacker to disclose information over a network” [3]. Microsoft, the reporting authority, scored it 9.3 critical, and NVD tags it as affecting an exclusively hosted service, meaning the fix was made in Microsoft's service rather than by customers applying a patch [3]. The point for due diligence is not that one product had a flaw. It is that an assistant with broad reach, untrusted input in the same context and a way to send output elsewhere forms an exfiltration path, and only the vendor can close it.

So ask what the vendor does about it, specifically. Does it mark retrieved content as untrusted and separate it from the user's request? Does it restrict links and images in the assistant's output, which can carry data to outside servers when rendered? Can the assistant take actions such as sending mail or sharing files, and does a person confirm them? How does the vendor test for injection, and how does it handle reports? A vendor that answers only that its model is aligned to refuse malicious requests has not answered the question.

The question set: good answers and red flags

Send these questions as a short addendum to your standard questionnaire, scoped to the specific AI feature. Ask for answers in writing and for documentation links, not for a call.

Grade the answers, not the questionnaire

A completed questionnaire tells you the vendor responded. It does not tell you whether the answers are good enough to enable the feature for people who handle sensitive data. Grade the four answers that decide the most on a three-step scale, and make enablement depend on the grade. On training use, a vague statement that the vendor may use your data is a red flag, an available opt-out is acceptable, and a contractual never is strong. On retention, an undefined period is a red flag, a fixed window for abuse-monitoring copies is acceptable, and zero retention or a period you set is strong. On subprocessors, the progression runs from unnamed industry leaders to a named list to a named list with regions and change notice. On admin controls, it runs from on for everyone to an org-wide off switch to scoping per group and per data type.

A simple rule works: any red flag means the feature stays off for groups that handle restricted data until it is resolved. All acceptable means a scoped rollout with logging. Strong answers on training use and retention are the minimum before the feature reaches anyone who handles customer personal data. At Halvorsen, the document assistant earned strong answers on admin controls and training use but a red flag on retention, so it was enabled for marketing and kept off for finance and legal pending a contract change.

Admin controls and audit logs to require before enablement

Treat enablement as a configuration change you own, not a vendor decision you inherit. Before broad rollout, confirm the following, and test each one rather than relying on documentation.

1. Turn the feature off tenant-wide, then enable it for a pilot group. Confirm users outside the group cannot invoke it through any surface, including mobile apps and integrations.
2. Exclude sensitive sources, such as HR folders, legal workspaces and executive channels, and confirm with a test question that the assistant cannot retrieve from them.
3. Disable web grounding, third-party plugins and connectors unless there is a specific need, because each adds inputs and destinations.
4. Fix the oversharing the assistant will expose. Run a permissions review of the pilot group's accessible content first; the assistant makes existing access mistakes faster to exploit.
5. Confirm audit events for invocation, retrieved sources and actions reach your SIEM, and write one detection: assistant output containing an external link or image in response to content from outside the organization.
6. Set a review trigger. A vendor release that adds a new AI capability reopens the review for that capability.

To verify the injection controls rather than take them on faith, send a test email or share a test document into the pilot tenant containing a benign, clearly labeled instruction, such as asking the assistant to append a fixed phrase to its summary. If the phrase appears, the vendor's separation of content from instructions is weaker than described, and you have a concrete finding to raise.

Put the answers in the contract

A vendor's documentation can change without notice; a contract cannot. NIST SP 800-161 treats supply chain risk as something to identify, assess and mitigate throughout the life of a product or service [4], and the NIST AI RMF calls for policies and procedures that address AI risks from third-party entities [5]. Both point the same way: the due-diligence answers should become obligations.

• Customer data, prompts and outputs will not be used to train or improve any model, including by subprocessors, without written consent.
• The vendor will list all AI subprocessors and processing regions and give advance notice of additions or changes, with a right to object.
• Retention periods for prompts, outputs and abuse-monitoring copies are stated, and deletion on request covers every copy.
• New AI capabilities are delivered off by default for this tenant, or with advance notice before default enablement.
• Security incidents involving AI features, including data exposure through prompt injection, fall under the standard notification terms.
• Audit logs for AI feature use are available for export for the agreed retention period.

Expect some resistance on default-off and advance notice; vendors ship AI features frequently. A reasonable compromise is a tenant-level setting that holds new AI capabilities off until an admin enables them; ask whether one exists before you ask for a contract clause. If a vendor will commit to none of these, record that as an accepted risk with a named owner, and limit the feature's scope accordingly.

Where a runtime gateway helps, and where it cannot

Be clear about the boundary: AI calls a SaaS vendor makes inside its own service do not pass through your gateway, so the vendor's controls and your contract carry that risk. A gateway helps around the edges you do control. Intertrace's read-only discovery reports identity-provider AI-app grants and AI usage in your repositories, which surfaces embedded features and connected AI apps you have not reviewed. When your own agents read from or write to SaaS systems through MCP or APIs routed through Intertrace, PII and secrets detection applies to the requests, responses and tool-call arguments, and outbound messages ask a person before they are sent. Each decision is a structured event you can export to your SIEM alongside the vendor's audit logs.

What to do this quarter

1. Build the list. Read the last two quarters of release notes for your top twenty SaaS vendors and combine them with discovery of AI-app grants. Record every AI feature, whether it is on, and for whom.
2. Turn off by default anything enabled for groups that handle restricted data and not yet reviewed, and tell those groups why and when it will be reviewed.
3. Send the question set as an addendum, scoped to each feature, and grade the four deciding answers.
4. Run the benign injection test in a pilot tenant for each assistant that reads external content.
5. Wire audit logs to your SIEM and write the external-content-to-external-link detection.
6. Raise contract amendments at the next renewal, starting with training use, subprocessor notice and retention, and record accepted risks with owners where vendors decline.