Criteria Mapping
SOC 2 criteria,
evidenced on every AI call.
SOC 2 examines controls against five trust services criteria. AI workloads have historically been the gap in that examination — hard to evidence because the decision path was opaque. Governance at the call boundary closes it.
Context
What SOC 2 is, and what this page claims
SOC 2 is an attestation engagement performed by a licensed CPA firm against the AICPA trust services criteria. A Type I report examines control design at a point in time; a Type II examines operating effectiveness over a period.
There is no such thing as SOC 2 certification — the output is an auditor's report, not a certificate, and the report belongs to the organization examined.
This page maps where KriftAI's governance controls produce evidence that supports the criteria for AI workloads specifically. It describes control capability. It does not assert an attestation.
The Gap
Why AI workloads have been hard to evidence
The criteria are well understood for conventional systems. AI introduced a component whose behaviour was neither deterministic nor observable at the control layer.
When model calls are scattered across application code, there is no single place to demonstrate that access was authorized, that inputs were validated, or that outputs were checked. Evidence has to be assembled from logs that were never designed to serve as evidence.
Routing every call through one governed entry point changes what can be shown. The control is not distributed across a codebase; it is a single path that every call demonstrably took, with a CI test failing the build if any code bypasses it.
Security (Common Criteria)
Logical access and system operations
Logical access
Three role layers plus database-level row security scoped by organization and project membership. Cross-tenant reads are refused at the database, independent of application logic.
Least privilege
Default-deny tool gating per workspace type. A tool request from the model is blocked unless that workspace holds the grant.
Monitoring
Per-call verdict capture with flagged and blocked counts aggregated per use case, plus a capture-point coverage map showing which paths are instrumented and active.
Change to policy
Governance configuration is versioned and exportable as JSON, giving a reviewable record of policy state rather than a settings screen with no history.
Incident response
Blocked calls, flagged responses, and override decisions all write to the ledger, providing the timeline an incident review needs.
Processing Integrity
Complete, valid, accurate, authorized processing
Input validity
Prompt-injection detection evaluates every input before model invocation; high-severity matches terminate the call.
Output validity
Universal and workspace rules evaluate every response before delivery, with block, redact, or warn outcomes recorded against the triggering rule.
Completeness of record
One ledger row per governed call, written on every path because the chokepoint is the only path.
Authorization
Workspace membership and entitlement checks gate whether a call may proceed at all, with denial as the default on check failure.
Confidentiality & Privacy
Retention, redaction, and disposal
Credential protection
Output scanning redacts API keys, secret keys, and passwords before a response is delivered.
Retention control
Content-logging mode set per organization: full content, SHA-256 fingerprint, or metadata only.
Tenant isolation
Row-level security policies enforce organization and project scoping at the database layer.
Certified disposal
Owner-initiated deletion of the audit trail with a tamper-evident SHA-256 certificate over organization, requester, timestamp, row count, scope, and cutoff.
Close the AI gap in your control environment
See how a single governed call path turns AI workloads from an evidence problem into a documented control.