Application Identities

An Application Identity (App ID) is the identity Catalyst issues to a workload. Every workload you run is given an App ID:

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

The App ID is the unit you build security boundaries around. Components, policies, and MCP access are all expressed in terms of App IDs: you allow-list which App IDs may invoke a target, which components an App ID 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.

Cryptographic identity

Catalyst issues each App ID 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.

An application binds to its App ID using an API token at startup, but the SPIFFE identity is what secures runtime communication. The token identifies which App ID the workload is; the SVID is what every downstream hop verifies. See Security for the full identity and trust-boundary model.

What attaches to an App ID

At the App ID 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 App IDs, see App IDs. For how App IDs bind to MCP authentication, see MCP authentication.