Shipping AI Agents? The 5 Security Questionnaire Questions Your First Enterprise Buyer Will Ask

The champion at your first big customer loves the product. The pilot went well. Then an email arrives from someone you haven’t met, in a department you didn’t know existed, with a spreadsheet attached. It’s the security questionnaire, and it has about a hundred questions.

A founder on Hacker News described the moment well, three years before agents made it harder:

"Whenever we get a client with around 100+ head count, they ask to fill their own security assessment. It takes a lot of time as it has sometimes 100+ questions. We can't also deny them, but we're getting tired."

make_it_sure, in Ask HN: How small startups deal with long security questionnaires from clients?, June 2023

The top reply is the best advice we’ve read on the subject, from someone who ran sales at a startup:

"...it was a huge competitive advantage to have someone who knows their stuff (a founder who wrote most of our code) complete them fast and get them back. It's competitive out there. Using an advantage to your company's benefit as a founder is your job - not work that is beneath you."

BlueTie, replying on Hacker News, June 2023

We agree, and for a company shipping AI agents it’s even more true. Most of those hundred questions are standard: multi-factor authentication, encryption, backups, vendor management. We covered the common traps in Enabled Isn’t Enforced. But five questions will decide the deal, because they’re about what makes your product different from the software the buyer has bought before. They’re also the five where the founder’s own voice is the strongest answer you have.

The short answer

For a Series A company shipping agents, the five questions that matter most are:

1. Do you train on our data, and where does it go? They’re asking whether their data becomes someone else’s model, and who else touches it.
2. What can your agent do in our environment, and on whose authority? They’re asking how much of their authority you’re borrowing, and where it stops.
3. How do you keep prompt injection from turning your agent against us? They’re asking what happens when your agent reads text an attacker wrote.
4. Can we see what the agent did, and can we stop it? They’re asking whether they can investigate without you, and how fast it stops.
5. When something goes wrong, who tells us, how fast, and who’s accountable? They’re asking whether you’ll call them before they find out.

A strong answer to each one has three parts: a plain sentence that matches your contract, the design choice that makes it true, and evidence they can check. When the honest answer is “not yet,” a dated plan beats a confident paragraph every time. The builder below drafts all five from your situation.

Why the first questionnaire is different when you ship agents

Three things have changed, and each one is a reason to answer these five with more care than the rest of the spreadsheet.

The questionnaire arrives earlier. SecurityPal, which processes questionnaires for vendors, now sees them arriving “before vendors are even shortlisted” (SecurityPal). Your answers aren’t paperwork after the decision anymore. They’re part of the decision.

The questions moved from promises to proof. SecurityPal summarizes the change in two sentences buyers actually wrote: in 2024 they asked “Can we opt out of AI?” and in 2025 they asked “Can you prove our data never trains your models?” (SecurityPal). The standard question banks have caught up too. In July 2025 the Cloud Security Alliance published its AI Controls Matrix, 243 controls across 18 domains, with a companion self-assessment questionnaire built on it (Cloud Security Alliance). Expect questions drawn from it.

Someone you’ll never meet has to defend you. Your champion forwards your answers to a security team, a privacy team and sometimes legal. Edelman and LinkedIn’s 2025 research on these “hidden buyers” notes that more than 40 percent of B2B deals stall because people inside the buying group can’t agree (Edelman). A questionnaire is how the security team decides whether to lend you its reputation. Jon describes the buyer’s side this way: they’re “protecting their reputations in their organizations, they’re going to look for the least risky.”

Underneath those changes is one principle worth holding onto while you write: each of the five questions maps to a property that makes agents different from ordinary software. Agents work with the buyer’s data (question 1). They act with borrowed authority (question 2). They read content that anyone, including an attacker, can write (question 3). They act at machine speed, often without a person watching each step (question 4). And when they fail, the failure lands on the buyer before it lands on you (question 5). Answer the property behind each question and your answers will hold up when the follow-ups come.

1. Do you train on our data, and where does it go?

What they’re really asking. Will our data become part of a model someone else benefits from? Who else touches it, in which country, and for how long? The buyer’s data is the buyer’s liability. If you send it to a model provider, that provider becomes your sub-processor, which makes it theirs too.

Why it’s asked now. It’s the most common AI question in the market. Conveyor, whose AI has helped vendors answer more than 750,000 security and compliance questions, lists “Are you using our (customer) data to train or fine-tune AI models?” among the top AI questions B2B companies get, followed by “If yes, can we opt out and how do you ensure no unauthorized re-use of data?” (Conveyor). The shift from opt-out to proof is the part to plan for.

What a strong answer includes.

• One sentence about training that matches your contract word for word. If your data processing agreement says you don’t train on customer data, say exactly that. If a feature does learn from customer data, say which feature, whether it’s opt-in, and what it learns.
• Every model provider you use, what each one receives, the region it’s processed in and how long it’s kept.
• The provider terms and settings that apply, quoted or linked, such as API terms that exclude training and any zero-retention arrangement you actually have.
• Your own retention for prompts, outputs, embeddings and logs.

A sample answer, in a founder’s voice (swap in your own facts):

“We don’t use customer data to train or fine-tune models, ours or anyone else’s, and section 4 of our data processing agreement says so. To answer requests, we send the minimum text needed to one model provider, listed on our sub-processor page with its region, under API terms that exclude training. We keep prompts and outputs for 30 days to investigate issues, then delete them. The attached diagram shows every place your data goes.”

Evidence to attach: the data processing agreement with the clause highlighted, your sub-processor list, a one-page data flow diagram and your retention table.

If the honest answer is “not yet”: the usual gap is an incomplete sub-processor list or a retention period nobody wrote down. Both are a week of work. Send the answer with “our updated sub-processor list will be published by” and a real date, then send the link when it’s live.

2. What can your agent do in our environment, and on whose authority?

What they’re really asking. How much of our authority are you borrowing, and where does it stop? Which identity does your agent act as? Can it read, write, send, delete or pay? Can one customer’s agent touch another customer’s data? Which actions need a person to approve them?

Why it’s asked now. Agents moved from answering questions to taking actions, and buyers have watched integrations become the way in. When attackers stole the OAuth tokens behind Salesloft’s Drift chat agent in 2025, they used them to export data from many companies’ Salesforce instances (Google Threat Intelligence Group). A TechTarget guide for enterprise buyers published in July 2026 puts “agent permissions, authority and decision boundaries” first on its list of questions to ask vendors (TechTarget).

The principle. Least privilege is older than agents, but agents act at machine speed on someone’s behalf, so the scope you request is the risk you’re asking them to accept. Chris Kirschke, who spent 27 years in security operations, has enabled write access on a production system exactly once, which he told us about on episode 102 and we wrote up in Are You Actually Going to Give the Agent Write Access?. Your buyer’s security team thinks the same way.

What a strong answer includes.

• A permission matrix: each action the agent can take, whether it reads or writes, and whether it needs approval.
• The exact OAuth scopes or API permissions you request, and how a customer can narrow them.
• How credentials are separated: one credential per customer and per agent, never a shared key. We made the case in Your Agents Share One API Key.
• Which actions always need a person, and who that person is on the customer’s side.
• How a customer turns the agent off for their account.

A sample answer, in a founder’s voice:

“Our agent reads tickets and drafts replies in your help desk. It can’t send, close or delete anything without an approval from someone on your team. It acts through an OAuth app with the four scopes listed in the attached matrix, and each customer gets its own credentials, so one customer’s agent can’t reach another’s data. Your admins can narrow the scopes or turn the agent off for your whole account from the settings page.”

Evidence to attach: the permission matrix, the scope list, an architecture diagram showing tenant separation and, if you have one, the summary of an AI access control audit.

If the honest answer is “not yet”: if your agent requests broad scopes because they were easier during the pilot, narrow the defaults before you answer. If you’re on a shared key, say when per-customer credentials ship.

3. How do you keep prompt injection from turning your agent against us?

What they’re really asking. Your agent reads our email, our tickets, our documents and the web. What happens when some of that text was written by an attacker, and it tells your agent to do something we never asked for?

Why it’s asked now. Because it works. Simon Willison named the dangerous combination in June 2025: an agent with access to private data, exposure to untrusted content and the ability to communicate externally can be tricked into stealing that data (Simon Willison).

If you use "AI agents" (LLMs that call tools) you need to be aware of the Lethal Trifecta

Any time you combine access to private data with exposure to untrusted content and the ability to externally communicate an attacker can trick the system into stealing your data!

Simon Willison (@simonw) · June 16, 2025

