The AI Agent Security Questionnaire: 12 Questions Enterprise Buyers Ask, and What a Passing Answer Looks Like

An AI agent security questionnaire is the set of questions an enterprise buyer's security, compliance and procurement teams send an agent vendor before approving a deployment. In 2026 it is no longer a generic vendor questionnaire with an AI section bolted on. It asks what the agent is authorised to do, how that authority is checked at runtime, and what evidence survives afterwards. Most vendors fail on the third one.

If you are reading this because a pilot the buyer already liked has been sitting in their security review for six weeks, and the blocking questions are about logging and authority rather than encryption, you are in the right place. That delay is not a procurement problem. It is a missing artefact.

The questionnaire is where agent deals go to die. Not because the product is weak, but because the questions changed and the answers did not.

Encryption, uptime, data residency and SOC 2 scope are solved problems with canned answers. The AI agent governance section is different. It asks about authority and evidence, and most agent vendors have neither in a form an auditor accepts. The pilot works, the buyer likes it, and then a security architect asks one question in a call and the deal adds eight weeks.

This is that question set, what each question is actually testing, and what a passing answer sounds like. Eight of the twelve you can pass by writing a better answer. Four you cannot, and knowing which four is the difference between an eight-week delay and a closed deal.

Key takeaways

• The questionnaire is testing three things: what authority the AI agent has, whether that authority is checked before execution, and what evidence exists afterwards.
• Traces are not evidence. A trace shows what happened, written by the party being asked to prove it. Auditors discount self-generated records.
• The strongest artefact you can show is a denial. An approval shows something happened. A refusal shows the control was operating.
• Four of the twelve cannot be answered with better copy. They ask for artefacts, and one of them asks for an artefact you are structurally unable to issue yourself.
• SOC 2 Type II does not close that one. Period attestation and per-record verification are different things, and buyers now ask for both.

Why AI agent deals stall in security review

Three things moved in 2026 and they moved together.

Enterprise legal teams read the case law. Moffatt v. Air Canada rejected the argument that a chatbot is a separate entity from the company deploying it. Mobley v. Workday was certified as a nationwide class action in May 2025 on a theory that reaches the AI vendor, not only the deploying employer. The consequence downstream is contractual: buyers now push agent liability toward the vendor, and the vendor has no artefact proving the agent stayed inside what the customer authorised.

Second, buyers started contracting as though logging and oversight obligations were already binding. The EU AI Act's high-risk obligations moved from August 2026 to December 2027 for standalone systems, but that deferral did not relieve vendors. Retrofitting evidence capture after deployment is expensive, so procurement writes the requirement in now.

Third, the failure mode is documented. Independent research catalogued 344 verified agent incidents, of which 188 involved autonomous AI causing direct production damage with no attacker present. Deletion and destruction accounted for 65. This is no longer a hypothetical risk a security team has to argue for internally.

The result is an AI agent security review that asks about permission and proof rather than perimeter.

The 12 questions, and what each one is testing

1. How are agent identities provisioned, scoped and revoked?

What it tests: whether an AI agent identity is real in your system or a label on a shared service account.

Failing answer: "Agents authenticate with an API key scoped to the customer."

Passing answer: each agent has its own workload identity, capabilities are scoped per agent rather than per customer, and revocation is atomic across the control plane with a stated propagation time. If revocation depends on a cache expiring, say the cache TTL out loud. Buyers accept a number. They do not accept vagueness.

2. Does each agent run under a unique, bounded identity with short-lived, per-invocation credentials?

What it tests: shared-secret sprawl, which is still the common state. Survey data from early 2026 found 45.6% of organisations authenticating agents with shared API keys and only 21.9% treating agents as independent identity-bearing entities.

This is where the question "should AI agents have their own identity and permission system, separate from human identity?" gets settled in practice. They should, and it is not sufficient on its own. Separate identity solves attribution: it tells the buyer which agent acted rather than which employee's credentials it borrowed. It does not solve AI agent authorization, which is what questions 6, 8 and 9 are reaching for.

Passing answer: one identity per agent, credential lifetimes measured in minutes not months, no shared service accounts, and an answer to what happens when a credential leaks that does not involve a support ticket.

3. What is logged for every prompt, response, tool call and policy decision?

