25 Security Questions for AI Agent Vendors

An enterprise AI security questionnaire is a structured set of questions that forces every agent vendor to give you comparable, evidence-backed answers about how they handle your data, who can reach it, what an agent is allowed to do, and what it leaves behind. Below are 25, grouped into seven themes, with the answer to accept — and the proof to ask for — beside each.

The market for enterprise AI agents is crowded, and the pitches sound alike. Every vendor “takes security seriously,” “never trains on your data,” and offers “enterprise-grade access controls.” Those are sentences, not evidence, and a procurement team comparing five tools on sentences is comparing nothing.

A good security questionnaire fixes that by asking questions whose answers are either observable or not. “Does an agent run through an approval step?” has a yes-or-no answer you can watch in a demo. “Can you show me what a given answer was built from?” is a screen or it is a promise. This post is that questionnaire — 25 questions across the seven areas that actually separate agent platforms — written so you can hand it to any vendor and score the replies side by side.

Where a question has a clean answer for Suger Insulin, the general-purpose AI platform built by Suger, this post gives it, using only capabilities that exist today. Treat those as a worked example of what a specific, checkable answer looks like — not as a reason to skip asking every other vendor the same thing.

Theme 1 — Data handling: is your content retrieved or trained on?

The first question decides whether uploading your real documents is a normal decision or an irreversible one. The answer to accept is that your content is retrieved at query time to ground an answer, not used to train a model — because those two operations have opposite consequences for deletion, isolation, and auditability.

Do our documents or conversations train your models — including any opt-in version with a checkbox someone could leave on? A default-off training setting is a different answer from a structural no. Ask which one it is.
When a question is answered, what actually happens to our data? The answer you want describes retrieval: relevant passages are found and supplied alongside the question for that one answer, then discarded. Insulin chunks, embeds, and indexes documents and retrieves them at query time — the model’s weights never change. Is your company data used to train models? walks through why the mechanism matters more than the policy.
Can an answer built from our data ever surface to another customer? With training, that is structurally possible and unprovable. With retrieval into a per-tenant index, it is not a path that exists.
Where does our content physically sit, and is it encrypted in transit and at rest? You want named infrastructure and named ciphers, not “the cloud.” Suger’s platform runs on AWS in the United States, with TLS 1.3 in transit and AES-256 at rest — see the Suger security overview.

The tell across all four: a vendor that retrieves can answer each precisely, and a vendor that trains has to explain a complication.

Theme 2 — Access control: who can reach an agent and its data?

Ask how access is granted, not whether it exists. The answer to accept is role-based access with named roles and explicit sharing, where nothing is visible until someone grants it — not an “admins see everything” model that quietly widens as the org grows.

What roles exist, and what can each actually do? You want a short, legible list. Insulin shares an agent with three roles — ADMIN (edit configuration and manage sharing), EDITOR (change the system prompt, model, knowledge bases, and integration allowlist), and USER (use it in conversation, configuration read-only).
Is a personal workspace private by default? A user-level agent and a user knowledge base should stay private until shared. Uploading a document must not publish it.
Can an organization admin reach every knowledge base by default? The safer answer is no. Insulin organization knowledge bases require explicit per-base sharing, and an org admin cannot access one by default — a deliberately tighter model than people expect.
How do people authenticate, and can we enforce SSO and MFA? For an enterprise rollout you want single sign-on and provisioning. Suger supports OIDC SSO with SCIM provisioning on Growth and Enterprise plans, and MFA across all plans.

Controlling which agents see which documents covers how these defaults compose in practice.

Theme 3 — Scoping and least access: what can one agent reach?

This is the theme most vendor checklists skip, and it is where a real breach of expectation happens. The answer to accept is that an agent reaches only the systems and documents you explicitly attach — an allowlist, not inheritance. An agent that can touch everything the buyer’s organization has connected is a single prompt away from a mistake nobody scoped.

