Skip to main content

Enterprise identity for agents

Enterprise identity lets your agents run under the identity of the end user who invoked them, rather than a single shared service identity. Catalyst verifies who called the agent, hands your code a trusted user object, and propagates that identity to the downstream tools the agent calls — with no authentication code in the agent. For the underlying trust model, see Identities and Security.

This works with any Python agent framework — vanilla LangGraph, CrewAI, Google ADK, or plain Python — because the identity plumbing lives in the Catalyst data plane and a thin helper library, not in a framework-specific runtime.

What it gives you​

  • Authenticated users. Know which real user is behind each agent invocation, and reject calls that carry no valid identity.
  • Audit trail. Every downstream tool call carries the originating user's identity, so an auditor can trace an action back to the person who triggered it.

Human-in-the-loop approval is not supported on this path — see the callout below.

How it works​

Three layers cooperate to carry a user identity from the caller all the way to a downstream tool. Two of them run inside the Catalyst data plane; the third is a small library you add to your agent.

  1. Inbound authentication. Catalyst intercepts the incoming request, verifies the upstream JWT the caller presented, and exchanges it for a Catalyst-issued user token. It forwards that token to your app in the X-Diagrid-User-Token header. Your agent never sees the raw upstream credential.
  2. diagrid-identity helper library. A thin, drop-in library for vanilla frameworks. It reads X-Diagrid-User-Token, gives your handler a verified user object, and enforces the identity policy you configure. See OAuth with the helper library.
  3. MCP proxy. When your agent calls an MCP tool, the Catalyst MCP proxy transparently mints a delegated token that carries the user's identity to the downstream server. Your agent writes no on-behalf-of code. See On behalf of.

Standards​

Enterprise identity is built on open standards, so it interoperates with your existing identity provider and tooling:

  • OAuth 2.0 and OpenID Connect (OIDC) — user authentication and token issuance.
  • RFC 8693 (token exchange) — the delegation grant that mints on-behalf-of tokens.
  • RFC 8707 (resource indicators) — audience-scoping so a token minted for one server cannot be replayed against another.

Human-in-the-loop is workflow-only​

HITL requires the workflow path

Human-in-the-loop approval is not available on the sync path described here. A synchronous HTTP request cannot hold the caller's connection open indefinitely while it waits for an external approval that may take minutes or hours.

HITL needs durable workflow semantics — the ability to pause, persist state, and resume when an external event arrives. That is only available when your agent runs under the workflow-centric path. See Workflow patterns for the external-events pattern that backs HITL today.

Next steps​

OAuth with the helper library

Read the verified user in FastAPI, Flask, or plain Python with diagrid-identity.

On behalf of

Propagate the user identity to downstream MCP tools with zero agent code.

Custom IdP tokens

Pass a token from your own identity provider when the Diagrid identity provider is not trusted.

Troubleshooting

Rejection codes and the operator debugging path for each one.

Last updated on