What it tests: whether your capture is complete enough to reconstruct a decision, not just observe an outcome.

Passing answer: full provenance per action. User, agent identity, model version, tool version, the proposed action, the decision, the policy that produced it, a hash of the result, and a timestamp. Immutable, exportable, and signed.

The word doing the work there is decision. Most vendors log actions. An action log tells the auditor what the agent did. It does not tell them whether the agent was permitted to do it. That gap is the difference between telemetry and an AI agent audit trail.

4. Show me a complete audit trail for a single user task involving at least one agent, two tool calls and one agent-to-agent handoff

What it tests: this is not a document request. It is a live demo, and buyers expect retrieval in under ten seconds with reproducible provenance.

This question fails more vendors than any other, for a specific reason. Most agent platforms have distributed tracing, which is excellent for debugging and organised around spans and latency. The buyer is asking for something organised around authority: one task, one chain, one answer to "was each step allowed." Those are different data models, and a trace viewer does not become an audit trail because you renamed the tab.

Passing answer: open the console, pull the task by ID, show the chain end to end, and let them click into one step and see the decision that permitted it.

5. Can we run a private pilot in our environment that produces evidence we can show our auditors?

What it tests: whether your evidence is portable or hostage.

Buyers want artefacts they retain after the pilot ends. If the only way to see the record is to log into your dashboard, the evidence dies with the contract, and the buyer's auditor cannot examine it independently. You cannot answer this one with a better sentence. Either the pilot emits something the customer keeps, or it does not.

Passing answer: the pilot emits records the customer keeps, in a documented format, verifiable without a login.

6. What happens when the agent is denied, and can you show me a denial?

What it tests: whether your control demonstrably operated, which is the thing auditors actually assess.

This is the most underrated question on the list and the easiest to be excellent at.

An approval record shows an action took place. It does not show that anything checked it. The artefact that proves a control was operating is the denial: the agent proposed something, the check refused it, and here is the record. Most systems evaluate policy, return a refusal to the caller, and discard the decision. The evidence of the control working is thrown away at the exact moment it is created.

This is also the honest answer to "how do AI agents access sensitive data without authorization." They usually do not break anything. They act inside credentials that were granted too broadly, and nothing records the moment the action should have been refused, because nothing refused it.

Passing answer: denials are recorded through the identical path as approvals. Same schema, same signature, same storage, same retrieval. If your denials live in application error logs while approvals live in an audit store, you do not have a denial record. You have a stack trace.

7. How fast can we stop an agent mid-action?

What it tests: containment, and whether you have thought about the window between a wrong decision and its discovery.

Buyers are now specifying numbers: termination inside five minutes for production agents, inside one minute for agents with transaction authority.

Passing answer: a stated termination path, a stated worst-case time, and an honest account of what is already in flight when the switch is thrown.

8. Who signs your audit records, and can we verify them without calling your API?

What it tests: independence. This is the question that separates a log from evidence, and it is the only one on the list you can never pass on your own.

A record your system wrote, stored in a database your team can update, and served from an endpoint you control, is testimony from the party being examined. It may be completely accurate. It is still a claim, not proof, and an auditor will treat it accordingly. The same reason a company does not audit its own books.

Passing answer: records are cryptographically signed by a party with no stake in the outcome, the verifying key is published where anyone can fetch it, and verification runs offline against that key with everyone's servers switched off. If verification requires calling you, you have moved the trust problem one hop rather than solving it.

The stronger version adds anchoring: batches of records committed into an append-only structure published somewhere neither party controls, so records cannot be inserted, removed or backdated after the fact without breaking every proof derived from it. Name the cadence and the maximum window as numbers.

9. What authority did our side actually grant, and where is that recorded?

What it tests: whether a mandate exists as a machine-checkable artefact or as a sentence in a configuration screen. This is the AI agent authorization question, and it is the one that most often arrives last and costs the most to answer late.

"The customer configured limits in the dashboard" is a weak answer, because the configuration is a row in your database that your team can change. The buyer is asking what they authorised, in a form that exists independently of you.

Passing answer: the authority is a versioned artefact, signed by the granting party, that the vendor cannot create on the customer's behalf. Every decision references the version in force at the time it was made, so an auditor can test whether the decision was correct, not only that it occurred.

One honest sub-problem worth naming rather than hiding. If a model converts a plain-language instruction into a machine policy, the trust problem has moved from the agent to the translator and then been signed. The defensible design is that the human confirms the structured rules, not the sentence, and it is that confirmation which gets signed. The model may translate. It never decides.

10. What happens when you change the model underneath us?

What it tests: change control, which enterprise buyers now treat as a contractual matter.

Current expectations include advance deprecation notice, parallel availability of the prior model, and re-acceptance rights after an update, with regression testing against a fixed evaluation set.

Passing answer: a notice period stated in days, a pinning option, and an evaluation set you re-run on every change with published tolerance bands.

11. What certifications and attestations do you hold, and what is in scope?

What it tests: baseline assurance, and whether you understand the difference between holding a certificate and having the control.

SOC 2 Type II and ISO 27001 are table stakes. ISO/IEC 42001 has moved from differentiator to requirement in financial services, healthcare and government procurement, with first-year certification cost commonly quoted between $85K and $650K.

Passing answer: current reports, the scope stated precisely, and a clear statement of which agent-specific controls sit inside that scope rather than adjacent to it. Scope inflation is caught immediately and costs you credibility on every other answer.

12. Have you tested against the OWASP Top 10 for Agentic Applications, and will you share methodology and results under NDA?

What it tests: whether anyone has attacked the thing on purpose.

Passing answer: independent testing inside the last twelve months, methodology and dated results available under NDA, and remediation status per finding. "We do internal testing" reads as no.

Eight of these you can answer. Four you have to have.

Questions 1, 2, 3, 4, 7, 10, 11 and 12 are engineering and paperwork. Hard work, finite work, and entirely inside your control. Get them right and you look like a serious vendor.

Questions 5, 6, 8 and 9 are different. They do not ask you to describe something. They ask you to produce an artefact, on the call, that exists whether or not the buyer believes you.

• Q9 asks for the authority, as a signed object your team cannot edit.
• Q6 asks for a denial, recorded through the same path as an approval.
• Q5 asks for those records in the buyer's hands, surviving the pilot.
• Q8 asks whether any of it can be checked without you.

That last one is the wall, and it is worth being precise about why, because there are three obvious ways around it and none of them work.

Why you cannot be your own third party

Q8 is not asking whether your logging is good. It is asking who vouches for it.

Your record, written by your code, stored in your database, served from your endpoint, signed with your key. Every one of those is a point at which your company could have changed something. Nobody is accusing you of anything. That is what an auditor's job consists of, and it is why a company does not audit its own books.

Three answers come up in every one of these calls. Here is why each one falls short.

"We have SOC 2 Type II, and our auditor attests to our logging controls." This is the strongest of the three and it still does not close Q8. A Type II report says an independent auditor sampled your controls over a period and found them operating. It is a statement about your organisation over months, based on a sample, made by a firm you engaged and paid. Q8 asks something narrower and harder: can this specific record, about this specific action, on this specific date, be checked by someone who trusts neither of us. Period attestation and per-record verification are different artefacts, and the second does not follow from the first. Your buyer accepts your SOC 2 for infrastructure and still asks Q8 for agent decisions, because the exposure is per-action and the sample is not. Worse for Q9: no attestation can cover an authority artefact that does not exist to be audited.

"We write the records into the customer's own bucket or SIEM." This is a good answer to Q5 and only to Q5. Storage location is not provenance. A record you generated, signed with your key and copied somewhere else is still your assertion, sitting in a different building. Q8 is about who signed it, not where it ended up.

"We publish hashes of our logs to a public chain." Anchoring proves a record existed at a point in time and has not been altered since. It does not make the record true at the moment it was issued. If you generate the record and you anchor the record, you have proved that you did not tamper with your own claim afterwards. The claim is still yours. Anchoring is necessary and it is not sufficient, and a security architect who has seen this before will say exactly that.

So there is a ceiling on how well you can ever answer question 8 alone, and the ceiling is below passing. You can improve questions 1 through 4 indefinitely. Question 8 has a hard stop, and no amount of engineering on your side moves it, because the thing being tested is precisely that the evidence did not come from your side.

The buyer already knows this. It is why the question is phrased the way it is.

What passing questions 5, 6, 8 and 9 actually requires

