Vendor due diligence

Ask what the agent can do—not only what model it uses.

A practical questionnaire for enterprise buyers evaluating AI products that retrieve customer data, connect to tools, operate workflows, make recommendations, or take action.

A model card explains the model. An agent security review must explain the identity, authority, data, tools, actions, approvals, evidence, dependencies, and containment surrounding the model.

Response format

For each question, request Yes / Partial / No / Not Applicable, a concise explanation, the responsible owner, evidence reference, applicable product tier or deployment model, known limitations, and planned remediation date where relevant.

1. Product scope and agent inventory

Identify every AI agent, copilot, autonomous workflow, model-powered feature, and third-party agent included in the proposed service.
Describe what each agent can read, create, change, send, approve, purchase, delete, deploy, disclose, or trigger.
Identify the model providers, model versions, agent frameworks, orchestration systems, and MCP clients or servers used.
Describe which capabilities are enabled by default, optional, experimental, customer-configurable, or limited to specific service tiers.
Explain how customers are notified before an agent gains a new tool, broader data access, greater autonomy, or a material model change.
Provide the named product, security, privacy, and operational owners accountable for agent risk.

2. Identity, authentication, and delegated authority

Can every consequential action be attributed to a stable agent identity and the initiating customer user, service, or workflow?
How does the service authenticate agents, users, MCP clients, MCP servers, tools, and downstream systems?
Does the agent act as itself, impersonate a user, use a shared service account, or receive delegated short-lived authority?
How are permissions constrained by customer, tenant, user, record, action, tool, time, destination, and transaction value?
How are tokens, API keys, certificates, and secrets issued, stored, exposed to model context, rotated, and revoked?
Can a customer immediately revoke a specific agent, user delegation, tool, integration, credential, or action class?

3. Tenant, customer, and data boundaries

Where are customer and tenant boundaries enforced for retrieval, memory, tools, APIs, caches, logs, and downstream actions?
What automated tests verify that one customer’s prompts, memory, data, tools, actions, or evidence cannot cross into another tenant?
Which customer data classes can enter prompts, retrieval indexes, agent memory, model requests, traces, or tool outputs?
How does the service enforce data minimization and remove fields not necessary for the current action?
Is customer data used to train, fine-tune, evaluate, improve, or retain state for any shared model or service? Describe opt-out and deletion controls.
Identify every external model, subprocesser, region, support path, logging system, and tool server that may receive customer data.

4. Tool, API, and MCP security

List all tools and MCP servers the agent can call and the business effect of each available action.
How are tool names, descriptions, schemas, examples, publishers, versions, and integrity verified before use?
Can an MCP server or integration register a new tool or expand a schema without customer and security approval?
How are tool parameters validated before reaching databases, commands, file paths, templates, interpreters, browsers, or external APIs?
What filesystem, process, network, credential, and resource isolation protects tool execution?
How are outbound destinations, redirects, callbacks, webhooks, internal networks, and data exfiltration constrained?

5. Action policy and human oversight

Which actions are permitted autonomously, permitted with conditions, subject to human approval, or prohibited?
Are business rules and transaction limits enforced outside the model and prompt?
What context is shown to a human approver, and can the initiating agent alter, omit, or satisfy the approval itself?
How does policy account for value, volume, recipient, destination, novelty, timing, customer tier, data class, and workflow state?
Can customers define stricter action policies, approval thresholds, regional restrictions, and deny rules?
How are emergency exceptions approved, logged, time-limited, reviewed, and revoked?

6. Adversarial testing and change control

Describe testing for prompt injection, goal hijacking, tool poisoning, memory manipulation, sensitive-data leakage, and privilege escalation.
Describe testing for cross-tenant access, approval bypass, indirect injection from documents or websites, and unsafe chained actions.
Are tests repeated when models, prompts, tools, permissions, MCP servers, data sources, dependencies, or workflows change?
Who can approve production changes that expand agent authority or introduce a new external dependency?
Provide the date, scope, and summary of the most recent independent security assessment relevant to the agent architecture.
Explain how high-severity findings, exceptions, compensating controls, and remediation commitments are communicated to customers.

7. Logging, evidence, and customer visibility

Can logs connect customer user, agent identity, model reference, retrieved data, tool call, policy decision, approval, result, and downstream effect?
Do policy records explain why an action was allowed, denied, changed, rate-limited, or escalated?
What evidence can customers access, export, retain, search, integrate with a SIEM, or preserve for investigation?
How are logs protected from alteration, synchronized in time, access-controlled, separated by tenant, and deleted?
What monitoring detects unusual agents, tools, destinations, data volume, action rates, retries, errors, and approval patterns?
How quickly are customers notified of a suspected unauthorized action, cross-tenant event, data exposure, or compromised integration?

8. Containment, recovery, and contractual accountability

Can the vendor selectively disable an agent, tool, MCP server, credential, tenant, destination, workflow, or action class?
Can the service enter read-only, human-approved, or deny-by-default safe mode without a full outage?
Describe the incident response roles, evidence preservation, customer communication, remediation, and controlled restoration process.
When was selective containment last tested, and what time-to-detect, revoke, preserve, and restore was achieved?
Do contracts define AI-specific security obligations, subprocessors, data use, breach notification, audit rights, deletion, and support for investigation?
Will the vendor provide advance notice and customer control over material changes to models, tools, data use, autonomy, or deployment architecture?

High-risk response patterns

“The agent only performs what the user asks” without independent action authorization.
Shared service credentials or full user impersonation with no narrower delegation.
Reliance on model safety filters as the primary control for tool execution.
No authoritative list of tools, MCP servers, data sources, or downstream actions.
Human approval that shows only generated text and omits the real target, amount, destination, data, or side effect.
Conversation logs presented as complete evidence for actions taken across external systems.
Inability to disable one compromised agent or tool path without shutting down the entire service.
Material model, tool, or data-use changes permitted without customer notice or renewed security review.

Scoring guidance

Do not reduce the review to a single arithmetic score. Weight unanswered or unsupported questions based on the maximum possible business effect. A missing control around money movement, production deployment, cross-tenant data, regulated decisions, or destructive actions should outweigh numerous low-impact “Yes” responses.

Contractual follow-through

Convert material vendor answers into contract terms, technical configurations, customer acceptance tests, evidence delivery requirements, notification obligations, remediation dates, and renewal conditions. Reassess when the vendor changes models, tools, data use, permissions, autonomy, subprocessors, or architecture.

Next step

Fugitive Intelligence can help buyers adapt this questionnaire to a specific workflow or help vendors turn the answers into enforceable controls and customer-ready evidence. Request a vendor assurance discussion.