The Enterprise Security Questionnaire for AI Agents: 10 Questions Buyers Ask, and Evidence to Answer Them

A year ago, the security questionnaire that arrived with an enterprise deal asked about encryption at rest, SSO and your penetration test. Today it has a new section: “Describe how your AI agents authenticate to our systems, what they are permitted to do, and how their actions are recorded.”

Teams that answer with a paragraph of intent (“agents follow least privilege”) lose weeks in security review. Teams that answer with evidence close faster. This post lists the ten questions we see most often, what a weak answer looks like, and the evidence that makes a strong one. It applies whether your agents connect through MCP, talk to other agents over the A2A protocol, or call plain REST APIs.

Why buyers are asking now

Security teams have read the same incident write-ups you have: agents that deleted data they were never meant to touch, agents tricked by hidden instructions in a tool result, agents holding long-lived keys that ended up in logs. We cover several in six AI agents gone wrong. Their conclusion is consistent: an agent is a new kind of caller, and the existing vendor questionnaire does not describe it.

So the questions are shifting from “do you have a policy?” to “show me the control.” Each question below is paired with the artifact that answers it.

The ten questions

1. Does each agent have its own identity?

Weak answer: “Agents use our service account.”

Strong answer: every agent has a distinct principal and OAuth client, so an auditor can list agents, see who owns each one and revoke one without touching the rest. Shared service accounts fail the non-human identity governance test and make SOC 2 access reviews impossible to evidence. See SOC 2 for AI agents.

Evidence: an export of agent principals with owner, creation date and last use.

2. Do agents ever hold our credentials?

Weak answer: “Keys are stored encrypted.”

Strong answer: agents reference a credential by name; a broker resolves it server-side at call time, so the model, its logs and its memory never contain the secret. This is the single control reviewers care about most, because it removes the most common failure: a key pasted into a prompt, a log or a tool argument.

Evidence: a request trace showing a credential reference going in and no secret value coming back out.

3. How is the login handshake secured?

Buyers want to know how an agent proves who it is and who it acts for. Good answers name the mechanism: OAuth 2.1 with PKCE for interactive MCP clients, client credentials for headless agents, short-lived tokens, refresh-token rotation and audience-bound tokens so a token minted for one server cannot be replayed against another. We compare the options in login handshake procedures for AI agents and explain the audience rule in MCP token passthrough.

Evidence: your published OAuth discovery metadata and token lifetimes.

4. How do you limit what an agent can do?

Weak answer: “The prompt tells it not to.”

Strong answer: limits are enforced outside the model. A policy is evaluated on every call (allowed hosts, methods, paths, rate limits), and it fails closed when the policy cannot be evaluated. A prompt is a suggestion; a policy is a gate. See testing that guardrails fail closed.

Evidence: the policy document for a sample agent and a denied-request log entry.

5. Which actions need a human?

Reviewers expect sensitive actions (payments, deletions, permission changes) to pause for approval, and they expect the agent not to be able to approve its own request. They also ask how you avoid rubber-stamping; see approval fatigue.

Evidence: an approval record showing requester, approver and outcome.

6. How do you handle prompt injection and tool poisoning?

Nobody expects you to claim immunity. A credible answer assumes the model will sometimes be fooled and limits what a fooled agent can do: scoped credentials, per-call policy, response sanitization and approvals. Read indirect prompt injection and credential containment and MCP tool poisoning.

Evidence: a description of blast radius: “if this agent is hijacked, it can call these three endpoints, at this rate, with this data redacted.”

7. How do A2A and MCP connections get trusted?

If your agents discover other agents or MCP servers, buyers ask what stops a spoofed Agent Card or a swapped tool schema. Strong answers mention verified discovery, pinned or reviewed tool definitions and authenticated push notifications. See Agent Card spoofing, MCP rug pulls and A2A webhook authentication.

Evidence: your list of approved agents and servers, and how a change is reviewed.

8. Can you reconstruct what an agent did?

The question is usually phrased as “if there is an incident, how quickly can you tell us exactly what happened to our data?” A strong answer ties together the agent, the user it acted for, the policy decision, any approval and the outcome, with a trace ID that survives hops between agents. See agent incident forensics and trace propagation across A2A and MCP.

Evidence: a worked example of a single action traced end to end.

9. Who owns the data the agent touches?

Buyers want assurance that their data is not retained in model memory, copied into prompts you do not control or sent to a third party beyond what is needed. Answers should cover response sanitization, retention and deletion. See agent data egress and agent memory and data ownership.

Evidence: a data-flow diagram and your retention settings.

10. How do you stop one agent, fast?

A kill switch, credential revocation and a runaway-spend cap. Reviewers ask how long it takes and who can do it. See agent kill switches and runaway agent spend.

Evidence: a documented runbook and the time it took in your last drill.

The business case: evidence is a sales asset

Every one of those answers is faster to give when the controls live in one layer instead of being re-implemented inside each agent. The commercial effects are concrete:

• Shorter security reviews. Exported principals, policies and traces replace weeks of email back and forth.
• Fewer custom builds. One governed integration path beats a bespoke credential scheme per customer. We weigh the trade-off in build vs buy for an AI agent credential proxy.
• Access to regulated buyers. Finance, health and the public sector ask about the EU AI Act and ISO 42001 first.
• Lower incident cost. When something does go wrong, a joined audit trail turns a week of guessing into an afternoon of reading.

How Fullmakt fits

Fullmakt is a credential broker and governance layer for AI agents. It produces much of the evidence above as a by-product of normal operation:

• Agent principals and OAuth clients give each agent its own identity.
• Credential references keep upstream secrets in a vault or environment backend; the agent never sees the value.
• Per-call policy with approvals for sensitive actions, which an agent cannot grant itself.
• Signed envelopes bind a request to its exact arguments to resist replay.
• MCP and A2A surfaces so agents connect through standard protocols.
• Audit history recording requests and decisions in one place.

You still own your threat model and your answers. The broker makes them provable.

Checklist

• [ ] Each agent has its own principal and a named owner.
• [ ] No upstream secret is ever visible to the model or its logs.
• [ ] Tokens are short-lived and audience-bound.
• [ ] Policy is evaluated per call and fails closed.
• [ ] Sensitive actions require a human the agent cannot impersonate.
• [ ] Approved MCP servers and A2A agents are listed and change-reviewed.
• [ ] One action can be traced from user to outcome in minutes.
• [ ] You can revoke one agent without an outage for the rest.

FAQ

What do enterprise buyers ask about AI agent security? They ask how each agent authenticates, whether agents hold customer credentials, what actions are permitted, which require human approval, how prompt injection is contained and how every action is logged and traced.

How should I answer an AI agent security questionnaire? Answer with evidence, not intent: an export of agent identities, a sample policy, a denied-request log entry, an approval record and a traced example action. Name the mechanism (OAuth with PKCE, audience-bound tokens, fail-closed policy) rather than the principle.

Do MCP and A2A change the questionnaire? They add questions about discovery and trust: how Agent Cards and tool definitions are verified, how changes are reviewed and how delegation is recorded across hops.

Is a credential broker required to pass security review? No standard mandates one, but keeping secrets out of agents, enforcing policy per call and keeping a joined audit trail is much easier with a single broker layer than with controls scattered across agents.

How does Fullmakt help with security questionnaires? Fullmakt gives each agent its own principal, keeps upstream credentials behind references, evaluates policy and approvals per call and records an audit history, which supplies the identity, access and traceability evidence buyers request.

See how Fullmakt brokers credentials for AI agents or browse the Fullmakt blog.