TL;DR: Most AI agent security diligence accepts descriptions of controls instead of evidence that the controls act. This guide gives regulated enterprise AI and security leaders 30 security evaluation questions for technical due diligence, in eight categories from scope and inventory to evidence, containment, and agentic AI governance, with what a strong answer looks like and what evidence to request for each. Prediction Guard, a sovereign AI control plane, is built to produce that evidence inside your boundary for the agent traffic routed through it.
Most AI agent diligence fails the same way: it accepts descriptions of controls instead of evidence that the controls act. A vendor says the agent is scoped, monitored, and auditable, and nobody asks to watch it refuse something. Prediction Guard, a sovereign AI control plane that runs inside your boundary, is built to produce that evidence: enforcement, delegated authority, and records for the agent traffic routed through it.
This guide gives regulated enterprise AI and security leaders 30 security evaluation questions for technical due diligence on AI agent security. Organized into eight categories, these questions cover everything from agent inventory and threat assessment to identity, data privacy, runtime controls, and agentic AI governance. Each category explains what a strong vendor answer looks like and what evidence to request. It works for buying an agent product, assessing a vendor that builds agents into its service, or reviewing an acquisition target. It complements general AI vendor questionnaires, such as Prediction Guard's AI vendor risk checklist, by focusing on what an agent can do and how that is controlled. The standard underneath is operational control of agents: the vendor can show what each agent may do, stop it, and prove both. A disclosure: Prediction Guard publishes this guide and builds a sovereign AI control plane, which appears in one section. Nothing here is legal advice.
How to Use These Security Evaluation Questions
Grade every answer on an evidence ladder with four rungs: an assertion ("we do that"), a document (a policy or architecture diagram), a configuration (an export of real settings or records), and a demonstration (the control acting, live, in a test tenant or your own environment). Weight each answer by the highest rung reached, and require a demonstration for anything tied to a high-impact action. Certifications such as SOC 2 or ISO 27001 attest to organizational controls, so ask what is in scope, because they do not by themselves show how an agent behaves at runtime.
The eight categories move from knowing the agent to proving what it did:
KNOW IT LIMIT IT WATCH IT PROVE IT
1 Scope and 3 Identity and 5 Runtime 7 Evidence,
inventory delegated controls and incident
2 Threat authority detection response, and
assessment 4 Data privacy 6 Tools, MCP, containment
and access and supply 8 Governance
controls chain and complianceCategory 1: Scope and Inventory, Where AI Agent Risk Assessment Starts
You cannot assess what you cannot enumerate, and an agent's risk comes from what it can do, not what it is called.
Q1. How many agents are running today, and who owns each one? Listen for a registry with a named owner, purpose, data scope, and review date for every agent, plus a way to detect agents nobody registered. "We track them informally" is an answer to probe.
Q2. What can each agent do, in terms of tools, data, and actions with side effects? Listen for a capability list per agent that separates reading from writing and flags irreversible actions, not a description of the model.
Q3. Which agents are customer-facing, which touch regulated data, and which can act without a human in the loop? Listen for risk tiers based on autonomy and blast radius, applied agent by agent, with the reasoning written down.
Ask to see: the registry export, and an example of an unregistered agent being detected.
Category 2: AI System Threat Assessment
A credible AI system threat assessment names the ways agents fail and shows testing against them, not only a generic security review. The OWASP Top 10 for Agentic Applications (official OWASP list) is a useful shared vocabulary, and Prediction Guard's overview of key OWASP agentic risks walks through it.
Q4. Which threat model do you use for agents, and which risks does it cover? Listen for coverage of goal hijack, tool misuse, identity and privilege abuse, supply chain, memory poisoning, cascading failures, and rogue agents, with the mitigation for each.
Q5. How do you test prompt injection and tool misuse, and were the attacks adaptive? Listen for red-teaming that adapts to the defenses. In published research from researchers at OpenAI, Anthropic, Google DeepMind, and others, adaptive attacks bypassed 12 published prompt injection and jailbreak defenses with success rates above 90% for most, so near-zero results against a fixed test set tell you little.
Q6. What happens when an agent reads untrusted content, such as a ticket, a document, or a web page? Listen for a described path in which injected instructions cannot, on their own, cause a consequential action, because authority is enforced outside the model.
Q7. When was the last independent test, and what did it find? Listen for dated findings, fixes, and a retest. Reluctance to share even a summary is itself information.
Ask to see: the threat model, and a summary of the latest independent test.
Category 3: Identity and Delegated Authority
Q8. Does every agent have its own identity, separate from the person or service account that deployed it? Listen for a unique, revocable identity per agent and per sub-agent. Shared service accounts mean one compromised agent exposes everything that uses the credential.
Q9. How is authority granted, scoped, and expired? Listen for delegated authority: scoped, time-bound authority granted to an agent for a specific task, exercised under its own identity, traceable to the accountable human who authorized it, and enforced outside the prompt. The principle is least agency: the minimum authority a task needs.
Q10. Can you revoke one agent's access without affecting the others, and how long does it take? Listen for a measured time and a live demonstration. If revoking one agent means rotating a shared key, the answer is no.
Q11. What happens to authority when one agent delegates to another? Listen for lineage tracking and a rule that a child agent can never hold more authority than its parent.
Ask to see: one agent revoked live, with the others continuing to run.
Category 4: Data Privacy and Access Controls
This category covers data privacy and access controls together, because an agent's access is the main route by which private data escapes.
Q12. What data can each agent read and write, and how is that limited to what the task needs? Listen for task-scoped access evaluated on each request and not a broad credential. Prediction Guard's guide to authorization scope by industry shows how scope differs across regulated sectors.
Q13. What happens to sensitive data in prompts, tool outputs, memory, and logs? Listen for detection and masking before data reaches a component that should not see it, retention limits, and logs that store references and not raw values.
Q14. Where does the data go, and who else processes it? Listen for a data-flow map naming every model provider and subprocessor, with retention, training use, and region, and an option to run inside your boundary. Prediction Guard's deployment models guide compares the options.
Q15. How do you stop one customer's data from reaching another's through memory, retrieval, or shared context? Listen for tenant isolation in each layer, with test evidence.
Ask to see: the data-flow map, and an out-of-scope read being refused.
Category 5: Runtime Controls and Runtime Threat Detection
Q16. What is enforced on every call before it runs, and what is only observed afterward? Listen for a clear line between enforcement and alerting. An alert-only feature presented as enforcement is the most common gap.
Q17. Do you control both what passes into and out of a model and what the agent itself may do? Listen for Component Input/Output Controls (what passes into and out of a model or tool) and Agent Behavior Controls (what an agent may do, in what sequence, against which systems). A filter in front of the model is only the first half.
Q18. How does runtime threat detection work, and what does it trigger? Listen for detection of unusual sequences, volumes, or drift that feeds a separate enforcement mechanism able to trigger an intervention, a recorded control action that blocks, restricts, pauses, or terminates an agent action. A detection system that only generates dashboard alerts does not provide containment.
Q19. What stops an agent from looping or running up cost? Listen for hard limits on tokens, spend, rate, and concurrency that stop the action and do not merely report it.
Ask to see: a blocked call with the specific control that blocked it, and an agent stopped at a limit.
Category 6: Tools, MCP Servers, and Supply Chain
An agent's effective attack surface extends beyond the tools explicitly connected to it. Dependencies, package registries, proxies, and permitted network paths can create indirect routes to systems the agent was never intended to reach.
Q20. Which tools, MCP servers, models, and packages can an agent reach, and who approved each? Listen for an approved registry, pinned versions, review of tool descriptions and changes, and an exportable AI bill of materials.
Q21. What happens when an approved tool or server changes its behavior later? Listen for change detection and re-approval, and isolation of third-party servers so a compromised one has limited reach.
Q22. What can the agent's environment reach indirectly, including package mirrors, proxies, and telemetry endpoints? Listen for default-deny egress and a threat model that includes permitted paths. In July 2026, Hugging Face's technical timeline, citing OpenAI's account, described an agent escaping its sandbox through a zero-day in a package registry cache proxy, one of the sandbox's permitted network paths.
Ask to see: the approved-tools registry, and the egress policy.
Category 7: Evidence, Incident Response, and Containment
Q23. What record exists of every action an agent takes, and can anyone alter it? Listen for Immutable Audit Logs (tamper-resistant records of each action and control decision) that name the agent, the accountable human, the data touched, and the control decision, stored where you control them. For what a defensible record contains, see this guide to audit log implementation.
Q24. Can you produce an evidence package for a single incident on demand? Listen for an Evidence bundle (what was attempted, which control acted, and what was contained) that can be exported for an auditor, regulator, or insurer.
Q25. How do you stop an agent, and does the stop depend on the agent's cooperation? Listen for containment enforced at the agent's identity and the control point, with a measured time-to-stop. Palisade Research's shutdown resistance study found that several frontier models sometimes sabotaged a shutdown mechanism in controlled tests even when told not to, so a stop that relies on agreement is not enough.
Q26. What is your incident response process for a misbehaving agent, and who has authority to act? Listen for runbooks, named authority for each level of stop, notification duties, and evidence of drills.
Ask to see: a log sample, an exported Evidence bundle, and a live stop with its timing.
Category 8: Agentic AI Governance and Compliance
Agentic AI governance is where the vendor's answers meet your obligations, so ask for specifics and not logos.
Q27. Which frameworks and regulations do you map your controls to, and how? Listen for control-level mapping to the NIST AI RMF, a voluntary framework that NIST says is being revised, to OWASP, and to the EU AI Act where it applies.
Q28. How is each agent classified for regulatory purposes, and what role do you claim? Listen for classification by intended purpose and a clear statement of provider or deployer role. Under the EU AI Act, high-risk requirements apply from 2 December 2027 for Annex III uses. The Article 50 transparency duties have applied since 2 August 2026, but which duty applies depends on the system and what it does: systems intended to interact directly with people must tell them they are dealing with an AI system, while other paragraphs cover marking synthetic content and disclosing deepfakes, and not every duty applies to every agent or interaction. The Commission's AI Act page tracks the dates.
Q29. How are changes to models, prompts, tools, and scope controlled? Listen for versioned configuration, reassessment when a change alters what the agent can do, and a tested rollback path.
Q30. What do your certifications and audits actually cover? Listen for a scope statement that names the agent runtime. Attestations of organizational controls are useful but do not show how an agent acts.
Ask to see: the control mapping, and the scope statement of the latest audit.
Five Answers That Should Slow the Deal
- "The system prompt tells the agent what it may not do." An instruction is not a control.
- "We monitor for that." Ask what happens when the monitor fires, and whether it can stop anything.
- Agents running under shared service accounts. Attribution and revocation both fail.
- Evidence that exists only in aggregate dashboards or the vendor's tenant. You cannot reconstruct an incident from it.
- A refusal to demonstrate. If a control cannot be shown acting in a test tenant, treat it as an assertion.
Where Prediction Guard, a Sovereign AI Control Plane, Fits, and Where It Does Not
A sovereign AI control plane is the architecture that identifies, authorizes, enforces, meters, records, and contains agent actions, running inside your boundary. These capabilities provide the enforcement layer behind several of the questions above: whether an agent has the authority to act, whether its actions are constrained at runtime, and whether those actions can be reconstructed and contained. It speaks most directly to categories 3, 5, 6, and 7, and it does not replace the vendor's threat assessment, your governance process, or the sandbox and network controls around an agent.
Use these 30 questions on Prediction Guard too. Its published limits apply: it enforces on traffic routed through it, per-invocation authorization at the tool server is not yet generally available, token-based limits currently apply per API key, and human approval gates for high-risk tool executions are on the roadmap, as its blast radius guide states. A vendor that states its limits this plainly is easier to diligence than one that does not.
Questions About AI Agent Security Due Diligence
1. How many questions should a review include?
Scale to risk. A read-only internal assistant may warrant the inventory, data, and evidence categories, while an agent that acts on regulated data warrants all eight with demonstrations.
2. Who should answer them?
The people who operate the controls, not only sales or compliance. Ask engineers to show configuration and live behavior.
3. Can a certification replace these questions?
No. A certification attests to organizational controls within a defined scope. These questions ask how a specific agent is bounded and stopped.
4. When should diligence happen?
Before contract signature, and again whenever the agent gains a new tool, data source, or level of autonomy.
Evidence Over Description
The strongest diligence outcome is not a clean questionnaire. It is a vendor that can show each control acting, give you the record, and tell you where its limits are. That is the standard AI agent security should be held to: operational control of agents that can be demonstrated, independently examined, and proven through evidence.
How Prediction Guard Solves This
Prediction Guard gives regulated enterprises operational control of their AI agents: one sovereign AI control plane that identifies, authorizes, enforces, meters, records, and contains every action an agent takes, running inside the customer's own boundary. It is built to answer the questions in this guide with demonstrations: delegated authority per agent, Component Input/Output Controls and Agent Behavior Controls on every routed call, token and spend enforcement, Immutable Audit Logs, and an Evidence bundle for each intervention.
It enforces on traffic routed through it, and per-invocation authorization at the tool server and human approval gates are not yet generally available. Ask us to show you a blocked call, a stopped spend, and a revoked agent identity in the same session.