SOC 2 AI API gateway review should start before the buyer asks for a security packet. The procurement question is not "do you have a badge?" It is whether the gateway, model routes, logs, keys, billing records, support process, and downstream providers can be matched to evidence that a security reviewer can actually inspect.
This guide is for procurement, security, platform, compliance, and vendor-risk teams evaluating an AI API gateway before production traffic. It is not legal or audit advice. Use it as a practical evidence checklist: what to request, what to verify in the SOC 2 report, what to test in the gateway, and what to keep in your own buyer-side file.
Flatkey is relevant because flatkey.ai publicly positions the product as one API gateway for production AI teams, with model access, routing, billing, usage analytics, operational controls, a dashboard, and one key for multiple providers. Flatkey's public footer also links to certificate lookup pages for VOC AI Inc. showing a SOC 2 Type II entry and an ISO 27001:2022 entry, and the current pricing API snapshot checked on June 19, 2026 returned 638 model rows across 23 vendors. Treat those as dated public evidence, not a substitute for the private SOC 2 report, signed agreement, DPA, account settings, or production log validation.
Quick Answer: What SOC 2 AI API Gateway Evidence Should Prove
A SOC 2 AI API gateway review should prove three things: the vendor's control report covers the relevant service, the gateway can produce operational evidence for your AI traffic, and your own team has controls for the responsibilities the vendor report leaves to customers.
| Review Area | Evidence To Request | What To Verify |
|---|---|---|
| SOC 2 report scope | Current SOC 2 Type II report, report period, auditor, system description, and bridge letter if the report period is stale. | The AI gateway, API routing, logging, support, billing, and relevant infrastructure are inside the system boundary. |
| Trust Services Criteria | Categories covered by the report, commonly security plus any availability, confidentiality, processing integrity, or privacy criteria. | The covered categories match the buyer risk. Do not assume privacy or availability are covered unless the report says so. |
| Complementary user controls | CUECs and buyer responsibilities listed in the SOC 2 report. | Your team can satisfy key management, route approval, data classification, user access, retention, and incident responsibilities. |
| Subservice organizations | Carve-out or inclusive subservice organization description, provider list, and monitoring controls. | Downstream model providers, cloud services, support tools, observability, and billing vendors are handled consistently with the report model. |
| AI gateway operations | Sample logs, key ownership fields, route-change history, model-provider route inventory, and incident export process. | The gateway can show who sent traffic, which model/provider received it, what changed, and what evidence is retained. |
| Data and privacy | Privacy policy, DPA path, data-processing locations, retention policy, payload logging policy, and provider data-use terms. | Prompts, outputs, metadata, support materials, and billing records have clear handling rules. |
| Buyer-side evidence | Your own rollout record, approved use cases, key taxonomy, route policy, logging mode, and review cadence. | The vendor evidence is tied to how your team will actually use the gateway. |
Start With The SOC 2 Scope, Not The Badge
A public badge can be useful for initial screening, but procurement should still request the actual SOC 2 report under the vendor's trust process. The AICPA describes SOC 2 reporting as an examination of controls at a service organization relevant to security, availability, processing integrity, confidentiality, or privacy. That means the useful procurement question is scope: which system, service, date range, criteria, controls, exceptions, and management assertions are covered?
For a SOC 2 AI API gateway, the scope review should answer:
| Scope Field | Buyer Question | Why It Matters For AI API Traffic |
|---|---|---|
| Legal entity | Which entity is named in the report and contract? | Flatkey's public certificate lookup refers to VOC AI Inc.; your procurement file should match the contracting entity and service owner. |
| System boundary | Does the report cover the AI gateway, API routing, dashboard, keys, billing, usage records, and support process? | A report for a broader data or analytics platform may not prove the specific gateway workflow you plan to use. |
| Report period | What date range did the Type II report test, and is a bridge letter needed? | Procurement usually wants current operating evidence, not only a historical point-in-time statement. |
| Trust categories | Which Trust Services Criteria are covered? | Security coverage does not automatically mean availability, confidentiality, processing integrity, or privacy coverage. |
| Exceptions | Were any controls qualified, excepted, or remediated? | Exceptions can affect key management, logging, change control, incident response, or vendor monitoring. |
| Subservice organizations | Which cloud, provider, support, observability, and payment services are carved out or included? | AI gateway risk often depends on downstream model and infrastructure providers. |
The practical rule is simple: if a buyer cannot tie the SOC 2 report to the exact gateway service and traffic path, the report is screening evidence, not final procurement evidence.
Map SOC 2 Criteria To AI Gateway Controls
The AICPA Trust Services Criteria cover security, availability, processing integrity, confidentiality, and privacy. A SOC 2 AI API gateway evidence packet should translate those broad categories into concrete gateway checks.
| Control Topic | Evidence To Verify | Related SOC 2 Concern |
|---|---|---|
| API key ownership | Keys are tied to owners, environments, apps, and workflows; key creation and revocation are auditable. | Logical access, accountability, change control, and incident containment. |
| Route and model approval | Approved providers, endpoint families, model rows, fallback rules, and change records are reviewable. | Change management, vendor monitoring, processing integrity, and confidentiality. |
| Audit logs | Logs show timestamp, key or project, route, provider, model, endpoint family, status, error class, usage units, and administrative changes. | Monitoring, incident response, access review, and operational evidence. |
| Payload handling | Prompt/output logging mode, redaction, access restriction, retention period, and deletion path are documented. | Confidentiality, privacy, and data minimization. |
| Usage and billing | Usage records and billing records are separated from raw payloads and tied to owner, model, route, and cost center. | Processing integrity, accountability, and financial review support. |
| Incident review | Security events, provider failures, suspicious usage, leaked keys, fallback loops, and over-limit events have a runbook and export path. | Security monitoring, response, and remediation. |
| Vendor and provider changes | Provider additions, removals, regional changes, and data-use policy changes trigger re-review. | Subservice organization monitoring and risk assessment. |
This is where AI gateways differ from generic API gateways. The route is not just a host/path decision. It can determine which model provider sees prompts, which data policy applies, which retention rule applies, which fallback path is allowed, and which usage unit is billed.
Flatkey Evidence To Verify Before Procurement
Flatkey has useful public evidence for an initial SOC 2 AI API gateway review. The public site says Flatkey unifies model access, routing, billing, usage analytics, and operational controls for teams shipping AI products. The footer links to a Cert Assure SOC 2 Type II lookup for VOC AI Inc., certificate `USA-SOC2-220513`, with a listed period from July 15, 2025 to July 14, 2026 and an active status at the time checked. The same footer links to an ISO 27001:2022 lookup for VOC AI Inc., certificate `USA-I-270513`, with a listed period from May 1, 2024 to April 30, 2027 and an active status at the time checked.
Use those public pages as the start of the file, then verify these details directly with Flatkey before procurement:
| Flatkey Check | What To Capture | Guardrail |
|---|---|---|
| SOC 2 report request | Current report, auditor, period, scope, covered criteria, exceptions, subservice organizations, and bridge letter if needed. | Do not rely on the public badge or certificate lookup alone. |
| ISO 27001:2022 cross-check | Certificate entity, activity scope, dates, and any statement of applicability or security overview available under trust review. | ISO certification supports an ISMS review, but it does not replace the SOC 2 report or AI-route validation. |
| Catalog and endpoint support | Current model row, provider, endpoint family, availability status, and pricing unit from Flatkey pricing. | Model counts, vendor counts, and availability can change; verify on the day you approve the route. |
| Dashboard evidence | Key owner, route, model, provider, status, usage unit, billing record, and any export path in the current Flatkey dashboard. | Do not assume exact dashboard labels from public marketing copy. |
| Logs and retention | Metadata fields, payload logging behavior, retention period, viewer permissions, support-data handling, and deletion/export process. | Flatkey's public privacy policy mentions request metadata, error records, usage records, necessary logs, and support materials, but a buyer needs account-specific terms. |
| Provider route policy | Approved providers, fallback constraints, provider data-use terms, and who can change routes. | Reliability fallback can become a vendor-risk change if the downstream provider changes. |
How To Test The Gateway Before Security Signoff
Do not wait for live customer traffic to discover whether your SOC 2 AI API gateway evidence is complete. Run a controlled smoke test per route and save the review packet.
- Create non-secret route identifiers: use separate keys or projects for staging, production, batch, customer-facing, and evaluation traffic.
- Pick one low-risk model route: record provider, model row, endpoint family, pricing unit, and expected data class.
- Send a harmless test request: avoid real customer data, personal data, secrets, or regulated content.
- Review the log record: confirm timestamp, key/project, owner, route, provider, model, status, usage units, error class, and cost visibility.
- Review administrative evidence: confirm who created the key, who approved the route, who can change fallback, and where changes are logged.
- Test a denial path: try a disallowed model, blocked data class, expired key, or quota boundary and save the result.
- Document retention: identify where metadata, payloads if any, support tickets, billing records, and security logs are retained.
- Attach procurement documents: SOC 2 report, bridge letter, ISO evidence, privacy policy, terms, DPA path, provider review, and your rollout note.
- Repeat on changes: rerun the packet when provider, model, endpoint family, fallback, data class, logging mode, or contract terms change.
- Separate public and private evidence: public pages help screen; private report and account-specific validation close procurement.
SOC 2 Is Only One Layer Of AI Gateway Review
A SOC 2 AI API gateway review should sit beside ISO 27001, GDPR, application security, and vendor-risk checks. These frameworks are related, but they answer different questions.
| Framework Or Source | What It Helps Verify | What It Does Not Prove By Itself |
|---|---|---|
| SOC 2 | Independent examination of controls for the described system and covered Trust Services Criteria during the report period. | It does not prove every Flatkey feature, customer account setting, downstream model route, or buyer workflow is covered. |
| ISO/IEC 27001:2022 | Information security management system scope, risk management, and certification status. | It does not replace a SOC 2 report or prove a specific AI request log schema. |
| GDPR | Processor review, security of processing, data minimization, retention, transfer safeguards, and role mapping for personal data. | It does not become satisfied just because a gateway is SOC 2 reviewed. |
| OWASP logging guidance | Practical log design, event attributes, data to exclude, protection of logs, and monitoring concerns. | It does not define your vendor's retention policy or prove your prompt/output handling is acceptable. |
| Buyer controls | Your key taxonomy, user access, route approval, data classification, model fallback, retention, and incident review. | They do not replace vendor controls; they make the vendor evidence usable in your environment. |
Use Flatkey's adjacent enterprise AI API gateway checklist for the broader procurement stack and audit logs for AI API usage for evidence fields that security teams typically ask for.
Procurement Evidence Packet Template
The most useful output from a SOC 2 AI API gateway review is a compact packet that sales engineering, security, legal, and platform teams can all read.
| Packet Section | Fields To Include | Owner |
|---|---|---|
| Vendor identity | Legal entity, contracting entity, support contact, trust portal path, certificate lookup links, and current status. | Procurement |
| SOC 2 file | Report type, period, auditor, system boundary, Trust Services Criteria, exceptions, subservice organizations, CUECs, and bridge letter. | Security |
| Gateway route file | Approved providers, models, endpoint families, fallback rules, data classes, route owner, and change approver. | Platform engineering |
| Log and evidence file | Request metadata fields, administrative logs, payload policy, retention class, export method, and viewer access list. | Security operations |
| Data protection file | DPA path, privacy policy, terms, provider data-use review, processing locations, subprocessor list, and GDPR role notes. | Legal and privacy |
| Buyer-side controls | Key taxonomy, access review cadence, route-change process, quota policy, incident runbook, and re-review triggers. | Platform and governance |
| Launch approval | Final approver, approved use cases, blocked data classes, launch date, review date, and residual risks. | Security and product |
Red Flags During Review
Pause procurement if the SOC 2 AI API gateway evidence leaves these gaps unresolved:
- Badge-only answer: the vendor points to a badge but cannot provide the current SOC 2 report under NDA or trust access.
- Scope mismatch: the report covers a different product, entity, infrastructure boundary, or time period than the gateway being procured.
- No CUEC plan: the report lists customer responsibilities, but the buyer has not assigned them internally.
- Opaque subservice organizations: downstream model providers, support tools, logging tools, or cloud providers are not clearly handled.
- No route-change evidence: the team cannot show who added a provider, changed a model, or enabled fallback.
- Payload logging ambiguity: prompts and outputs may be stored, but retention, access, and deletion are unclear.
- Dashboard-only proof: screenshots exist, but there is no exportable or reviewable evidence file for security review.
- No re-review trigger: new models, regions, endpoint families, and provider policy changes can happen without procurement/security review.
FAQ
What is SOC 2 AI API gateway evidence?
SOC 2 AI API gateway evidence is the set of documents, logs, route records, control mappings, and buyer-side notes that show how an AI gateway's controls support procurement review. It includes the vendor SOC 2 report, scope review, subservice organization handling, audit logs, key ownership, route approvals, retention policy, and customer responsibilities.
Is a SOC 2 badge enough to approve an AI API gateway?
No. A badge can help with initial screening, but procurement should verify the current SOC 2 report, covered system, report period, criteria, exceptions, subservice organizations, and complementary user entity controls. The private report and the buyer's route test matter more than the badge alone.
Should SOC 2 cover every model provider behind a gateway?
Not necessarily. SOC 2 reports describe the service organization's system and how subservice organizations are handled, often through carve-out or inclusive methods. Buyers should verify how model providers, cloud services, support tools, and observability services are represented, then review each provider's own data and security terms.
How do SOC 2 and GDPR connect for an AI API gateway?
SOC 2 can support security-control evidence, while GDPR review focuses on processing roles, lawful basis, data minimization, processor terms, transfers, retention, and data-subject rights. A SOC 2 AI API gateway can centralize useful evidence, but it does not automatically resolve GDPR obligations.
What should I verify in Flatkey before buying?
Verify Flatkey's current SOC 2 report, ISO 27001 certificate details, legal entity, signed terms, DPA path, model/provider route, endpoint family, dashboard evidence fields, log retention, payload handling, support-data handling, and fallback behavior. Also confirm the current model row and pricing unit on the day you approve production use.
Final Procurement Step
Before you approve a SOC 2 AI API gateway, build the evidence packet the same way an auditor or enterprise buyer will inspect it: entity, report scope, criteria, period, exceptions, subservice organizations, logs, access controls, route changes, data handling, and customer responsibilities. Flatkey can centralize model access, routing, usage visibility, and operational controls, but your procurement file should still verify the current report and the exact route you will run.
Get a key when you are ready to centralize model access, routing, usage visibility, and buyer-review evidence behind one AI API gateway.