Three months later, Noma Security showed it against a major platform: hidden instructions in a web form’s description field led Salesforce’s Agentforce to send lead data to a domain that was still on Salesforce’s allowlist but had expired, which the researchers bought for five dollars. Salesforce fixed it by enforcing trusted URL allowlists (The Register). On episode 106, Jesse Anglen, the founder of Ruh.ai, described the simplest version: a line of fine print on a web page telling any agent that reads it to grab its credentials and email them away.

The principle. Instructions and data travel in the same channel, so no filter catches every injection. Willison’s own warning is the right standard for your answer: “we still don’t know how to 100% reliably prevent this from happening,” and “in web application security 95% is very much a failing grade.” That changes what a strong answer is. It doesn’t promise detection. It describes containment: the design that limits what an injected instruction could do. Meta’s Agents Rule of Two turns that into a rule you can cite: within a session, an agent should have no more than two of three properties, processing untrustworthy inputs, access to sensitive systems or private data, and the ability to change state or communicate externally (Meta). We walked through it in The Human in the Loop Is Going Away.

What a strong answer includes.

• An honest first sentence: no system filters out every injection, so you designed for containment.
• The design choice: which of the three ingredients you removed or separated for each workflow. For example, the agent that reads outside email can’t send email, and the agent that can send can’t read outside content.
• Outbound limits: allowlisted destinations, no rendering of untrusted links or images that could carry data out.
• Approvals for consequential actions, scoped so people actually read them.
• Testing: the date of your last adversarial test or AI penetration test, what it found and what you fixed.

A sample answer, in a founder’s voice:

“No one can filter out every prompt injection, so we designed for containment. The part of our agent that reads your customers’ messages can’t call external URLs or send anything; replies go through a separate step that only drafts, and a person on your team approves every send. Outbound requests are limited to an allowlist of three domains. We test this adversarially every quarter. The last AI penetration test was in September; it found two issues, both fixed within a week, and the letter is attached.”

Evidence to attach: a short threat model, the AI penetration test or red team letter, and a summary of the evaluation you run on every release. Our AI red teaming and penetration testing teams produce exactly this kind of letter.

If the honest answer is “not yet”: if you haven’t tested adversarially, schedule it before you answer and put the date in the response. A dated test on the calendar reads very differently from silence.

4. Can we see what the agent did, and can we stop it?

What they’re really asking. If something looks wrong at 2 a.m., can our team investigate without waiting for you? Is there a record of what the agent did, with which inputs and which tools, on whose behalf? And how fast can we make it stop?

Why it’s asked now. Because approvals alone haven’t held up. Yash Kosaraju, the CISO of Andreessen Horowitz (a16z), explained why on episode 104: the perceived defense is a prompt asking whether you accept an action, but “after the third click you don’t really read what’s in there, and you just start clicking through.” Buyers want a record they can replay and an off switch they can reach. The same TechTarget guide lists “AI auditability and traceability” and “human oversight and escalation requirements” among the core questions.

The principle. You can’t defend what you can’t replay. Logs are how a buyer’s security team checks your story without having to trust it, and a fast stop in the customer’s hands is what makes a mistake small.

What a strong answer includes.

• What you log for each agent action: the time, the customer and user it acted for, the inputs it read, the tools it called, what it changed and who approved it.
• How long you keep those logs, and how customers get them: an export, an API or a feed into their security monitoring.
• The stop: who can pause the agent for an account, how fast it takes effect and what happens to work in progress.
• How you keep approvals meaningful: fewer, clearer prompts for the actions that matter.

A sample answer, in a founder’s voice:

“Every action the agent takes is logged with the time, the user it acted for, the documents it read, the tools it called and the approval, if one was required. We keep those logs for a year, and your admins can export them or stream them to your security tools. Any admin can pause the agent for your whole account from the settings page; it takes effect within a minute, and in-progress drafts are held, not sent. A sample log entry is attached.”

Evidence to attach: a sample log entry with the field list, your log retention policy, a screenshot of the admin settings and the runbook for an emergency stop.

If the honest answer is “not yet”: a per-customer pause and a CSV export of agent actions are usually the two fastest things to build, and they answer most of this question. Say when they’ll ship.

5. When something goes wrong, who tells us, how fast, and who’s accountable?

What they’re really asking. If your agent, your model provider or your integration is part of an incident, will you call us before we find out some other way? Who is the person? How many hours? What changes if you swap the model underneath us?

Why it’s asked now. Buyers have watched agent integrations become shared incidents. The stolen Drift tokens potentially affected at least 700 organizations (Atlanta Journal-Constitution), and Cloudflare, one of them, published its own customer notification and the 104 API tokens it rotated (Cloudflare). Your buyer’s security team is picturing that week with your product in the middle of it.

