Most B2B SaaS teams evaluating an AI support agent get to the security review late and then watch the deal stall there for a month. The problem is rarely that the vendor is unsafe. The problem is that nobody sent an AI support agent security questionnaire; they sent the standard vendor form, which was written for software that stores records, not for software that reads customer conversations, sends them to a model provider, and clicks buttons in your product on a user's behalf. The questions that matter most for an agent are not on the form, so the review either takes forever or passes without having asked them.

This guide is an AI support agent security questionnaire built for that gap. It covers ten question areas, what a strong answer looks like for each, and what a weak answer looks like, so your security team can run a review that is both faster and more accurate than reusing the generic form. It picks up where our RFP checklist for evaluating an AI support agent leaves off and should run alongside the 30-day pilot, not after it.

What is an AI support agent security questionnaire?

An AI support agent security questionnaire is a structured set of questions a buyer sends to a vendor to establish how the agent handles customer data, which third parties see that data, what the agent is permitted to do, and how misuse is prevented and detected. It extends a standard SaaS vendor security assessment with the areas specific to a system that runs on large language models and takes actions: model providers and subprocessors, training and retention policy, action scope and permissions, prompt injection, and human handoff with an audit trail.

The generic questionnaire asks whether the vendor encrypts data at rest and in transit, has a SOC 2 report, and runs background checks on staff. All of that still applies and you should still ask it. But an AI support agent introduces three things a records-storing SaaS tool does not: a live data flow to one or more model providers on every conversation, a decision layer that can be manipulated by the text it reads, and a set of actions it can take inside your product and your systems. A review that does not cover those three things has not reviewed the agent.

Why is a standard vendor security questionnaire not enough for an AI support agent?

A standard vendor security questionnaire is not enough because it assumes data sits in the vendor's database and is only touched by the vendor's staff and infrastructure. An AI support agent sends conversation content, and often account and screen context, to a model provider on every turn, can be instructed by the content it reads, and can act on connected systems. Those three properties are where the real risk lives and none of them appear on a form designed for a CRM or a file-sharing tool.

Three gaps show up repeatedly when teams reuse the generic form. The subprocessor section expects a hosting provider and an email service, not a model provider that sees the most sensitive content on every turn, so it never asks for the retention window, training terms and region that matter most. The access-control section asks about the vendor's staff, not about what the agent itself is allowed to do in Salesforce or in your billing system. And nothing on the form asks what happens when a customer message or a connected record contains text designed to redirect the agent, because prompt injection is specific to language-model systems and the controls for it are specific too.

The ten question areas for an AI support agent security review

The questionnaire below is organized into ten areas. For each, there is the question to send, what a strong answer looks like, and what a weak answer looks like. Treat areas one through five as gates: a weak answer on any of them should pause the pilot until it is resolved. Areas six through ten are scored and inform the contract, not the go or no-go decision.

1. Data inventory: what does the agent read?

Ask: List every category of data the agent can access to answer or act on a conversation. Include conversation content, user profile and account data, product screen or session context, connected system records, and internal knowledge sources. For each, state whether access is read-only, whether it is sent to a model provider, and whether it is stored by the vendor.

A strong answer is a table, not a paragraph. It names the categories, marks each one as read, sent, or stored, and distinguishes between what the agent can see and what it actually uses by default. It also states what the agent cannot access, which is often more useful than the list of what it can.

A weak answer says the agent "only accesses what it needs" or lists integrations without saying what fields they expose. If the vendor cannot inventory its own data flows, you cannot assess them.

2. Model providers and subprocessors

Ask: Which model providers does the agent use, in which regions, and under what contractual terms? Can the model provider be chosen or restricted by the customer? Provide the full subprocessor list with the purpose of each.

A strong answer names the providers, states the data retention window at the provider (zero retention, a fixed number of days, or indefinite), confirms whether the vendor's agreement with the provider prohibits training on customer data, and says which regions are available. It also explains how the customer is notified if a provider is added or changed.

