Most AI platforms are built by developers who inherited their authentication thinking from web application patterns. The user logs in. The user is issued a session token. The session token gates access to features. The whole system is designed around human users initiating actions.
That model is inadequate for multi-agent AI platforms — and the inadequacy becomes expensive when you’re building for financial services and enterprise clients who need SOC 2, GDPR compliance, and the ability to audit every action taken in the system.
When we built Sofia, we learned this the hard way. Here’s what we found.
The Agent Identity Problem
In a multi-agent AI platform, agents don’t just assist users. They act as users. An AI agent that reads your CRM, drafts an email, schedules a meeting, and posts a Slack message has taken four distinct actions across four different systems — each of which generated an authorization event that needs to be attributed to a specific identity.
Traditional identity systems are built around human identities. A user creates an account, authenticates with credentials, and performs actions. The audit log shows who did what. In a multi-agent system, “who did what” becomes significantly more complex. Did the user do it? Did the agent do it? Which agent? Acting on whose behalf? Under what scope of authorization?
If your identity system can’t answer these questions, your audit log is meaningless — and your SOC 2 auditor is going to notice.
The Four Options
Auth0 and ForgeRock
Auth0 is the default choice for many startups: easy SDK integration, generous free tier, good documentation. ForgeRock is its enterprise equivalent. Both handle human user authentication well.
The limitation: neither was built with AI agent identity as a primary use case. Machine-to-machine authentication exists in both, but the identity model treats agents as service accounts rather than first-class identities. For SOC 2 in financial services, that distinction matters.
Authentic
Authentic is a simpler open-source identity solution that works well for early-stage deployments. The limitation: manual configuration, not infrastructure-as-code friendly. When you’re building toward SOC 2 and deploying to Kubernetes, you need your authentication infrastructure reproducible from code — not manually configured per environment.
Keycloak
Keycloak is the option that survived our evaluation and the one our infrastructure consultant independently recommended for the same reasons. It’s open-source, runs on-premises or in your own cloud environment (critical for enterprise clients who require data residency), and is designed to support machine identities as first-class objects alongside human identities.
For AI agent platforms specifically: Keycloak’s client credential flows can represent each agent as a distinct identity with its own scopes, roles, and permission boundaries. The audit log shows agent actions attributed to specific agent identities, not rolled up into a generic service account.
Ory Stack
Ory is a modular, cloud-native alternative to Keycloak with strong infrastructure-as-code support. The trade-off: more complex to operate than Keycloak, higher ongoing engineering overhead. For most enterprise AI platforms, Keycloak is the better balance.
Why Infrastructure-as-Code Matters
When you’re operating an AI platform with enterprise clients who require isolated environments, your infrastructure needs to be reproducible from code. Every time you spin up a new client environment, authentication should be configured automatically — same policies, same roles, same audit logging configuration — not manually set up by an engineer.
Keycloak plus Terraform makes this possible. The entire authentication configuration is code: realms, clients, roles, permissions, flows. A new environment inherits the same configuration as every other environment. Your audit log is consistent across environments.
This isn’t just an operational efficiency point. It’s a SOC 2 requirement. Change management controls require that infrastructure changes go through a defined process — and if your authentication configuration exists only in a GUI, it’s not under change management.
SOC 2 and the Authentication Decision
SOC 2 access control requirements require that access to systems is granted based on defined roles, that access is reviewed periodically, and that there’s an audit trail of who accessed what and when.
For a multi-agent AI platform: every agent needs a defined identity with specific role assignments. Agent permissions need to be reviewable and adjustable without touching user permissions. Every agent action needs to produce an audit log entry attributed to the specific agent identity. When an agent’s authorization changes, the change needs to be logged.
Auth0’s M2M client model makes this harder than it needs to be. Keycloak’s service account model, configured through IaC, makes it straightforward.
What This Looks Like in Practice
On the Sofia platform, AI agents authenticate with Keycloak using client credential flows. Each agent type has its own client in Keycloak, with scopes that represent the specific systems and actions it’s authorized to take. An agent authorized to read CRM data cannot, by configuration, write to the CRM — and that constraint is auditable.
When we provision a new enterprise client environment, Terraform applies the Keycloak configuration automatically. The client’s environment has the same identity model, the same role definitions, and the same audit logging as every other environment.
For our SOC 2 path, this means the access control evidence is automatically generated and consistent. The auditor can review the configuration-as-code, the deployment log, and the audit trail — all pointing to the same authorization model applied consistently.
The Bottom Line
If you’re building a multi-tenant AI platform for financial services or enterprise clients, the authentication decision you make now will either enable or constrain your compliance path for years. The platform that treats AI agents as first-class identities — with distinct authentication, scoped authorization, and auditable action logs — is a fundamentally different compliance story than one that treats agents as service accounts bolted onto a user identity system.
Build the identity model right the first time. It’s much cheaper than rebuilding it when your first enterprise client asks for your SOC 2 report.
FINdustries builds the Sofia AI platform for wealth management and financial advisory firms. If you’re evaluating authentication architecture for an AI agent platform, we’d like to talk about what we learned building ours.