The principle. Buyers aren’t buying a model. They’re buying a counterparty. The question behind the question is whether you’ll be a good one on your worst day. That’s why this answer should have names and numbers in it, and why we built Who Signs for the Agent?, a one-page accountability map for exactly this section of the questionnaire.

What a strong answer includes.

• Your incident response plan, with scenarios specific to agents: a prompt injection that caused an action, data exposed through a model provider, an agent taking unintended actions at scale and a compromised integration.
• Your notification commitment in hours, and where it’s written in the contract.
• A named security owner and a named backup.
• How you handle model and provider changes: notice to customers before you swap the model or provider that processes their data.
• Your insurance, and what it covers.

A sample answer, in a founder’s voice:

“Our head of security owns incident response, with our CTO as backup, and both are named in the attached plan. We’ll notify you within 48 hours of confirming an incident that affects your data, as our agreement states, and sooner when we can. The plan covers agent-specific scenarios, including prompt injection and a compromised integration, and we last ran a tabletop exercise on it in August. We give customers 30 days’ notice before changing the model provider that processes their data.”

Evidence to attach: the relevant pages of your incident response plan, the notification clause, your change notice policy, the date of your last tabletop exercise and your certificate of insurance.

If the honest answer is “not yet”: name the owner today, add the notification clause to your standard agreement, and run a one-hour tabletop on the agent scenarios this month. All three fit in a week, and our blast radius playbook has the first hours mapped out.

Build your five answers

Pick where you are for each question and add the details you know. The builder drafts an answer in a founder’s voice, lists the evidence to attach and, where the honest answer is “not yet,” writes a dated plan you can paste into the response. Treat the drafts as a starting point: change every sentence that isn’t exactly true for you.

Interactive · 10 minutes · Runs in your browser

The five-answer builder

For each question, choose the status that's honestly true today and fill in what you know. The drafts update as you go.

The builder needs JavaScript. The five questions, strong answers and evidence lists are written out above.

Load an example company Start over

…where you stand

…answers with evidence

…partly there

…dated plan items

Copy all five answers Download (.md) Print

Everything here runs in your browser and is saved only in this browser. The drafts are a starting point; send only what's true for your company.

Have an operator review my answers →

We get your email and the status you picked for each question, never the details you typed. Jon or Sasha replies to set up a review of your real questionnaire. No sequence.

How to send it

How you send the questionnaire matters almost as much as what’s in it. A few habits make a big difference for a young company.

Send it fast, and send it complete. BlueTie’s advice holds: speed is an advantage, and a founder who knows the product can be fast. Complete beats perfect. A response with five clear agent answers, honest “not yet” items with dates and the evidence attached will move further than a perfect answer that arrives three weeks later.

Write a short cover note in your own voice. Three or four sentences from the founder: who owns security, what you invested in early and why, and an offer of a call. It’s the part of the response that can’t be copied from anyone else’s, which is the same reason founder stories stand out in our own market.

Offer one call between security people. Thirty minutes between your security owner and theirs resolves more follow-ups than a week of email. If you don’t have a security owner yet, that’s one of the things an on-demand team is for: our partners bring their YSecurity lead to exactly these calls.

Check before you send. Read every “yes” against the system it describes, because enabled isn’t the same as enforced. Our pre-send answer check is built for that. If the buyer sent a due diligence questionnaire rather than a security one, What Is a DDQ? explains the difference.

Keep the answers alive. Agent products change fast. When you change a model provider, a scope or a retention period, update the answer and tell customers who received the old one. A trust center page with current answers saves you from rewriting them for every buyer.

And if your SOC 2 report just landed, the buyer’s next questions are in The Week After Your SOC 2 Report Lands. If you’re retiring agents as you go, Wednesday’s AI agent offboarding checklist gives you the record buyers ask for when they get to question 2.

For all ten AI questions we expect from enterprise buyers in 2027, plus the extra ones healthcare, insurance, legal, finance and defense buyers add, see The 10 AI Security Questions Your First Enterprise Buyer Will Ask in 2027, with a one-sentence answer for each.

Your first enterprise questionnaire is a chance to show a security team that you understand what you built. Answer the five questions about agents in your own voice, with evidence, and with dates where you’re not there yet. That combination is rarer than it should be, and buyers notice.

Jon and Sasha