Most enterprise AI deployments treat authentication as solved at the edge — but identity evaporates the moment traffic enters the AI layer.
Shared service accounts hit every LLM endpoint. MCP tool servers issue tokens per-application with no link to the human operator. A2A agent tasks carry no caller identity. The result: no attribution, no per-user policy, and no audit trail.
When compliance requires knowing who submitted a prompt, what data they accessed through tools, and which agentacted on their behalf — current platforms have no answer.
Smartflow's SSO gateway exchanges any enterprise identity token — OIDC silent grant, Kerberos SPNEGO, SAML assertion, or trusted proxy header — for a single Smartflow JWT.
That JWT carries the user's AD group memberships, department, and authentication method. It is the only credential that flows through the entire stack. Users who are already logged into the corporate domain authenticate without a prompt.
Every downstream control — model allow-lists, MCP server ACLs, A2A agent ACLs, Maestro policy injection — reads from the same JWT. There is no second authentication, no credential synchronization, and no shared service account.
allowed_groups and denied_groups. PKCE OAuth tokens are stored by JWT subject and injected automatically — users consent once, then all tool calls use their own credentials.Engineering-*) match sub-groups.| Capability | Typical AI Gateway | LiteLLM / Portkey | Smartflow |
|---|---|---|---|
| User identity on LLM calls | ✕ Service account only | ✕ API key only | ✓ Full SSO user identity |
| AD group-based model access | ✕ | ✕ | ✓ Wildcard group patterns |
| MCP tool server group ACL | ✕ | ✕ | ✓ Per-server allowed / denied |
| PKCE OAuth tied to user identity | ✕ | ✕ | ✓ Auto-injected from JWT sub |
| A2A caller identity in task metadata | ✕ | ✕ | ✓ Full audit trail per task |
| Zero re-login for SSO users | ✕ | ✕ | ✓ Silent OIDC / Kerberos |