A weak answer says "we use industry-leading models" without naming them, or names them but cannot produce the retention and training terms. This is the most common failure in AI support agent reviews and the one most worth pushing on.

3. Training and retention

Ask: Is customer data (conversations, account data, knowledge content) used to train or fine-tune any model, by the vendor or by any provider? What is the vendor's own retention period for conversation logs and context, and can the customer set it?

A strong answer separates the vendor's own use from the providers' use, gives a clear no on training unless the customer opts in, and states a retention period with a customer-controlled override. It also covers derived data such as embeddings and evaluation sets, which teams often forget to ask about.

A weak answer says data "may be used to improve the service" or leaves derived data unaddressed.

4. Tenant isolation and access control

Ask: How is one customer's data isolated from another's, in storage, in retrieval, and in the model context? Which vendor staff can access customer conversation content, under what approval, and is that access logged?

A strong answer describes isolation at the storage layer and at the retrieval layer (so one tenant's knowledge base can never be retrieved into another tenant's conversation), describes a break-glass process for staff access with logging and customer notification, and confirms that production access is time-limited and reviewed.

A weak answer covers database isolation only and does not address retrieval, or describes staff access as "restricted to authorized personnel" with no logging detail.

5. Action scope and permissions

Ask: What actions can the agent take in our product and in connected systems? How is the allowed set of actions defined, who approves changes to it, and can a given action require human confirmation before it runs? How are credentials for connected systems stored and scoped?

A strong answer describes an explicit allowlist of actions per connected system, with permissions that can be narrowed below what the integration itself permits, a per-action setting for whether the agent can execute directly or must ask a human first, and credential storage with least-privilege scopes rather than an admin token. It also describes what the agent does when an action fails or returns something unexpected.

A weak answer says the agent "can perform any action the integration supports," or describes permissions at the integration level only, with no per-action control. For an agent that can touch billing, account settings or CRM records, this area is a gate.

6. Prompt injection and tool abuse

Ask: What controls prevent content in a conversation, a document, or a connected record from redirecting the agent's behavior or triggering actions the user did not request? How is this tested, and how are new attack patterns handled?

A strong answer describes multiple layers: separating instructions from untrusted content, restricting which actions can be triggered from which inputs, confirmation steps for consequential actions, monitoring for anomalous action patterns, and a regular adversarial testing program with results the customer can review. It acknowledges that no single control is complete.

A weak answer describes input validation or content filtering as the whole story, or claims the problem is fully solved. Prompt injection is an open research area, and a vendor that says it has eliminated the risk has not understood it.

7. Human handoff and audit trail

Ask: When the agent hands a conversation to a human, what context travels with it? Is every agent response and every action logged with the inputs that produced it? Can the customer export or query that log?

A strong answer confirms a complete, immutable record per conversation covering what the agent read, what it answered, what actions it took and why, and who it handed off to and when, with export available to the customer's own logging or SIEM tooling. The handoff carries the full conversation and the agent's reasoning, so the human does not start from zero.

A weak answer logs only the final messages, or keeps the audit trail in a vendor dashboard with no export.

8. Compliance posture and evidence

Ask: Which audits and certifications does the vendor hold (for example SOC 2 Type II, ISO 27001), and can the full report be shared under NDA? Is a data processing agreement available for GDPR? If the customer handles regulated data such as PHI, will the vendor sign a business associate agreement, and does the model provider's agreement support that?

A strong answer produces the actual report rather than a badge, provides a signable DPA, and gives a clear yes or no on a BAA with the chain of agreements that makes it possible, including the model provider's. For teams in regulated verticals, the PHI section of our healthcare SaaS onboarding guide covers the specific questions to add.

A weak answer lists logos on a trust page without reports, or says a BAA is "available on enterprise plans" without confirming the model provider is covered.