Does an agent automatically inherit every connection our organization has configured? The answer you want is no. Insulin agents “do not automatically receive every connection your organization has configured” — you allowlist the integrations each agent may use.
How are knowledge bases attached, and can attachment be read-only? You want a mode. Insulin attaches a base in Read (retrieve and search only) or Edit (retrieve, plus create and update files — but never delete). Read is right for almost every agent.
Can an organization-level agent reach a personal integration? It should not. Insulin org-level agents can use org-level integrations only and cannot reach user-level ones — scope does not leak upward or downward.
How do you recommend we split knowledge bases? A thoughtful vendor answers “by who may see the content, not by subject,” because sensitivity is the boundary that maps onto which agents get which base. Per-document access control across one giant base is the shape nobody maintains.

Scope is the boundary that makes every later control meaningful; get it wrong and audit and approvals are guarding a door that is already open.

Theme 4 — Actions and approvals: what happens before an agent does something?

For any agent that can act — send, write, update, spend — ask what stands between the plan and the action. The answer to accept is a visible human-in-the-loop approval step for consequential actions, where the plan is shown before it runs and a person decides whether it runs at all.

Before an agent executes a tool, do we see the plan and approve it? In Insulin, tool execution runs through approval workflows in chat: the agent proposes, you see the plan, and nothing runs until you approve. Watch this in a demo rather than reading it in a datasheet.
Can we choose the model per agent, or are we locked to one? Model choice per agent lets you match capability and cost to the task, and keep a sensitive workflow on a model you have vetted. Insulin lets you pick the model per agent.
How is an agent extended with new capabilities, and who approves that? New skills are a supply-chain question. Insulin extends an agent with reusable skills, including ones installed from the agent marketplace — so ask who in your org can install one, and treat it like adding a dependency.
Does the platform ground answers in your documents, or fall back to model guesswork? Grounding is a safety property, not just a quality one: a grounded agent answers from attached sources with citations instead of inventing a figure. Insulin agents answer from attached knowledge bases with cited sources.

The demo test here is simple: ask the vendor to make an agent do something irreversible, and see whether the product makes you the one who pressed the button.

Theme 5 — Auditability and run history: can you reconstruct what happened?

Assume something will go wrong and ask how you would investigate it. The answer to accept is a durable, inspectable record of what ran, when, and with what result — for interactive answers and for unattended automation alike. “We have logs” is not enough; ask to see the table.

Can we trace what a specific answer was built from? Citations are the observable proof that grounding is real. Insulin returns cited sources with an answer, so a reply can be traced to the passages it used rather than accepted on trust — see why AI answers need citations.
Is there a run history for automated work, and what does each record show? For scheduled and event-driven automation you want a runs table. Every Insulin job trigger creates a run record showing when it started, its status, and its duration, with the result — and, for an event-driven run, the payload it received — on expansion.
Are audit logs reachable programmatically, or console-only? You want them queryable so you can feed your SIEM. Suger’s audit logs are queryable via API rather than trapped in a console.
How do you notify our systems of events, and can we verify the notification is genuine? Signed webhooks matter for anything that triggers downstream action. Suger sends HMAC-signed webhooks with an X-Suger-Signature-256 header so a receiver can verify authenticity.

Theme 6 — Tenancy and deletion: is our data isolated, and can we get it out?

Two questions that a policy document cannot answer honestly unless the architecture backs them. The answer to accept is that every record belongs to exactly one organization, and that deleting a document actually removes it from future answers — not that it is “scheduled for removal” from a model that already absorbed it.

Is tenancy enforced in code, or by convention? You want isolation checked before data is read, not assumed. In Suger, every record belongs to one organization, and org-scoped verification runs before any data access.
If we delete a document today, what happens to answers tomorrow? A retrieval system has a clean answer: the document stops being retrieved, so it stops appearing in answers, and nothing was absorbed that would need unlearning. A training system has a complicated one. This single question separates the two architectures faster than any certificate.
Who can delete an agent’s underlying automation, and is it private by default? Ask for the ownership model. An Insulin job is private to its creator — only the owner can see, run, edit, or delete it.
Does an unattended run inherit its creator’s access? It does, and you should design for it. An Insulin job runs within its creating user’s scope, so a job built by someone with broad access carries that access into a run nobody is watching — the combination to check when output goes somewhere visible.

