Enterprise Controls and TrustJuly 11, 2026Flatkey Team

SOC 2 AI API Gateway Scope: What the Report Should and Should Not Prove

Use this SOC 2 AI API gateway scope checklist to separate what a report can prove from route, provider, logging, retention, and buyer-owned follow-up evidence.

A SOC 2 AI API gateway scope review should not start with the badge. It should start with a simple question: what system, period, controls, dependencies, and buyer-owned responsibilities did the report actually cover?

That distinction matters for model routing. An AI API gateway can sit between your application and multiple model providers, endpoint families, logs, support workflows, billing records, and fallback paths. A SOC 2 Type 2 report can be useful evidence for the gateway vendor's described system and covered trust services criteria. It should not be treated as proof that every upstream model provider, every route, every prompt-retention setting, every buyer account configuration, or every future model change is approved.

Use this SOC 2 AI API gateway scope checklist when procurement, security, legal, and platform engineering need to decide what the report should prove, what it should not prove, and what follow-up evidence belongs in the approval packet.

Flatkey is relevant to this review because the current public site positions flatkey.ai as an AI API gateway and model operations platform for routing official GPT, Claude, Gemini, and other model traffic through one key, with dashboard, billing, routing, usage, and operational evidence surfaces. Flatkey public pages and certificate lookup pages are dated screening evidence only. For production approval, ask for the private SOC 2 report, signed contract/DPA where applicable, account settings, route configuration, and support confirmation for the workload you will run.

For broader procurement context, pair this article with the SOC 2 AI API gateway evidence checklist, the AI gateway procurement evidence packet, and the AI API vendor risk assessment.

SOC 2 AI API Gateway Scope: Quick Decision Table

The first page of the review should separate report evidence from buyer follow-up evidence.

Review area	What the SOC 2 report should help prove	What it should not prove by itself
Legal entity	Which service organization was examined	That every affiliate, reseller, or upstream model provider is covered
System boundary	Which platform, services, locations, infrastructure, people, and processes are in the described system	That every dashboard feature, endpoint family, customer route, or future integration is in scope
Report period	The period covered by the Type 2 examination	That current controls are unchanged after the period ended
Trust services categories	Which criteria were covered, such as security, availability, confidentiality, processing integrity, or privacy	That categories not selected were examined
Controls tested	Which controls the auditor tested and the results for the period	That buyer configuration, route policy, or workload data class was tested
Exceptions	Whether control exceptions were noted and how management responded	That exceptions are immaterial to your specific workload
Subservice organizations	Whether major dependencies are included, carved out, or handled by other reports	That upstream model-provider retention, training, logging, or regional behavior is covered
CUECs	Which complementary user entity controls the buyer must operate	That the vendor is responsible for buyer key storage, redaction, provider allowlists, or app-level data classification

This is the core SOC 2 AI API gateway scope rule: the report is evidence about a described service organization system during a defined period. It is not a blanket approval for every AI route your team may create.

Lock The Five Scope Fields Before Reading Controls

Do not start by scanning for a clean opinion. Start with five fields.

Field	Buyer question	Evidence to save
Entity	Who is the audited service organization?	Report cover page, legal entity, contract counterparty, certificate lookup if public
System	What services, infrastructure, teams, processes, and data flows are included?	System description, product/service list, system boundary diagram
Period	What Type 2 period did the report cover?	Start date, end date, bridge letter if needed
Criteria	Which trust services categories were included?	Security, availability, processing integrity, confidentiality, privacy scope
Dependencies	Which subservice organizations and CUECs affect the opinion?	Inclusive/carve-out method, subservice list, buyer control list

For an AI gateway, the system field deserves the most attention. "API gateway" can mean base URL routing only, or it can also include dashboard access, model catalog, account balance, usage metering, request logs, alerting, support workflows, incident response, and key management. The private report should tell you what was in the system description. If it does not, ask the vendor to map the report scope to the exact route you plan to use.

What A SOC 2 Report Should Prove For An AI Gateway