9. Incident response and breach notification

Ask: What is the vendor's incident response process for a data exposure, a model provider incident, or an agent taking an unintended action at scale? What is the notification commitment to customers in hours, and what information is provided?

A strong answer gives a documented process with a named notification window, covers the model provider incident case specifically (since the vendor depends on providers it does not control), and includes an agent-specific scenario such as a bad configuration causing wrong actions across many conversations, with a kill switch to pause the agent.

A weak answer provides a generic incident policy with no agent-specific scenarios and no stated notification window.

10. Data residency, deletion and offboarding

Ask: Where is customer data stored and processed, including at the model provider? Can the customer require a region? On termination, what is deleted, when, and how is deletion verified? What does the customer get back?

A strong answer names the regions for both vendor storage and model inference, confirms a deletion window with a certificate or verifiable confirmation, covers backups and derived data (embeddings, evaluation sets, logs), and offers a full export of conversations and audit logs before deletion.

A weak answer covers vendor storage but not model inference region, or gives a deletion commitment that excludes backups and derived data.

How to run the security review alongside the pilot in two weeks

Run the security review in parallel with the pilot, not before it and not after. Send the questionnaire the week the pilot is scoped, require strong answers on the five gate areas before any real customer data enters the pilot, and use the remaining five areas to shape the contract while the pilot produces its results. Done this way, the review adds about two weeks of elapsed time and almost no delay to the decision.

A workable sequence looks like this.

In the first week, send the ten areas as written, with the strong and weak descriptions removed so the vendor cannot pattern-match. Ask for the subprocessor list, the SOC 2 or equivalent report, the DPA and, if relevant, the BAA position in the same request. Your security lead reviews areas one through five as they come in and flags anything that is a gate.

In the second week, hold one working session with the vendor's security contact and the person who owns the agent's configuration. Walk the data inventory and the action allowlist together, because those are the two areas where written answers are most often technically true and practically misleading. Confirm what the pilot configuration will actually have access to and lock that scope in writing.

At the end of the second week, make the gate decision. If areas one through five are strong, the pilot proceeds with real data under the agreed scope. If any are weak, the pilot proceeds in shadow mode only, with no actions enabled and synthetic or sanitized data, until the gap is closed. Areas six through ten become contract terms: notification windows, deletion commitments, audit log export, and a right to re-review when subprocessors change.

Do not accept a trust page or a badge as an answer to any area; ask for the artifact. And put an annual re-review and a subprocessor change-notification clause in the contract, because an AI support agent changes faster than a records system.

Where Worknet fits in this review

Worknet is an AI support agent that works inside your product and in Slack and Microsoft Teams, answers from your company knowledge, reads screen and account state, and takes permitted actions through API and MCP connections to systems such as Salesforce, Zendesk and HubSpot, with handoff to a human when one should step in. Every one of the ten areas above applies to Worknet, and you should send the questionnaire to us exactly as you would to any other vendor.

Two things about the design are relevant to how the review goes. The configuration is written in plain English by your support or success team, which means the action scope and the knowledge sources the agent uses are visible and editable by the people who own the support process, not buried in a vendor-side setup. And the agent is built to hand off with the full conversation and context rather than drop the user into a fresh queue, which is the behavior area seven is checking for.

Worknet's pricing is quote-based, as is typical for this category, so this post makes no claim about cost or about how Worknet compares on price to any other vendor. The security review is about whether the agent can be trusted with your customers' data and your systems. Ask us the ten questions and judge the answers.

Conclusion

A generic vendor security questionnaire will either stall an AI support agent evaluation or pass it without asking the questions that matter. The ten areas here cover what the generic form misses: what the agent reads, who else sees it, what it can do, how it can be manipulated, and how its decisions are recorded. Run them alongside the pilot, treat the first five as gates, and turn the rest into contract terms.

If you want to see how Worknet answers them, book a demo and bring the questionnaire.