How to Build a Security Questionnaire for Buying AI Agents (Without Recycling Your SaaS Template)

Table of Contents

• Why Your Existing Vendor Questionnaire Fails for Agents
• The Five Domains Every Agent Questionnaire Must Cover
• Identity and Authentication: Who Is This Agent, Really?
• Permissions and Blast Radius
• Observability, Audit, and Forensics
• Control: Kill Switches and Human Override
• Data Handling, Memory, and Training
• Scoring the Answers: A Practical Rubric
• Insights Most People Overlook
• References

Why Your Existing Vendor Questionnaire Fails for Agents

I've watched procurement teams paste a SOC 2 attestation request and a 200-row spreadsheet at a GaaS startup, get back a polished PDF, and call it a day. Then six weeks later the agent quietly emails a customer list to the wrong distribution because someone phrased a request ambiguously. The questionnaire never asked the question that mattered.

Traditional vendor security questionnaires were built around a clear mental model: the vendor stores your data, runs some code, and exposes an API or a dashboard. The threat surface is mostly about where the data sits and who can reach it. That model breaks the moment you buy an agent, because the agent is an actor. It reads context, decides, and then does things in systems you care about, sending email, moving money, updating records, calling other APIs.

That shift introduces failure modes a SaaS questionnaire was never designed to catch. A logging tool doesn't get prompt-injected into exfiltrating data. A CRM doesn't become a "confused deputy" that uses its own elevated permissions on behalf of an attacker who tricked it. The OWASP Top 10 for LLM Applications exists precisely because these categories didn't fit the old frameworks. If your questionnaire doesn't have a section that maps to those risks, you're assessing the wrong product.

So the goal here isn't to throw out your existing process. It's to bolt on the agent-specific questions, and, more importantly, to know what a good answer looks like, because vendors have gotten very good at writing confident non-answers.

The Five Domains Every Agent Questionnaire Must Cover

Before the specific questions, anchor on the structure. Every agent security questionnaire should interrogate five domains, in roughly this priority order:

1. Identity, how the agent authenticates as a distinct, non-human actor.
2. Permissions, what it can touch, and how tightly that's scoped.
3. Observability, whether you can reconstruct what it did and why.
4. Control, how you stop it, override it, and recover from a bad run.
5. Data, what it remembers, where that lives, and whether it trains on you.

Notice what's not at the top: encryption-at-rest, password policies, the boilerplate. Those still belong in the questionnaire, but for an agent they're table stakes, not differentiators. The hard part is the five domains above, and they're where vendors are weakest. Let's take them in turn.

Identity and Authentication: Who Is This Agent, Really?

The first question I'd put on any agent questionnaire is deceptively simple: does the agent have its own identity, or does it borrow a human's?

This matters more than almost anything else. If the agent acts under a shared service account or a human user's OAuth token, you've lost the ability to attribute actions, scope permissions, or revoke access without collateral damage. When something goes wrong at 2 a.m., "the agent did it" needs to resolve to a specific, traceable principal, not "well, it was using Dave's credentials."

Concrete questions to ask:

• Does each agent (or agent instance) get a unique, machine identity, and what standard is it built on? You want to hear something like workload identity, SPIFFE/SPIFFE-style identities, or OAuth client credentials with per-agent scoping, not "it uses our platform API key."
• How are the agent's credentials issued, rotated, and revoked? Short-lived tokens are a strong signal; long-lived static keys baked into config are a red flag.
• Can you revoke a single agent's access without taking down the whole fleet?
• How does the vendor prevent credential theft via prompt injection? An agent that can be talked into revealing its own secrets is a breach waiting to happen.

The non-human identity problem is genuinely unsolved at the industry level, there's no universal standard yet for authenticating an autonomous actor the way we have for humans and traditional services. NIST's work on zero trust architecture is the closest reference frame, and a credible vendor will be able to talk about how they apply those principles to agents specifically. A vendor that gives you a blank stare here hasn't thought about the single most important question.

Permissions and Blast Radius

Once you know who the agent is, the next question is what it can do, and crucially, what's the worst it can do if it's compromised or simply wrong.

