Playbook

Selling AI agents to enterprise buyers

Somewhere between your first logo and your fifth, a security questionnaire arrives. Most of it is the standard vendor review every SaaS company answers. A growing section of it is not, and that section is about agents specifically — what yours can do, on whose authority, and what you can prove afterwards.

The short answer: the classic vendor-review questions (encryption, access control, subprocessors, incident response, an attestation) still apply and are table stakes. The new ones are about autonomy and provenance: what can the agent do without a human, what happens when it reads hostile input, whose credentials does it act on, and can you produce a record of what it did. Answer those four before the call and the review shortens from weeks to days.

The part that has not changed

You will still be asked for encryption at rest and in transit, role-based access control, an SSO story, your subprocessor list, data-retention and deletion terms, an incident-response process with notification timelines, business continuity, and a compliance attestation — most commonly SOC 2 Type II, sometimes ISO 27001, and in health or public sector something more specific.

Two practical notes. A Type II report covers a period, so the clock starts when your controls do — beginning that process the month a deal appears is already late. And the subprocessor list is where AI vendors trip: every model provider, every inference host and every tool your agents call is a subprocessor, and a buyer who finds one you did not list stops trusting the rest of the document.

The four questions that are actually about agents

1. What can it do without a human?

This is the first question a competent reviewer asks, and a vague answer ends the conversation. What they want is a boundary they can read: which categories of action execute autonomously, which wait for approval, who can change that setting, and whether the change is logged.

The strong answer is a boundary drawn around irreversibility — sending, paying, publishing, deleting, granting access — with everything upstream running unattended. It is strong because it is a rule rather than a list, so it still holds for a capability you ship next quarter. Approvals and trust is the long version.

2. What happens when it reads something hostile?

Reviewers have caught up on prompt injection, and the wrong answer is "we filter for it". OWASP's 2026 position is that no reliable prevention mechanism exists, and a reviewer who knows that will read a prevention claim as either naivety or marketing.

The credible answer is containment: each agent holds only the tools its job needs, credentials never enter the model's context, the agent that reads untrusted content is not the agent that can send or spend, and outbound reach is constrained. Say the limitation out loud and then describe the bound — that is what a security team is actually assessing. Detail in the containment checklist.

3. Whose credentials is it acting on?

If your agent holds one service account for every customer, expect a hard stop. What a buyer wants is per-tenant, per-agent scoping, secrets held by the runtime rather than pasted into prompts, and a clear statement of who inside your company can read them. "Encrypted at rest" is necessary and does not answer the question — the question is who holds the key and under what process.

4. Can you show what it did?

An action log, not a chat transcript: what the agent did, in which system, at whose instruction, with what result, retained for a stated period and exportable. This is the one that cannot be retrofitted — a system that never recorded approvals cannot be made to have recorded them — and it is increasingly a regulatory requirement rather than a preference. See the EU AI Act and AI agents.

The questions behind the questions

Three more turn up once the reviewer is satisfied on the basics, usually from legal or procurement rather than security:

  • "Is our data used to train anything?" A yes-or-no with the model provider's terms attached. Anything hedged reads as yes.
  • "Where does this run?" Increasingly a hard requirement rather than a preference, and the answer has four parts, not one — data at rest, the inference call, the credentials, and the agent's accumulated memory. Where your agents actually run covers the shape of a complete answer.
  • "What is your AI governance policy?" A real question now, not a formality, and in regulated buyers it is often mapped to a framework. A short, honest document beats a long aspirational one, because the reviewer will test whether your product matches it.

What to have ready before the first call

  1. A one-page agent security summary covering the four questions above. Most of the questionnaire is answerable from it, and volunteering it early changes the tone of the review.
  2. A subprocessor list that is actually complete, model providers included.
  3. An architecture diagram showing where customer data goes, with the model call drawn explicitly. Reviewers look for that line and get suspicious when it is missing.
  4. Your attestation, or a dated plan to get one. "In progress, audit window opens in March" is a workable answer. "We take security very seriously" is not.
  5. A DPA you have actually read, including whatever it says about automated decision-making.

The trap worth naming

Startups selling agents tend to describe autonomy as the product — the agent does it all, nobody has to check. To an enterprise reviewer that is not a feature description, it is a risk disclosure, and it converts a routine review into an escalation.

The same capability lands completely differently when it is framed as a boundary you control: the agent handles the reversible work unattended, anything consequential waits for your team, you set where that line sits, and every action is recorded. Identical software, and one version closes.

Related reading

FAQ

What do enterprise buyers ask about AI agents specifically?

Four things beyond the standard vendor review: what the agent can do without a human, what happens when it reads hostile input, whose credentials it acts on, and whether you can produce a record of what it did. The classic questions about encryption, access control, subprocessors and incident response still apply on top of those.

Do I need SOC 2 to sell AI agents to enterprises?

Usually yes, or a credible dated plan to get one. A Type II report covers a period of operation rather than a moment, so the clock starts when your controls do — beginning the process once a deal is already in play is late. Some buyers accept ISO 27001, and regulated sectors may require something more specific.

How should I answer a prompt injection question in a security review?

Not with a prevention claim. OWASP's 2026 position is that no reliable prevention mechanism exists, and a reviewer who knows that will read a prevention claim as naivety or marketing. Describe the containment instead: least-privilege tools per agent, credentials never in the model's context, separation between the agent that reads untrusted content and the agent that can act, and constrained outbound reach.

Are model providers subprocessors?

Yes. Every model provider, inference host and third-party tool your agents call belongs on the subprocessor list. This is a common omission for AI vendors, and a buyer who discovers an unlisted one tends to stop trusting the rest of the document.

How should a startup describe agent autonomy to an enterprise buyer?

As a boundary the customer controls, not as the absence of human involvement. "The agent handles reversible work unattended, anything consequential waits for your team, you set where that line sits, and every action is logged" describes the same software as "it does everything on its own" — but the first passes review and the second triggers an escalation.

Answer the four questions on day one

Per-agent credential scoping, an approval boundary around anything irreversible, and an exportable record of every action — the things a reviewer asks for, in place before they ask.

Start a deployment