How a 50-person fintech proves SOC 2 controls for its AI agents
A representative deployment pattern. Cryptographic agent identities, scoped permissions, and signed audit trails mapped directly to AICPA Trust Services Criteria for the Type II window.
This is a representative scenario — not a named customer. The control mappings, evidence artefacts, and Trust Services Criteria references are real. The company name, headcount, and product specifics have been generalised to protect customer confidentiality. If you want a named reference for a specific industry, contact us.
The setup
A B2B payments company, ~50 people, Series A. They run a fleet of AI agents that handle customer-facing workflows: triaging support tickets, reconciling transactions against ledger entries, and drafting compliance correspondence for the operations team. The agents touch customer financial data — so the security boundary matters.
They are mid-way through their SOC 2 Type II observation window. The CISO's working assumption is that the audit will look at AI-agent activity the same way it looks at human user activity: who did what, when, with what authorization, and where is the evidence?
The problem they hit first
Their initial implementation used a single service-account API key shared across the agent fleet. Two issues surfaced quickly: (1) audit logs attributed every action to "the AI service" rather than to a specific agent, which made incident investigation slow; (2) the auditor flagged the shared credential as a control gap under CC6.1 (logical access — entity-level authentication).
They needed per-agent identity, per-agent permissions, and per-agent audit trails — without rewriting their agent runtime.
The fix
They moved to a model where every agent is registered with Vorim at deployment time, gets a unique Ed25519 keypair, and is granted a tight set of permission scopes per workflow. Every action — tool calls, model calls, data fetches — runs through a Vorim permission check and emits an audit event. Bundles are exported monthly for the security team's review and held for the auditor.
Control mapping
Below is the mapping the security team produced for their auditor, by Trust Services Criterion. The "evidence" column is what they hand over — not a description, the actual artefact.
Each AI agent in production has a unique Ed25519 keypair issued at registration. Public-key fingerprint is the agent's permanent identity. There are no shared API keys between agents, and a compromised credential affects exactly one agent — not the fleet.
Permissions are granted per agent across seven scopes (read, write, execute, transact, communicate, delegate, elevate). Each grant carries a time window, an optional rate limit, and a resource pattern. Auditors can pull the active permission set per agent at any point in time.
Every permission denial, error, and elevated-scope call is emitted as a discrete audit event. Trust-score deltas (a derived signal based on denial frequency, scope breadth, and behavior change) flag agents that are drifting from baseline before incidents.
Audit events stream into the existing SIEM via the API. The incident response runbook for an AI agent — credential revocation, scope reduction, full audit pull — is the same shape as it is for a human user, which makes it operable by the on-call team without specialized training.
The audit log is append-only with SHA-256 hash linking — modifying any event invalidates all subsequent hashes. Bundles export with a signed SHA-256 manifest, so an auditor recomputes the hash and verifies the signature to confirm integrity over a date range.
Every event captures actor (agent_id), action (operation name), inputs (where lawful), outcome (allowed / denied / error), latency, and a metadata blob. There is no "the agent did something" log line — there is "agent X executed action Y on resource Z at time T with outcome O".
Retention is configurable per tier; the fintech selected 24 months for the AI-agent control plane to comfortably cover the SOC 2 Type II audit window plus rollover. TimescaleDB hypertables keep query performance flat as the log grows.
Bundle exports are gated by role. Compliance can pull a redacted bundle for external auditors; engineering can pull a full bundle for internal review. Exports themselves are audit events — there is a record of every time data left the system.
What it cost them
About a sprint of engineering work. The bulk was migrating from the single service-account credential to per-agent registration in their existing deployment pipeline. The audit-log integration was a thin wrapper around their LLM and tool calls; the SDK does the rest. The auditor's questions were closed in a single follow-up meeting once the signed bundle was demonstrated.
What they did not need
- —A separate SIEM pipeline for AI activity — the existing pipeline ingests Vorim events.
- —A bespoke audit-trail design — the signed bundle satisfies CC4.1 evidence requirements out of the box.
- —A custom retention layer — Vorim retention is configurable per tier.
- —A new on-call rotation — Vorim alerts route to the existing incident channels.
The honest limitations
Vorim covers the agent identity and audit-trail surface. It does not cover the LLM provider's own SOC 2 posture, the underlying data infrastructure, or application-level access controls that govern what a tool function can actually do once authorized. Those still have to be in place. The point of this case study is narrower: given those exist, Vorim closes the AI-agent control gap without bespoke engineering.
If you are running a similar audit
The pattern transfers cleanly to other regulated industries — healthcare under HIPAA, public-sector under FedRAMP-adjacent frameworks, EU operators under the AI Act. The articulation of controls changes; the underlying evidence shape (identity + permission decision + signed log) does not.
Need to map AI agents to SOC 2 controls in your audit?
30-minute call. We'll walk through your current control mapping and where Vorim slots in. No commitment.
Representative scenario based on common deployment patterns. AICPA Trust Services Criteria references are to the 2017 TSC framework. This page is not legal or audit advice. SOC 2 audit scope and evidence requirements are determined by your auditor.