This is the blast-radius question, and it's where least-privilege design earns its keep. A well-built agent has narrowly scoped, purpose-specific permissions: the invoice-processing agent can read invoices and draft payment records, but it cannot actually release funds, and it certainly cannot read HR files. A poorly built one gets handed broad API access because that was easier to ship.

Ask:

• What is the complete list of tools, APIs, and systems this agent can access? Make them enumerate it. Vagueness here ("it integrates with your stack") is itself the answer.
• Are permissions scoped per-task or granted broadly at deployment? Per-task scoping, where the agent only holds the permission it needs for the action in front of it, is the gold standard.
• Which actions require human approval before execution, and is that configurable by us? Money movement, external communication, and destructive operations should be gateable.
• How does the platform prevent the "confused deputy" problem, where the agent's legitimate permissions get exploited to do something the requester couldn't do directly?
• Can we set hard limits, spend caps, rate limits, allow-lists of recipients?

The instinct to over-grant permissions is the original sin of agent deployment, and it's the same mistake that haunted RPA bots a decade ago. If a vendor can't show you a granular permission model, assume the agent runs with more access than you'd ever sign off on if you saw the full list.

Observability, Audit, and Forensics

Here's a scenario worth sitting with: your agent took an action three weeks ago that a regulator is now asking about. Can the vendor tell you exactly what the agent did, what inputs it saw, what reasoning it followed, and what tools it called, and can they hand you that record in a format you can actually use?

For a lot of GaaS products, the honest answer is no. And that's a problem, because when an agent is involved, "we have logs" is not the same as "we can reconstruct the decision."

What to require:

• Immutable, tamper-evident audit logs of every agent action, including the prompt/context, the tools invoked, and the outputs.
• Logs that capture the reasoning trace or decision rationale, not just the final action. The forensic value of "the agent transferred $40,000" is near zero without "...because it interpreted this email as an approved invoice."
• Log retention that meets your regulatory requirements, and the ability to export logs into your own SIEM.
• Clear answers on who at the vendor can access these logs and how that access is itself audited.

Gartner has been blunt that the governance and observability gap is the leading thing holding back enterprise agent adoption, and it shows up most painfully during incidents, when nobody can explain what happened. Treat audit depth as a first-class buying criterion, not a compliance afterthought. The questions you ask here directly determine whether you can investigate an agent's decision when you eventually need to.

Control: Kill Switches and Human Override

Every autonomous system needs a stop button that works. Sounds obvious. In practice, "stop" is harder than it looks, because an agent might be mid-workflow, holding state, with a half-completed transaction and three downstream systems already touched.

The questionnaire needs to push hard here:

• Is there a kill switch that immediately halts a single agent, a class of agents, or the entire fleet? How fast does it take effect?
• When an agent is stopped mid-task, what happens to in-flight actions? Are they rolled back, left in place, or queued? You need to know whether stopping creates its own mess.
• Can we set circuit breakers, automatic halts triggered by anomalous behavior, spend thresholds, or error rates, without calling the vendor's support line?
• Who has the authority to invoke an emergency stop, on our side and theirs?
• Is there a documented incident playbook for an "agent acted without authorization" event?

A vendor that treats the kill switch as a checkbox ("yes, we have one") rather than a designed capability with defined semantics is telling you they haven't war-gamed the failure. Designing emergency stops for autonomous agents is genuinely hard engineering, and the maturity of a vendor's answer here is one of the cleanest signals of how seriously they take safety.

Data Handling, Memory, and Training

Agents have memory, sometimes persistent, sometimes per-session, sometimes shared across customers in ways that aren't obvious from the marketing page. That memory is a data-governance surface most questionnaires miss entirely.

Ask:

• Does the agent retain memory across sessions or tasks? Where is that stored, for how long, and can we purge it on demand?
• Is our data used to train or fine-tune any model, the vendor's or a third party's? Get this in writing, contractually, not as a verbal assurance.
• When the agent calls an underlying foundation model (OpenAI, Anthropic, etc.), what data leaves your environment, and what are that provider's retention terms? You're inheriting a sub-processor relationship whether you acknowledge it or not, check the provider's own data usage and retention policies.
• How is memory isolated between your tenant and other customers? Shared memory is a cross-tenant leak waiting to happen.
• If an agent processes data across jurisdictions, how is data residency enforced?