A scoped SOC 2 Type 2 report should help a buyer answer these questions.

Proof area	Useful SOC 2 evidence	AI gateway translation
Control design and operation	Controls tested over the report period	Whether access, change management, monitoring, incident response, vendor management, and related controls operated for the described gateway system
Availability scope	Availability criteria, SLA-adjacent monitoring, incident processes if included	Whether the covered service had defined monitoring and response controls, not whether each model provider will stay available
Confidentiality and privacy scope	Criteria and controls if these categories are included	Whether customer data handling controls were examined for the described system, not whether every provider feature has the same retention setting
Change management	Tested release, approval, and change controls	Whether gateway code/config changes were controlled, not whether a buyer-approved route cannot be changed by the buyer later
Access controls	Workforce access, privileged access, admin review, account management controls	Whether vendor-side access was controlled, not whether the buyer stored API keys safely
Logical security	Authentication, authorization, logging, vulnerability, and monitoring controls	Whether the gateway's described security controls existed, not whether buyer apps redact secrets before sending prompts
Vendor management	Subservice organization and vendor monitoring controls	Whether vendor dependencies were managed, not whether every upstream provider's SOC 2, DPA, or retention setting covers your route

This is where SOC 2 AI API gateway scope becomes practical. The report may support vendor-risk screening. It still has to be translated into route facts: endpoint family, data class, provider allowlist, fallback policy, prompt/output logging, metadata retention, support access, and deletion path.

What The Report Should Not Prove

The most common procurement error is letting a SOC 2 report stand in for decisions it was not designed to make.

Do not use the report alone to prove:

Claim	Why it needs follow-up
"All model providers are covered."	Upstream providers may be subservice organizations, carved out, or outside the gateway report. Ask for the provider map and applicable provider evidence.
"No prompts or outputs are stored anywhere."	Gateway logs, provider abuse-monitoring logs, application state, support tickets, and backups can have different retention behavior.
"No training applies to every route."	Training and retention commitments are often provider-, account-, endpoint-, and feature-specific. Save account-level proof.
"Fallback is approved."	A fallback route can send data to a different provider or region. The approval record should name allowed fallback providers.
"The buyer's app is compliant."	SOC 2 is about the service organization's controls. Buyer redaction, key storage, data classification, and app access controls are buyer responsibilities.
"Privacy or DPA review is done."	SOC 2 is not a signed DPA, data transfer assessment, privacy notice, BAA, or regional processing commitment.
"Current state is identical to the report period."	The report period may have ended months ago. Ask for bridge letters, current policies, current route config, and recent evidence.
"Pricing, model availability, and SLA outcomes are guaranteed."	Model catalogs, prices, provider rate limits, and third-party availability can change outside the SOC 2 report.

If a vendor says "SOC 2 covers that," ask them to point to the exact section, system boundary language, covered criterion, control, test result, and any CUEC or subservice organization note.

Read Subservice Organizations Before You Approve Providers

An AI gateway can depend on cloud hosting, payment systems, analytics, support tooling, observability vendors, security tools, and upstream model providers. The SOC 2 report should explain how subservice organizations are handled. Buyers usually see one of two approaches:

Method	What it means for the buyer
Inclusive method	The subservice organization's relevant controls are included in the report scope. Review which controls are included.
Carve-out method	The subservice organization is excluded from the report scope. Review separate evidence and the complementary subservice organization controls.

For model routing, carve-outs matter. A gateway's SOC 2 report may cover the gateway's vendor management controls while leaving OpenAI, Anthropic, Google, or another upstream provider outside the audited system. That does not make the report useless. It means the SOC 2 AI API gateway scope review must include a provider evidence row for each approved route.

Provider documentation shows why this cannot be inferred. OpenAI's API data controls separate abuse-monitoring logs, application state, Zero Data Retention, Modified Abuse Monitoring, and endpoint-specific behavior. Anthropic's API data-retention documentation explains that different APIs and features have different storage needs and that ZDR is an arrangement customers request for eligible use cases. Cloudflare's AI Gateway logging documentation shows how a gateway can expose prompts, responses, provider, timestamp, token usage, cost, duration, DLP actions, and payload-level logging controls. Those are examples of control surfaces a buyer should inspect for any gateway route, not claims about Flatkey's private report.