Three parts, and it needs all three.

A mandate. A signed, versioned, machine-readable statement of what the principal authorised. Scope, limits, conditions. Not a prompt, not a chat log, not a configuration row. An artefact that exists independently of the agent and can be shown to someone who was not there. That is Q9.

A gate. A check between the agent's decision and its execution that runs every time and returns allow or deny before anything happens. This part is no longer differentiated. Pre-execution interception has been broadly available since Q2 2026 under permissive licences, and you may already have it.

A receipt. A record of the decision, covering denials as well as approvals, issued and signed by a party with no stake in the outcome, that the buyer can verify without access to anyone's systems. That is Q5, Q6 and Q8 in a single artefact, and it is the part almost nobody has.

AI agent identity answers who the agent is. It does not authorise anything, and it does not prove anything. A verified agent identity can still take an action nobody approved, and the identity record will be perfectly accurate in every one of those log lines. What the buyer is reaching for is the action-level control and the artefact that demonstrates it operated. We call that structure Know Your Intent.

Where Abstraxn fits

Abstraxn issues the receipt so that you do not have to, and so that your buyer does not have to take your word for it.

That is the whole proposition, and the reason it works is a constraint rather than a feature. Abstraxn never holds funds, never holds keys, and never sits in the execution path. It has no stake in whether any given action succeeds, which is exactly what makes a record it issues worth something to the person reading it two years later. A vendor with money in the transaction cannot issue independent evidence about that transaction, and neither can you about your own agent.

What you actually integrate. Warrant is the module inside Abstraxn's KYI Framework that does this. Your backend installs @abstraxn/warrant and creates a mandate; the owner signs it, optionally through the @abstraxn/warrant-react form, which shows a deterministic plain-English readback generated by fixed rules rather than a language model, so the thing confirmed and the thing enforced are the same thing. At runtime your agent calls warrant.check() before the action. It returns ALLOW or DENY plus a signed receipt, and if the answer is DENY you never call the real tool. If you are wrapping an MCP tool, the check sits in front of the tool call. Mandates are created with your application key; runtime agents hold a separate per-mandate key and can only call check().

On Q9, the mandate. It is created by the principal and signed by the principal. Abstraxn cannot produce one on a customer's behalf, and a request arriving without an owner signature is rejected outright. When your buyer asks what they authorised, the answer is an object carrying their own signature, not a row in your database.

On the gate. Policy evaluation uses Cedar, which is deterministic rather than probabilistic: identical rules and identical input produce an identical decision, every time. Any single rule refusing wins over any number permitting, and an evaluation error denies rather than passes. The live policy controls are address allowlisting, address blocklisting and per-transaction limits. Velocity caps and kill switch are in active development.

On Q5, Q6 and Q8, the receipt. Every decision produces an Ed25519-signed receipt containing the proposed action, the verdict, the reasons and the timestamp. Denials run the identical path as approvals: same schema, same signature, same storage, same retrieval, which is the Q6 answer most vendors cannot give. The verifying public key is served from an unauthenticated endpoint, and @abstraxn/warrant-verifier checks a receipt offline with no call back to Abstraxn and none to you, which is the Q8 answer. Receipts are batched into a Merkle tree whose root is published on-chain, currently on public testnets, with mainnet anchoring in active development.

Two things we do not claim, because a document with no gaps in it is the first thing a security architect discounts. Mandate expiry is stored and displayed but is not yet enforced at evaluation time, which is in active development. There is no delegation or scope-attenuation model today, so the agent-to-agent handoff in question 4 is yours to cover, not ours.

What this changes in a deal is narrow and specific. It does not make your product better. It takes the four questions you were never going to pass alone off the list of things standing between you and a signature, and it does it without adding a party your buyer has to trust, because the point of the receipt is that they do not have to trust anyone.

Frequently asked questions

Related reading

• Know Your Intent (KYI): Agents Have an Identity Layer. They Have No Intent Layer.
• Know Your Agent: The Infrastructure for Agent-Initiated Financial Actions
• AI Agent Spending Limits: How to Build a Mandate That Can't Be Overspent
• Agent Identity Verification: The Control Plane for Agentic Payments
• Who Is Liable When an AI Agent Is Right?
• We Are Building Guardrails in the Wrong Places