Theme 7 — Assurance and incident response: what can you prove to an auditor?

Finish with the evidence a security team needs on file, and how the vendor behaves when a researcher finds a hole. The answer to accept is independent, current attestations you can actually obtain, plus a published disclosure process with a stated response time.

Which certifications do you hold, and will you share the reports under NDA — plus how do you handle a reported vulnerability? You want named, independent attestations and a real disclosure policy, not a self-assessment. Suger holds SOC 2 Type II, ISO/IEC 27001, and states GDPR compliance, and Enterprise customers can request the SOC 2 report, ISO certificate, penetration-test summaries, and completed security questionnaires. Its responsible-disclosure policy commits to acknowledging a report within 48 hours and taking no legal action against good-faith researchers. Reach the team at [email protected].

A vendor that self-scores every control and shares no third-party evidence has answered the easy version of this question. Ask for the report.

The checklist, at a glance

Theme	Questions	The evidence to demand
Data handling	1–4	A demo showing retrieval + citations; named infrastructure and ciphers
Access control	5–8	The role list; SSO/MFA/SCIM configuration in the product
Scoping / least access	9–12	The integration allowlist and Read/Edit attachment, shown live
Actions & approvals	13–16	An approval step you watch gate a real action in a demo
Auditability	17–20	The runs table, cited sources, and API-queryable audit logs
Tenancy & deletion	21–24	Delete a document, then show it gone from an answer
Assurance & IR	25	SOC 2 / ISO reports under NDA; a published disclosure policy

Frequently asked questions

What is an enterprise AI security questionnaire? It is a structured set of questions that forces every AI agent vendor to give comparable, evidence-backed answers about data handling, access control, scoping, actions, audit, deletion, and assurance — so you can score tools side by side instead of on marketing language.

What is the single most revealing question to ask? “If I delete a document today, what happens to answers tomorrow?” A retrieval system answers cleanly — the document stops being retrieved. A system that trained on your data has to explain a complication. The answer exposes the underlying architecture immediately.

Why does scoping matter more than most checklists suggest? Because an agent that inherits every connection your organization has configured is one prompt away from reaching data nobody scoped it to. Least-access — an explicit integration allowlist rather than inheritance — is the boundary that makes audit and approvals meaningful rather than decorative.

What evidence should I demand for approvals and audit? Watch them in a demo. Ask the vendor to make an agent perform an irreversible action and confirm an approval step gates it. For audit, ask to see the run record and the cited sources on an answer — not a datasheet claim that logs exist.

How does Insulin answer these questions? Insulin retrieves your content at query time rather than training on it, scopes each agent to an explicit integration allowlist, attaches knowledge bases in Read or Edit mode, gates tool execution behind in-chat approval, and records every job run. Company assurance — SOC 2 Type II, ISO/IEC 27001 — is documented on the Suger security page.

Takeaways

Score vendors on questions with observable answers, not on sentences everyone says. Retrieval-vs-training, an approval step, and a runs table are things you can watch in a demo.
The most revealing single question is what happens to answers after you delete a document — it exposes the architecture underneath the policy.
Scoping is the theme most checklists skip and the one that matters most: an explicit integration allowlist, not inheritance, is what keeps an agent inside its job.
For approvals and audit, demand a demonstration — a real action gated by approval, a run record, and cited sources — rather than a datasheet claim.
Ask for independent evidence: SOC 2 and ISO reports under NDA and a published disclosure policy beat any self-assessment.

Insulin was built so these answers are demonstrable rather than asserted — scoped agents, grounded knowledge bases with cited sources, and auditable jobs. See the Suger security overview, or get a demo and put this checklist to it.

25 Security Questions to Ask an Enterprise AI Agent Vendor