Treat CUECs As Buyer Work, Not Boilerplate

Complementary user entity controls are not filler. They are the controls the buyer must operate for the service organization's controls to make sense.

For an AI gateway, common buyer-side CUEC work includes:

Buyer-owned control	Evidence to keep
Key storage and rotation	Secret manager path, owner, rotation date, emergency rotation runbook
Route approval	Approved endpoint families, provider allowlist, fallback policy, data classes
Prompt redaction	Application-level redaction rules, test transcript, blocked field examples
Access review	Admin list, key owners, offboarding record, dashboard access review
Logging policy	Whether prompts and outputs are stored, metadata-only rule, retention schedule
Usage monitoring	Budget owner, quota settings, alert thresholds, finance review cadence
Incident workflow	Request IDs, support escalation path, evidence bundle, notification owners
Renewal trigger	Review date and triggers for new providers, endpoint families, data classes, or logging changes

A good SOC 2 AI API gateway scope memo should attach the CUEC list to engineering work. If the buyer must redact secrets before sending prompts, the approval should point to the redaction test. If the buyer must approve model providers, the route config should show the allowlist.

Flatkey-Specific Screening Evidence To Request And Save

Current public Flatkey pages, checked on July 11, 2026, support using Flatkey in this procurement workflow, but they do not replace account-specific evidence.

Evidence	What the public check showed	How to use it
Homepage	Flatkey publicly positions the service around official GPT, Claude, and Gemini APIs through one key, model routing, dashboard review, usage, cost, routing, and error visibility.	Use as dated product-screening evidence. Do not treat it as private SOC 2 report scope.
Pricing page and pricing API	Public pricing/catalog surfaces returned a live pricing page and a pricing API response with 158 model rows and endpoint families including `openai`, `openai-response`, `anthropic`, `image-generation`, and `openai-video`.	Use as a dated catalog snapshot only. Model and endpoint availability can change.
SLA page	The SLA says it applies to Flatkey-operated hosted dashboard, API gateway, routing, metering, and account services, and excludes third-party AI model providers and other outside systems.	Use to frame what Flatkey directly operates versus third-party dependencies.
Privacy and terms pages	Public policy pages discuss API access, model routing, usage records, billing, support, third-party model providers, and changing model/provider rules.	Use as screening evidence; final approval still needs signed terms and route-specific data handling proof.
Certificate lookup	The public CAI lookup showed VOC AI Inc. certificate `USA-SOC2-220513`, SOC 2 Type II, active, period July 15, 2025 to July 14, 2026.	Use as a public lookup only. Request the actual SOC 2 report and confirm covered system, criteria, period, exceptions, CUECs, and subservice treatment.

For Flatkey or any AI API gateway, the approval should say: "Public pages checked; private report requested; route evidence attached; unsupported assumptions listed."

Build A Scope-To-Route Evidence Packet

The output of this review should be a small evidence packet, not a vague approval.

Packet item	File to save	Owner
SOC 2 report	Private report, report period, criteria, opinion, exceptions, bridge letter if needed	Procurement/security
Scope map	Report system boundary mapped to dashboard, gateway, API, metering, logs, support, and route config	Platform engineering
Provider map	Approved providers, fallback order, subservice treatment, separate provider evidence	Security/platform
Data map	Prompts, outputs, files, metadata, billing records, logs, support tickets, backups	Security/legal
Retention matrix	Gateway, provider, application, support, and backup retention by endpoint family	Security/legal
CUEC record	Buyer controls and proof that each one is implemented	Platform/security
Test evidence	One successful low-risk request and one expected failure with request IDs and redacted logs	Platform engineering
Approval memo	Scope, restrictions, open risks, reviewer names, renewal trigger	Business owner/procurement