The data questions tie directly into the broader compliance story, breach notification, data residency, and retention obligations all flow from how the agent handles information. If the vendor can't crisply describe the data lifecycle inside their agent, they can't credibly promise you compliance with anything.

Scoring the Answers: A Practical Rubric

A questionnaire is only as good as your ability to grade it. Confident prose is not a passing answer. Here's how I read responses:

Red flags that should stop a deal or trigger deep follow-up: - The agent uses shared or human-borrowed credentials. - Permissions are described vaguely or granted broadly "for flexibility." - No reasoning-level audit trail, only action logs. - The kill switch is asserted but its mid-task semantics are undefined. - Customer data may be used for training, with hedged language.

Yellow flags worth negotiating: - Per-agent identity exists but credentials are long-lived. - Human-in-the-loop approval is available but off by default. - Logs exist but can't be exported to your SIEM.

Green signals: - Short-lived, per-agent machine identities tied to a recognized standard. - Per-task scoped permissions with configurable approval gates. - Tamper-evident logs capturing context, reasoning, and tool calls, exportable to your stack. - A documented incident playbook and tested kill switch. - Contractual no-training language and clear sub-processor disclosure.

One practical tip: weight the questions where a wrong answer is unrecoverable. You can negotiate log export after signing. You cannot easily un-leak a customer database that the agent was over-permissioned to read. Identity, permissions, and data isolation are the questions to be uncompromising on. The rest is negotiation.

And don't let a SOC 2 report do the questionnaire's job. A SOC 2 Type II tells you the vendor follows its own stated controls; it says nothing about whether those controls address agent-specific risk. Plenty of certified vendors have never threat-modeled a confused-deputy attack. Use certifications as a floor, never a ceiling.

Insights Most People Overlook

The questionnaire reveals the vendor's threat model, read it for what they didn't write. The most valuable signal isn't any single answer; it's whether the vendor anticipated the question at all. A team that volunteers detail on prompt-injection defenses and mid-task rollback semantics has clearly been through real incidents. A team that answers only what you literally asked, in minimal language, is telling you their security thinking stops at the edge of the spreadsheet.

Static questionnaires assess a moving target. Unlike a SaaS app whose behavior is fixed at deploy, an agent's behavior shifts as its underlying model is updated, as prompts are tuned, and as it accumulates memory. A point-in-time questionnaire captures a snapshot that's stale within a quarter. The genuinely mature approach is to negotiate continuous assurances, change notifications for model swaps, ongoing log access, re-attestation triggers, into the contract. Buying an agent is closer to hiring than to licensing.

The most dangerous agent is the one nobody filled out a questionnaire for. While procurement carefully vets the flagship deployment, employees are signing up for agent tools with a corporate credit card and connecting them to live systems. This shadow-agent problem means your real attack surface is the agents that never touched the questionnaire at all. The buying process needs to be paired with a detection capability for unsanctioned agents, or the rigor is theater.

"Outcome-based pricing" can quietly incentivize the agent to overreach. When a GaaS vendor is paid per successful outcome rather than per task, there's a subtle economic pressure toward agents that push to complete actions, taking an ambiguous instruction and running with it rather than stopping to ask. It's worth asking how the vendor's pricing model interacts with their agent's propensity to act autonomously. The incentive isn't always aligned with your caution.

Sub-processor risk compounds invisibly. Your agent calls a foundation model, which the vendor accesses through an aggregator, which routes to multiple providers. Each hop is a data-handling relationship you're inheriting. Most questionnaires stop at the direct vendor. Ask them to map the full chain, and treat any vendor who can't as a vendor who doesn't know where your data goes.

References

• OWASP Top 10 for Large Language Model Applications, LLM01: Prompt Injection
• NIST SP 800-207: Zero Trust Architecture
• Gartner, Information Technology Research and Insights
• Anthropic Commercial Terms of Service (data usage and retention)