Most founders think SOC 2 is about audits. It’s actually about architecture — and by the time the auditor shows up, the window to fix your identity system is already closed.
The companies that fail their SOC 2 Type 1 audits — or pass Type 1 and then fail the Type 2 observation period — usually have the same underlying problem: their access control architecture wasn’t built with auditability in mind. They can tell you what their system does. They can’t produce the evidence that it does it consistently.
For AI SaaS platforms specifically, this problem has a dimension that doesn’t exist in traditional software: AI agents that act as identities, performing actions across integrated systems without direct human initiation. Building an identity system that handles human users and AI agents auditably is a different problem than building authentication for a conventional SaaS application.
What SOC 2 Actually Requires Around Identity
The Security Trust Service Criterion CC6 addresses logical access controls. At a Type 1 level, the auditor is evaluating whether your controls are designed correctly. At a Type 2 level, they’re evaluating whether those controls operated consistently over the observation period.
Access Provisioning
When a user or agent is granted access to a system, is there a documented process? Is the access grant logged?
Role-Based Access Control
Are permissions organized around roles rather than granted individually? Can you demonstrate that access is limited to what’s required for each role?
Access Review
Is there a documented process for periodically reviewing who has access to what, and removing access when it’s no longer appropriate?
Audit Trail
Is there a log of who accessed what and when, retained for a defined period, and protected from unauthorized modification?
None of these requirements are exotic. But they all assume that your identity system produces auditable, structured records of access events — and that the architecture is organized around roles and policies rather than one-off access grants.
How Authentication-as-Code Maps to SOC 2
When your identity configuration lives in code — roles, permissions, user-to-role assignments, client credentials, token policies — every change to that configuration is a code change. Code changes go through version control. Version control produces a history of every change, who made it, and when. That history is SOC 2 evidence.
Contrast this with authentication systems managed through a GUI: role assignments changed by clicking through an admin panel, access grants made in real time without a documented approval workflow, configuration state that exists only in the database of your auth provider. You can describe your access control model. You can’t demonstrate that it’s been consistently maintained through an observation period.
Keycloak plus Terraform means your identity configuration is version-controlled, your changes are traceable, and your audit evidence is automatically generated by your deployment pipeline. The auditor can review the code, the commit history, and the deployment logs — all pointing to the same access control model applied consistently.
AI Agent Identity — The Frontier SOC 2 Doesn’t Fully Address
SOC 2 was designed for systems where humans perform actions. The standards for access control, audit logging, and identity management are calibrated to that assumption.
Multi-agent AI platforms complicate this in ways the standard hasn’t fully caught up with. When an AI agent reads a client’s CRM data, drafts a document, and sends a Slack message — all without a human directly initiating each action — the access control and audit trail questions are different.
Which identity performed each action? The agent? The user who authorized the agent? Both? What was the scope of authorization? How is that scope enforced — at the policy level or the architectural level?
The platforms getting ahead of this problem are building agent identity into their Keycloak configuration — representing each agent type as a distinct service client with explicitly defined scopes, so that what the agent can do is architecturally bounded, not just policy-constrained.
The Type 1 to Type 2 Transition
SOC 2 Type 1 is a point-in-time assessment: your controls are designed correctly as of this date. Type 2 is an observation period assessment: your controls operated consistently over the past 6-12 months.
The gap that most companies don’t appreciate: Type 1 can be achieved by building the right architecture and documenting it. Type 2 requires that the architecture has been running correctly — with evidence — for months.
The identity system decisions you make now don’t just affect your Type 1 audit. They determine whether the observation period produces the evidence you need for Type 2. A manually-managed auth system might pass Type 1 with careful documentation. It will struggle with Type 2 when the observation period reveals inconsistencies in how access was actually managed day-to-day.
Build the compliance architecture before the observation period starts. The window to fix your identity system closes earlier than you think.
FINdustries builds the Sofia AI platform for wealth management and financial advisory. We’re on the SOC 2 Type 1 path, and the identity architecture decisions we’re making now are designed to support the Type 2 observation period that follows. If you’re on the same path, we’d like to compare notes.
