What security reviewers ask about AI gateways

An AI gateway gets a harder security review than most software a company buys, and it should. It sits in the path of every model call, holds the credentials for the organization's provider accounts, and can see every prompt that passes through. The review is also newer than most: the Cloud Security Alliance's CAIQ describes itself as a set of yes/no questions for documenting the controls in cloud services¹, but it was not written with model traffic in mind, so reviewers add their own questions on top.

This checklist collects those questions by domain. For each, it says what a strong answer contains and what should make a reviewer probe further. It is written for both sides of the table: reviewers can use it as a question set, and vendors can use it to find the answers they cannot yet give.

Data flow and subprocessors

Everything else depends on knowing where data goes. Under the GDPR a controller may use only processors providing sufficient guarantees of appropriate measures, and a processor may not engage another processor without the controller's prior authorization, with notice of changes and a chance to object².

• Which requests pass through the gateway, and which data does it store about each?
• Which infrastructure vendors process that data, where, and with how much notice before a new one is added?
• Are the AI providers the vendor's subprocessors, or the customer's own providers under the customer's own agreements?
• Do retries and fallbacks send the same input to additional providers, and are those listed?

A strong answer is a named subprocessor list stating what each vendor can see and where it runs, plus a data-flow statement that includes fallback targets. A red flag is a residency claim that a single request could falsify — for example, a regional hostname in front of processing that is not actually region-constrained.

Credentials

• How are provider credentials encrypted at rest, under which key, and where does that key live?
• Can a stored credential be displayed again, by the customer or by the vendor's staff?
• What prevents a sealed credential being moved to another tenant's record?
• How are the vendor's own API keys stored, and how fast does revocation take effect?
• Can the encryption key be rotated, and what happens to stored credentials when it is?

Good answers name the algorithm and the key's location, and say that no interface returns a stored secret. Article 32 of the GDPR lists encryption among the appropriate measures for security of processing³; the useful follow-up is what the encryption is bound to. See BYOK gateway architecture for the design detail.

Content capture and retention

• Are prompts and completions stored by default? On which plan, if any, is capture on by default?
• What retention windows exist, and is expired content deleted or only hidden?
• Who can read captured content — which customer roles, and which vendor staff?
• Do exports and telemetry ever include content?
• Does the vendor train on customer content, and where is that commitment enforceable?

A strong answer separates metadata from content, says capture is off by default, and points to the clause in the terms or DPA that carries the no-training commitment, since that commitment is a policy rather than a mechanism. See the logging policy checklist.

Identity, access and audit

• Is multi-factor authentication available to customer users, and can an organization require it?
• Is SAML or OIDC single sign-on supported, and does SCIM deprovision leavers?
• What roles exist, and can a role be scoped to billing, read-only analysis or key management?
• Are configuration changes audited with actor and timestamp, and can the audit log be altered?
• How do the vendor's own staff authenticate, and is a second factor required for sensitive actions?

The strongest audit answer describes an enforcement mechanism — rows the database refuses to update or delete — rather than a statement that logs are kept.

Isolation and platform security

• Is the service multi-tenant, and is isolation logical or physical?
• How is the tenant derived for each request — from the session, or from request input?
• Which security headers are set on the web surfaces, and can the reviewer verify them?
• Are outbound webhooks signed, and how are signing secrets rotated?

Some of these can be tested in minutes. curl -I shows the headers. A revoked key, a denied model and an export that should not contain content can each be tried in a trial account.

Certifications, testing and incidents

• Which certifications or attestations are held today, and which are in progress with an engaged auditor?
• Has an independent penetration test been performed, and when?
• What is the breach-notification commitment, and in which document is it enforceable?
• Are incident runbooks written down, and will the vendor walk through one?

A vendor early in its life often cannot show a SOC 2 report. The honest answer says so, says whether an audit firm is engaged, and does not describe a roadmap item as held. A reviewer whose process cannot proceed without a report should treat that as a reason to wait, not something to negotiate around.

Availability and location

• Is there a published uptime commitment, and on which plans?
• Where does processing happen, and is region-constrained processing offered and enforced?
• Is a self-hosted or single-tenant deployment available?
• What happens to traffic if the gateway itself is unavailable?

AI-specific questions

The OWASP Top 10 for LLM Applications 2025 gives reviewers a shared vocabulary for model risks, from prompt injection to unbounded consumption⁴, and the NIST AI Risk Management Framework's Govern, Map, Measure and Manage functions give a structure for asking how the vendor manages them⁵.

• Which OWASP LLM risks does the gateway claim to reduce, and by what mechanism?
• Are content checks classifiers or patterns, and what do they not detect?
• Can model use be restricted by organization, project and key, including fallback targets?
• Can spend be capped per key, per project and per end customer?
• Does using the product make the customer compliant with any regulation? (The correct answer is no.)

How INFRO answers these questions

INFRO publishes its answers at /trust and as a downloadable security questionnaire generated from the same source, so the two cannot disagree. The DPA and the subprocessor list are public.

The short version, as those pages state it: