What is SOC 2?

Why It Matters

A security review asks three questions that an agent touches directly: how changes are approved, who can reach production, and what evidence exists that the controls operate. A SOC 2 examination reports on controls against five trust services criteria, security, availability, processing integrity, confidentiality, and privacy, and it is usually the gate before an enterprise buyer will connect a system to its own data.

The report is about the controls and the evidence they operate. It says nothing about whether the model is right, which is a separate question the buyer asks next.

What It Covers

The control families that matter for AI are the ones already in the report: access management, change management, monitoring, and incident response. The AI stack simply has to be inside them. Prompts, model versions, retrieval configuration, and tool definitions are changes to production behavior, so they need the same approval path as code.

Evidence is the second half. A control that operates without producing a record is an assertion, and an examination asks to see the records. That is the same requirement as a decision record, arriving from a different direction.

Where It Breaks

The AI stack commonly sits outside the described boundary. A vendor inference endpoint, a managed trace store, and a prompt store each receive production data while the report still reads clean, because nobody redrew the diagram when the model was added.

Change management is the second break. The process assumes human-authored changes with a review and an approver, and an agent that opens pull requests, edits configuration, or regenerates prompts can move production behavior without passing through it. Versioning a prompt is not optional in that environment; it is how the change becomes reviewable at all.

The third is access. An agent holding a broad service account satisfies “authenticated access” and defeats the point, since the criterion is about who can reach what, and the agent is now one of the whos.

How Flytebit Handles It

We put prompts and models under the same version control and approval path as code, give each agent instance a workload identity with bounded permissions, and treat decision records as the operating evidence a review asks for. Model behavior sits under the eval harness rather than inside the security report, which keeps both claims honest. The industry application is on our Software & Technology page, and the control design is our AI governance and risk work.