SOC 2
What SOC 2 is, and where Infer stands
SOC 2 is an attestation report issued by an independent CPA firm under standards set by the AICPA. It is not a certificate a vendor buys or a checkbox a regulator grants: an auditor examines a defined set of controls against the Trust Services Criteria and reports what they found. Infer's examination is scoped to the Security and Confidentiality criteria, and this page is part of Infer's compliance program.
Our position is simple: the control set SOC 2 examines is how Infer already operates day to day. Content is never written to durable storage, logs are metadata-only by construction, access to the service runs through a single authorized caller, and no internal path exposes customer content to personnel. Attestation is the act of having that operation examined independently, not a change to it. A Type I engagement is in preparation, and evidence collection is underway as part of normal engineering practice rather than as a separate compliance exercise.
Scope
Every SOC 2 examination covers the Security criteria, the common criteria that all reports share. Beyond that, the organization chooses which additional Trust Services Criteria categories are in scope. Infer's engagement is scoped to Security and Confidentiality.
Confidentiality matters unusually much for an inference provider. A buyer sending prompts to a hosted model is sending exactly the material they are most careful about: source code, contracts, customer records, internal analysis. The question they need answered is not only "can an attacker get in" (Security) but "what does the provider itself do with what I send, how long does it keep it, and who inside can read it" (Confidentiality). Infer's architecture is built around that second question, content exists in volatile memory for the life of a request and its transient session cache and nowhere else, so putting Confidentiality in scope puts the examination where the real buyer risk is.
Availability, Processing Integrity, and Privacy are not in the current scope. Availability is a candidate for a later window once Infer has served production traffic and has an operating record to examine; Privacy criteria concern personal information collection practices that do not describe how Infer operates, since Infer receives inference requests from a routing partner rather than from individuals.
Control mapping
The table below maps criteria areas an examination looks at to the practice Infer operates today. These are architectural properties, not intentions: the same facts documented on the security overview and in our retention statement.
| Criteria area | How Infer operates |
|---|---|
| Logical access | A single authorized upstream API caller, our routing partner, reaches the gateway; end users never connect directly. Credentials are scoped to that caller, and no internal tool, console, or export path lets personnel view request or response content. Debugging is performed against synthetic traffic. |
| Confidentiality of customer data | Prompts and completions exist only in volatile memory (GPU and host) for the life of a request and its transient session cache. They are never written to durable storage, never logged, never used for training, and never shared. |
| Data in transit | TLS terminates at the external edge; traffic between the gateway and compute nodes runs over an encrypted overlay network. |
| Monitoring & audit records | Operational logs are metadata-only by construction: timestamps, token counts, status codes, latency, and hashed identifiers. There is no content field to redact. Logs are retained for 30 days. |
| Retention & disposal | Because content is never persisted, there is no retention schedule, backup set, or media-sanitization step for customer content. Volatile state is evicted automatically and does not survive a replica restart. |
| Capacity & resilience | Overload is shed at admission with HTTP 429 rather than queued, so no request content accumulates in a buffer under load. Loss of a replica is absorbed by gateway failover to healthy capacity. |
Path to attestation
SOC 2 arrives in two stages, and we publish where we are at each one.
- Readiness review: underway. Control descriptions are being written against the Security and Confidentiality criteria, and the supporting evidence (log schema, host and serving configuration, transport configuration, access inventory, written policies) is being captured as part of normal engineering practice.
- Type I: in preparation. A Type I report expresses an auditor's opinion on whether controls are suitably designed and in place at a point in time. Auditor selection is in progress; the engagement is the next milestone.
- Operating window. Type II requires an observation period, typically three to twelve months, during which the controls run and generate evidence. That window begins once the service is carrying production traffic.
- Type II. An opinion on whether the controls operated effectively throughout the window. This is the report most enterprise buyers ultimately ask for, and it is the destination of this program.
Infer is pre-launch and has not yet served production traffic. Consistent with the convention across this site, figures and controls described here are design commitments until measured in operation. Status on this page is updated as each milestone completes, and the status line at the top of the page always reflects the current stage.
Requesting documentation
Reports and supporting security documentation are made available to qualifying customers and prospects under NDA as the corresponding engagement milestones complete. Until a report exists, we can share what does: the control descriptions and architecture narrative behind the mapping above, the scope of the engagement in preparation, and the current stage of the program. If your diligence process needs a completed report, tell us the timing you are working to and we will tell you plainly where the engagement stands against it.
To request documentation or discuss diligence requirements:
contact@infer.industries