What Your Buyer's Security Questionnaire Is Actually Asking About Your Agents

Short answer: Enterprise security reviews now ask six things about AI agents. Can you show what the agent did? Is each customer's policy isolated? Why was an action allowed? Can high-risk actions require approval? What can the agent access? Can rules be adapted without a custom build? Each question needs evidence a reviewer can open, such as a log, a policy or an approval record, not an assurance.

The security questionnaire used to be familiar territory: encryption, SSO, incident response, a SOC report. Now a new section shows up with oddly phrased questions. "Describe how agent actions are monitored." "How is customer policy separated?"

The reviewer isn't asking whether you take security seriously. They're asking what they can show their own auditors when an agent does something unexpected in their environment. "We follow industry best practices" gives them nothing to show, and the review can stall.

The wording varies by buyer, but the intent is consistent. Here are the six questions, what each is really asking, and the evidence that answers it.

Each reviewer question is answered by one piece of evidence

Every answer on the right is something a reviewer can open and inspect, not a statement of intent.

1. "Can you show us exactly what the agent did?"

What they're asking: Can you reconstruct an agent's behavior after the fact, step by step?

• Vague answer: "We log all activity."
• Defensible evidence: An action-level record for every step. It shows which agent and version, acting for which user, called which tool, with what parameters, touching which data, and the outcome.

A prompt-and-response transcript isn't enough. The action is what reaches the buyer's systems, so the action needs the record. Test it by picking one real ticket and replaying what the agent did, in order.

2. "Can one customer's policy or data affect another's?"

What they're asking: In a multi-tenant product, can another customer's configuration change what the agent does for me?

• Vague answer: "Tenants are logically separated."
• Defensible evidence: Policy scoped per tenant, enforcement that evaluates every action with the tenant in context, and logs separable by tenant.

The pattern to avoid is per-customer instructions appended to a shared prompt, where one tenant's text sits beside another's rules. You should be able to show that customer A's rule set has no path to the agent's behavior for customer B.

3. "Why was this action allowed?"

What they're asking: When something goes wrong, can you explain the decision, not just the outcome?

• Vague answer: "The model was instructed not to do that."
• Defensible evidence: A decision attached to each action, meaning allowed, blocked or escalated. It names the rule that matched and the inputs that rule evaluated.

You are not explaining the model's inner reasoning. You are explaining why the action was permitted to proceed. A rule-based check gives the same answer on the same input, which is exactly what a reviewer wants.

4. "Can we require approval for high-risk actions?"

What they're asking: Can a human stand between the agent and the actions we consider dangerous, and can we choose which ones?

• Vague answer: "The agent asks for confirmation when it's unsure."
• Defensible evidence: Approval triggered by a rule, not by the model's sense of doubt, because a model that is confidently wrong never asks. Show a defined approver role, a request carrying the exact parameters, and a recorded decision naming who approved or denied it.

The buyer sets the thresholds that matter to them.

The model never decides whether to ask. A rule decides, and the decision is recorded either way.

5. "What can the agent access, and how do you limit it?"

What they're asking: What is the blast radius if this agent misbehaves?

• Vague answer: "It only accesses what it needs."
• Defensible evidence: An inventory of the tools, APIs and data sources each agent can reach, scoped permissions per agent, and no access by default until granted.

Least privilege is a claim until you can hand over the list. It also has to hold outside the agent's prompt, because a prompt is a request, not a restriction. (See Your Agent Read the Policy. It Doesn't Have to Follow It.)

6. "How do we adapt rules to our own compliance requirements?"

What they're asking: Will you build us a special version?

• Vague answer: "We can customize for enterprise customers." Reviewers hear a services engagement and a branch of your codebase.
• Defensible evidence: Customer-configurable policy on top of one shared product. Rules are designed to change without redeployment, and changes are versioned so you can show what applied when.

Choose your words carefully here. You can offer evidence to bring to their review. You can't promise their compliance.

What separates defensible evidence from a vague assurance?

The same actions can produce two very different records, depending on who writes them.

Checklist before your next security review

• Can you produce an action-level record for one agent run during the review call?
• Can you show that policy and logs are scoped to a single tenant?
• Does each action record carry its decision and the rule behind it?
• Which actions require approval, who approves, and where is that recorded?
• Can you list every tool and data source each agent can reach?
• Can a customer change their rules without a code change on your side?

If an answer is "we'd need to check," that's your backlog.

Where Skyrelis fits

Skyrelis builds the runtime policy layer for AI agents. It sits in front of agent traffic rather than inside agent code, so there is no SDK and no code instrumentation. The change is to the routing path, which we confirm for your environment. Deploying in 30 minutes is the typical case. It applies policy to agent actions, supports approvals for high-risk ones, and keeps a replayable record of each decision. That gives you a control and a record to bring to the review. If these six questions keep coming up, it's worth a look.

FAQ