Identity and Access: SSO and Capability-Based Authorization

Identity and access are core-level concerns in EchoFoundry, and getting the mental model right here pays off across every module your organization runs. This episode covers SSO setup and the capability-based authorization model that replaces old-style fixed roles.

SSO as the front door

Authentication runs through a WorkOS-backed layer supporting SSO, SCIM-based directory sync, and MFA including step-up challenges for sensitive actions. Practically, this means:

• Users authenticate once against your organization's identity provider, not against each module separately.
• Directory sync (SCIM) keeps user provisioning and deprovisioning aligned with your source-of-truth HR or IT system, rather than requiring manual account management inside EchoFoundry itself.
• Step-up MFA can require a fresh authentication challenge before a particularly sensitive action (a large approval, an admin permission change) even for an already-logged-in session.

Set up SSO first, before granting any module access, so every subsequent access decision inherits a verified identity rather than a locally created account.

Why capability-based authorization, not roles

Traditional role-based access control assigns a user a role ("Admin," "Editor," "Viewer") and the role implies a fixed bundle of permissions. This breaks down fast in a multi-module platform: roles multiply, drift from what people actually need, and become impossible to audit ("why does this Editor role also grant billing access, who added that, and when?").

Capability-based authorization instead grants specific, explainable capabilities scoped to specific resources: "can approve expense reports up to $5,000," "can view but not edit EchoAgents workflow configs in the Marketing workspace." Every access decision is evaluated server-side, per resource, and, critically, every decision is explainable: you can ask the system why a user was allowed or denied a specific action and get a concrete answer, not a shrug.

Structuring capability grants

When setting up access for your organization, resist the instinct to recreate your old role list one-to-one. Instead:

1. Start from the resource, not the person. What resources exist (workflows, budgets, agent configs, reports) and what actions can be taken on each?
2. Grant capabilities in the smallest useful unit. Prefer several narrow grants over one broad one. Narrow grants are what make the system explainable later.
3. Use groups for the common case, individual grants for the exception. Group most users by function; reserve individual capability grants for genuine one-offs, and revisit them periodically. One-off grants are exactly the kind of thing that outlives its reason and gets forgotten.

Auditing access as an ongoing practice, not a one-time setup

Capability-based authorization is only as good as your discipline in reviewing it. Set a recurring cadence (quarterly is a reasonable default) to review capability grants across your organization: who has what, does it still map to their actual role, and are there individual grants that should have expired already.

Tying it back to governance

The same capability model that governs human users governs AI agents deployed through the platform (see the AI Operations Fundamentals track, Episode 3, for the agent-specific application). One authorization model, applied consistently to both humans and agents, is what makes an audit trail actually trustworthy, because there's only one place to look.

Field exercise

Pick one resource type in your organization (a workflow category, a budget pool, an agent configuration group) and write out the smallest set of capability grants that would let your team do its actual job, no broader. Compare it against what's currently granted and note every gap in either direction.