Skip to main content

Policies

Catalyst controls runtime behaviour declaratively through policies. A policy is a project-scoped resource that binds to one or more Application Identities — the per-workload identity Catalyst issues to every application, agent, and MCP server. Catalyst fetches the policies that apply to each App ID and enforces them inline on every relevant call. No application code changes are required, and policies can be tuned per environment without redeploying.

Catalyst exposes the following policy kinds.

Access policies​

Access policies control which App IDs can invoke a target — an application, an agent, or an MCP server. You attach access control rules to the target App ID; the default action can be set to deny, so the target is unreachable until a calling App ID is explicitly allow-listed. Authorization is enforced inside Catalyst at the service-invocation boundary, so a denied call is rejected before it reaches the target.

Access policies apply to any workload that other workloads call: services, agents, and MCP servers alike.

See Secure service invocation with access control for the rules model and the CLI commands, and App IDs for day-2 operations.

Workflow access policies​

Workflow access policies govern which App IDs can schedule workflows and activities on other App IDs — the authorization layer for multi-application workflows. They apply only to workflow applications (applications that run workflows). A policy is a pure allow-list: without one, all cross-app workflow calls are allowed; once a policy covers an app, every cross-app call must match a rule or it is denied. An app can always run its own workflows, so a policy only gates calls from other apps.

See Secure workflows with access policies for the rules model and the CLI commands.

Resiliency policies​

Resiliency policies describe how Catalyst should recover from transient failures on outbound calls. An outbound call is any call from an App ID out to another application, or to a component such as a state store, pub/sub broker, or binding. A resiliency policy can express retries (constant or exponential), timeouts on individual calls, and circuit breakers that trip after a configurable number of consecutive failures. The same policy can target multiple App IDs by listing them in its scope, or be scoped narrowly to a single one.

See Resiliency for the full concept, and Apply resiliency policies for the CLI commands.

MCP access policies​

MCP access policies are access policies applied to an MCP server's App ID: they govern which App IDs can call the server, and which downstream services the server can reach. Set the default action to deny to make the server unreachable until callers are explicitly allow-listed.

See MCP access policies to apply them, and MCP for the broader picture.

Enforcement model​

Policies are defined at the project level and bound to App IDs. When a workload makes a call through Catalyst, the relevant policies are evaluated before the call is dispatched. A retried request is retried inside Catalyst, so the application making the request sees a single logical call. A tripped circuit breaker fails fast without dispatching a request at all. A request that violates an access policy never reaches the destination App ID. Because enforcement happens in Catalyst rather than in application code, the same workload gets the same guarantees in every environment, and operators can change those guarantees without touching application code.

See also​

Last updated on