Identities

An ID is the identity Catalyst issues to a workload. Every workload you run is given an ID:

• An application — any service, API, or job.
• An agent — a durable AI agent.
• An MCP server — a tool/data server an agent connects to.

The ID is the unit you build security boundaries around. Components, policies, and MCP access are all expressed in terms of workloads: you allow-list 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 no matter where the workload runs.

Every workload gets an IDPolicies and component access are granted to the ID, not to a network address.

Cryptographic identity

Catalyst issues each workload a SPIFFE-based, cryptographically verifiable identity — a short-lived X.509 SVID, automatically rotated — used by the data plane to mutually authenticate every call between workloads and to backing infrastructure, with no shared secrets.

A workload binds to its ID using an API token at startup, but the SPIFFE identity is what secures runtime communication. The token identifies which workload it is; the SVID is what every downstream hop verifies. 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.