Identities
An ID is a workload's identity in Catalyst. Every workload you run gets its own ID:
- An application: any service, API, or job.
- An agent: a durable AI agent.
- An MCP server: a tool or data server that an agent connects to.
The ID is what you set security boundaries around. Policies, component access and MCP access all name IDs: which workloads may invoke a target, which components a workload may use, and which agents may reach which MCP servers. Because the boundary is the identity rather than a network address or a shared secret, the same rules hold wherever the workload runs.
A workload authenticates to Catalyst with its ID's API token. Inside Catalyst, the Dapr Server that represents the workload carries a short-lived SPIFFE identity and uses it for mTLS on every downstream call.
Cryptographic identity
Your application, agent or MCP server doesn't hold a certificate itself. It authenticates to Catalyst on every call with its ID's API token, over TLS to the regional Gateway. The token tells Catalyst which ID is calling.
Inside the data plane, the Dapr Server that represents the workload carries a SPIFFE-based, cryptographically verifiable identity: a short-lived X.509 SVID that Catalyst rotates automatically. The Dapr Server uses this SVID to mutually authenticate its downstream connections, to other Dapr Servers and to backing infrastructure, so no hop relies on a shared secret. See Security for the full identity and trust-boundary model.
What attaches to an ID
At the identity level you control:
- Access and resiliency policies — see Policies.
- Components the workload may use — see Components.
- MCP access — which agents may reach which MCP servers — see MCP.
For day-2 operations on IDs, see Manage IDs. For how IDs bind to MCP authentication, see MCP authentication.
Next steps
- Decide which identities can call each other with policies.
- Use an identity from your code with Connect to Catalyst.
