How to Answer Client Security Questionnaires About AI Agents

To answer a client security questionnaire about AI usage, describe what each agent does, which data it can reach, who can change it and how its actions are reviewed, then back every claim with evidence you can produce. Keep one maintained answer set so replies stay consistent, and say plainly where a control does not exist yet. Clients rarely expect perfection. They expect a clear account they can verify.

Key takeaways

• Answer from a one-page description of the agent: its role, its data, its tools, its permissions and its approval points.
• Write down what is true today, not what is planned. A candid gap with a next step builds more trust than a vague reassurance.
• Separate three topics that questionnaires blur together: data handling, access and oversight.
• Keep evidence ready for every answer: permission lists, logs, review notes and written provider terms.
• Maintain the answers as a living document, updated whenever the agent's tools, providers or permissions change.

Why are clients asking about your AI use now?

Most security questionnaires were written for software that stores data and follows fixed rules. An AI agent behaves differently. It reads documents, drafts messages, calls tools and sometimes acts on a person's behalf. A client's security, legal and procurement teams each read that differently, and each wants a different reassurance.

Security wants to know what the agent can reach and what it can do. Legal wants to know where data goes and who may use it. Procurement wants to know who is accountable. A good answer set speaks to all three without contradicting itself.

Some clients frame their questions around the [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework), and others around the [OWASP Top 10 for LLM Applications](https://genai.owasp.org/llm-top-10/). You do not need to adopt either formally to answer well. They are useful because they show the vocabulary your client's reviewer is likely to use: governance, access control, prompt injection, monitoring and incident handling.

What do these questionnaires actually ask?

Questions vary in wording, but they cluster around a small set of concerns. If you can answer these eight cleanly, you can answer most questionnaires with light editing.

• Which AI models and providers process our data, and in which regions?
• Is our data used to train or improve any model?
• What data can the agent read, write or send?
• Who can change the agent's instructions, tools and permissions?
• Which actions require a human to approve them first?
• What is logged, for how long, and who reviews the logs?
• How do you handle errors, incidents and wrong outputs?
• What happens to our data when the engagement ends?

Notice that none of these ask whether your AI is safe in the abstract. They ask for specifics about a system you operate. That is good news, because specifics are something you can document.

How do you describe data handling without overpromising?

Start with a plain data flow. Write down, in a few sentences, what information enters the agent, where it is processed, what the agent remembers afterward and where that memory is stored. If you have an architecture map of your AI stack, the data flow answer is mostly a caption for it.

Then cover four points that clients return to again and again.

First, model providers. Name the category of provider involved and what is sent to it: full documents, excerpts or only the question. If the agent retrieves company documents to answer a request, say that retrieval happens at the time of the request and that only the relevant excerpts are passed along, if that is the case. Do not say it unless you have checked.

Second, training. Clients want to know whether their material improves someone else's model. The honest answer depends on the written terms you hold with each provider, so read them before you reply. The article on whether your AI provider trains on your company data explains how to get that position in writing.

Third, location and retention. State where data is stored and processed, how long conversation logs and memory are kept, and how deletion works. If any of this is uncertain, see the notes on AI data residency for business and find out before you answer rather than guessing.

Fourth, end of engagement. Describe what is returned, what is deleted and what evidence of deletion you can provide.

A useful rule: every sentence about data should be something a colleague could verify by opening a settings page or a contract. If it cannot be verified, rewrite it as what you know and what you are confirming.

How do you explain access and human oversight?

Access and oversight are where reviewers spend the most time, because they determine what happens when something goes wrong.

For access, describe the agent as you would describe a new employee with a narrow role. It has its own identity, not a shared personal login. It has the minimum permissions needed for its job. Each tool it can use is listed, along with what that tool lets it do: read only, draft only, or act. The [OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) is a solid reference for the principles behind this, including least privilege and checking permissions on every request. If your process for reviewing these permissions is regular, say so and link the evidence. A step-by-step permission review gives you a repeatable routine to describe.

For oversight, answer three questions in order. Which actions can the agent take on its own? Which require a named person to approve first? Who is that person, and what happens if they are unavailable? Consequential actions, such as sending external messages, changing records or moving money, should sit behind approval unless there is a deliberate decision otherwise.

For monitoring, state what is recorded. Logs of requests, tool calls and outcomes let you reconstruct what happened. The [OpenTelemetry observability primer](https://opentelemetry.io/docs/concepts/observability-primer/) explains traces, metrics and logs in plain terms, and is a helpful shared vocabulary if a client's engineers ask how you observe the system.

Finally, be candid about prompt injection, where text inside a document or web page tries to steer the agent. It is a recognized risk for any system that reads untrusted content, and no one can claim to have eliminated it. The defensible answer is that you limit what the agent can do, keep consequential actions behind approval, and review its behavior. The claim you should avoid is that it cannot happen.

A step-by-step plan to build your answer set

Do this once, carefully, and each later questionnaire becomes an editing task rather than a research project.

• Name an owner. One person is accountable for the accuracy of AI answers, even if several contribute.
• List every agent and AI tool in use that touches client data or client work, including ones adopted informally by individual teams.
• For each, write a one-page profile: role, data it can reach, tools, permissions, approval points and the provider processing the data.
• Collect the written terms from each provider and note the positions on training, retention, location and deletion.
• Draft standard answers to the eight common questions above, each with a short evidence note, such as where the permission list or the log sample lives.
• Mark gaps honestly. For each, write the current state, the interim mitigation and who owns the fix.
• Have someone outside the drafting team, ideally security or legal, read the answers and challenge any sentence they cannot verify.
• Set a review trigger: update the set whenever a provider, tool or permission changes, and on a regular schedule even if nothing has.

The change trigger matters most. If your agent gains a new tool and your answer set still describes the old one, the document becomes a liability. Tie updates to your change request process so that the answer set changes in the same motion as the agent.

What does an honest answer look like in practice?

Illustrative scenario: a small services firm uses an agent that drafts replies to client emails using a shared folder of past correspondence. A client's questionnaire asks, "Can your AI access our contracts?" The first instinct is to write "No, access is restricted."

Before replying, the operations lead checks the actual folder permissions and finds that the agent's access covers the whole shared drive, which includes that client's contracts. The honest answer today is yes. So the firm narrows the agent's access to the correspondence folders, records the change, and then replies that the agent can read prior correspondence with the client for drafting purposes, cannot read contract files, sends nothing without a staff member's approval, and keeps a log of its activity. It adds the date of the next permission review to the answer's evidence note.

The lesson is that the questionnaire worked as an audit. Checking the answer improved the system. A firm that had written the comfortable answer would have had a reply on file that was untrue, which is worse than an awkward one.

How does Be Human's managed approach support this?

Be Human designs, implements and operates AI agents with identity, memory, tools and permissions kept under human control. Each engagement starts by defining one role, the memory and tools it needs, the approval boundaries and a success criterion you can observe. That definition is the same material a questionnaire asks for, so it can be reused as the basis of your answers. Managed operations can include monitoring, recurring evaluations, permission review, integration maintenance and incident response, which produce the ongoing evidence that clients ask to see. Be Human does not claim certifications or guarantees on your behalf, and your answers should describe your own controls and your own providers' terms.

Frequently asked questions

Should we mention AI use if the questionnaire does not ask? If the agent touches client data or produces client work, yes, in proportion to its involvement. Check your contract for notification terms, and consider a short note in your standard disclosures. Clients who discover undisclosed AI use later tend to react more strongly than clients who were told early.

What if the client requires a certification we do not hold? Say so directly, then describe the controls you do operate and the evidence behind them. Do not imply equivalence you cannot show. Many clients accept documented controls with a stated plan, and some will offer an alternative review.

How often should we update our answers? Update them whenever a provider, tool, permission or data location changes, and on a regular review schedule even without changes. A good habit is to review the answer set whenever the agent itself is reviewed, since the two should always describe the same system.

Can an AI agent fill in the questionnaire for us? It can produce a useful first draft from your documentation and save time. A named person must still verify every statement about security, because the agent can sound confident about things it has no way of checking. Treat its output as a draft for the owner, never as the answer of record.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.