This packet is also the bridge between the SOC 2 review and engineering operations. When a new provider, model class, logging mode, or data class is added, the team should know which files need refresh.

Red Flags That Should Pause Approval

Pause the approval if any of these are unresolved:

The SOC 2 report is unavailable and only a badge or certificate lookup is provided.
The report period ended and no bridge letter or current evidence is available.
The system description does not clearly include the gateway path you plan to use.
The report excludes relevant subservice organizations and no separate provider evidence is attached.
The selected trust services categories do not match the buyer's stated risk, such as privacy or confidentiality.
CUECs require buyer controls that have not been implemented.
Prompt/output logging is assumed to be disabled but no account or route evidence proves it.
Fallback can send data to an unapproved provider.
Support can inspect request content but support access, ticket retention, and redaction are not documented.
The approval has no owner, expiration date, or route-change trigger.

These red flags do not always mean the vendor fails. They mean the SOC 2 AI API gateway scope review is unfinished.

A Practical Approval Statement

A useful approval statement is short, specific, and testable:

Field	Example wording
Report evidence	"SOC 2 Type 2 report reviewed for Vendor X, period A to B, security and availability criteria, no unaccepted exceptions for this route."
Approved scope	"Production text-only support workflow through the approved gateway base URL and chat endpoint."
Providers	"Provider A primary, Provider B fallback; no image, video, file, web-search, or batch endpoint."
Data class	"Customer support text after application-level redaction; no payment data, secrets, PHI, or regulated records."
Logging	"Gateway metadata logs allowed; raw prompt/output logging disabled or separately approved; provider retention evidence attached."
Buyer controls	"Keys stored in secret manager, quarterly access review, route allowlist, monthly usage review, incident owner assigned."
Renewal trigger	"Refresh before adding providers, enabling new endpoint families, changing logging, routing regulated data, or after the SOC 2 period expires."

This is what "approved" should mean. Developers know which route they can use. Procurement knows which evidence was reviewed. Security knows what to monitor. Legal knows which assumptions still require contract language.

Bottom Line

A SOC 2 AI API gateway scope review is valuable when it stays precise. The report should help prove the audited service organization's described system, covered criteria, control operation, report period, exceptions, subservice treatment, and buyer responsibilities. It should not be stretched into proof of every route, provider, retention setting, fallback behavior, DPA term, data residency claim, or buyer configuration.

For Flatkey, start with the current public evidence, then request the private SOC 2 report and map it to the route your team will actually run. If you want one API key and one dashboard for multi-model access, get a key, attach the SOC 2 AI API gateway scope checklist to the procurement packet, and approve each production route with explicit provider, logging, retention, and CUEC evidence.

FAQ

What is SOC 2 AI API gateway scope?

SOC 2 AI API gateway scope is the boundary of the SOC 2 report as it applies to an AI API gateway. It includes the audited entity, described system, report period, trust services categories, tested controls, subservice organizations, carve-outs, and buyer-owned CUECs.

Does SOC 2 prove every AI model provider is covered?

No. SOC 2 can show how the gateway vendor manages the described system and its dependencies, but upstream model providers may be included, carved out, or covered by separate evidence. Buyers should save a provider map for each approved route.

Does a SOC 2 Type 2 report prove no prompt retention?

Not by itself. Prompt and output retention can differ across the gateway, upstream providers, application state, support tickets, logs, and backups. The buyer should verify endpoint-, account-, and route-specific retention evidence.

What should procurement ask for after seeing a SOC 2 badge?

Ask for the private SOC 2 report, report period, covered criteria, system description, exceptions, subservice organization treatment, CUECs, bridge letter if needed, provider map, route config, logging settings, retention matrix, and signed contract/DPA evidence where applicable.

How often should the scope review be refreshed?

Refresh the SOC 2 AI API gateway scope review when the report period expires, when the vendor provides a new report, before adding a provider or endpoint family, before routing a new data class, when logging or retention changes, and after material incidents.