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. An Application Identity (App ID) is the per-workload identity Catalyst issues to every application and agent that talks to it. Catalyst fetches the policies that apply to each App ID and enforces them inline on every relevant call. No application code changes are required, policies can be tuned per environment without redeploying.

Catalyst exposes two policy kinds today, with a third on the way.

Resiliency policies​

Resiliency policies describe how the 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.

Configurations​

Configurations are App ID-level runtime settings that can set up per-call enforcement rules. They control how a workload behaves at runtime: which tracing pipeline it emits to, which service invocation access control lists (ACLs) apply, and which HTTP and workflow pipelines are loaded. Where resiliency policies decide what to do when an outbound call fails, configurations decide how an App ID is wired up at startup and, in the case of ACLs, which inbound service invocations it will accept.

See App IDs for day-2 operations on configurations.

MCP access policies (coming soon)​

MCP access policies will govern which App IDs can call which Model Context Protocol (MCP) servers, and which downstream tools they can invoke on those servers. The design follows a default-deny model: every call is blocked unless an explicit rule allows it. Rules will be able to match on App ID, action (for example tools.call or tools.list), tool name patterns, and tool argument values. MCP access policies are intended for fine-grained, per-tool authorization of AI agents.

This policy kind is in design and is not yet available on Catalyst. See MCP for the broader MCP 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 inbound ACL 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