# Security

Catalyst's security model layers multiple controls: data-plane components carry cryptographic SPIFFE identities and communicate over mTLS, applications authenticate to the platform with scoped app API tokens over TLS, projects and regions provide isolation boundaries, and sensitive configuration lives in secret stores you own or Catalyst manages on your behalf. Human and machine access is governed by role-based access control and audited.

## Trust boundaries

The Catalyst control plane is never on the request path for application data. Configuration flows down from the control plane to the data plane; application payloads stay within the data plane and your applications.

A Catalyst deployment has three trust zones:

- **Catalyst control plane** — the management surface (CLI, console, API). It stores resource definitions, manages the workload identity system, and reconciles desired state into the data plane.
- **Catalyst data plane** — the Dapr Servers, platform services, and backing infrastructure that handle your Dapr API calls. Runs in a Kubernetes cluster — Diagrid-managed on Catalyst Cloud and Enterprise Dedicated, customer-managed on Self-Hosted and Air-Gapped.
- **Customer applications** — your application and agent code, running wherever you choose to run it. Catalyst never executes this code; it only routes traffic to and from it.

```mermaid
flowchart LR
  subgraph CP["Catalyst Control Plane"]
    API(Management API)
    SENTRY(Sentry)
  end
  subgraph DP["Catalyst Data Plane"]
    DAPR(Dapr Servers)
    INFRA(Backing Infrastructure)
  end
  subgraph APP["Customer Applications"]
    WORKLOAD(App / Agent)
  end
  API-."reconcile config".->DAPR
  SENTRY-."issue SVIDs".->DAPR
  WORKLOAD<--"TLS + app token"-->DAPR
  DAPR<--"mTLS (SPIFFE SVID)"-->INFRA
```

Three boundaries are crossed at runtime:

| Boundary | What crosses it | How it is secured |
|----------|-----------------|-------------------|
| Application → data plane | Dapr API calls (state, pub/sub, workflow, service invocation, …) | App API token on every call; transport is TLS to the regional Gateway. |
| Data plane → application | Pub/sub deliveries, input bindings, service-invocation callbacks | Optional application token in the `dapr-api-token` header; combine with network allowlisting on the project's egress address. |
| Data plane internals | Dapr Server ↔ Dapr Server, Dapr Server ↔ backing infrastructure | SPIFFE-based mTLS — each in-platform workload mutually authenticates with a short-lived X.509 SVID. |

## Identity and mTLS

Catalyst issues a [SPIFFE](https://spiffe.io/)-based, cryptographically verifiable identity — a short-lived X.509 SVID, signed by a Dapr Sentry and automatically rotated — to every workload that participates in the data plane: each Dapr Server, each Catalyst component, and each platform service. These identities drive mTLS between data-plane components, and the certificates that back this mTLS are issued, distributed, and rotated by Catalyst with no operator intervention.

Your application itself does not carry a SPIFFE identity. It authenticates to Catalyst on every Dapr API call using its [app](https://docs.diagrid.io/concepts/identities) API token, and the underlying transport is TLS to the regional Gateway. The Dapr Server that handles those calls is the entity with the SPIFFE identity — it represents your app inside the data plane and uses its SVID to mutually authenticate downstream connections.

On [Catalyst Enterprise Self-Hosted](https://docs.diagrid.io/operate/hosting/enterprise-self-hosted), the identity system spans two trust domains — one for in-region traffic and one for traffic between the region and Diagrid Cloud. The regional CA that signs in-region SVIDs is either auto-generated by Sentry on first boot (suitable for non-production; one-year lifetime, no auto-renewal) or supplied by you and rotated under your own PKI lifecycle, typically with [cert-manager](https://cert-manager.io/). See [System Architecture › Workload Identity](https://docs.diagrid.io/operate/hosting/enterprise-self-hosted/system-architecture#workload-identity) and [Regional PKI](https://docs.diagrid.io/operate/hosting/enterprise-self-hosted/system-architecture#regional-pki).

## Isolation and data protection

**Project and region isolation.** Regions and projects are Catalyst's isolation primitives — see [Organisations and Projects](https://docs.diagrid.io/concepts/organisations-and-projects) for the model. From a security standpoint, the project boundary is enforced at the network layer: Catalyst applies a deny-by-default network policy in each project so workloads in one project cannot reach another project's namespace or other internal services on the cluster network without an explicit allow rule. On Self-Hosted you can tune the defaults; see [System Architecture › Network Policies](https://docs.diagrid.io/operate/hosting/enterprise-self-hosted/system-architecture#network-policies).

**Secret management.** Sensitive metadata on components, HTTP endpoints, and configurations (connection passwords, API keys, tokens, certificates) is held in secret stores you own or Catalyst manages on your behalf — never as plaintext in the control plane. The two models are covered in [Managing Secrets](https://docs.diagrid.io/operate/project-operations/secrets):

- [**Transparent extraction**](https://docs.diagrid.io/operate/project-operations/secrets#transparent-secret-management-default) (default) — plaintext values in sensitive fields are extracted into a Catalyst-managed secret store at submission time and replaced with a `secretKeyRef`.
- [**Bring your own secret store**](https://docs.diagrid.io/operate/project-operations/secrets#bring-your-own-secret-store) — reference a Dapr secret store component (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) from your resources and Catalyst applies them as declared.

Applications can also resolve secrets at runtime via the [Dapr Secrets API](https://docs.diagrid.io/concepts/dapr-apis), keeping credentials out of application code and environment variables.

## Access control

Access to the Catalyst control plane is governed by role-based access control:

- **Human users** belong to an [organisation](https://docs.diagrid.io/concepts/organisations-and-projects) and are assigned one of four roles — Admin, Operator, Consumer, or Viewer — either globally or scoped to specific projects. Enterprise plans support SAML 2.0 SSO, so user lifecycle is managed by your IdP.
- **Automation** uses API keys: named tokens with a role assignment, configurable expiry, and optional project scope; the secret value is shown only at creation time.

See [Manage Access](https://docs.diagrid.io/operate/platform-operations/identity-and-access) for the full role matrix, SSO setup, and API key management.

**Workloads** authenticate to the data plane using their [app](https://docs.diagrid.io/concepts/identities) API token. Runtime behaviour for each app — what it can invoke, which components it can use, and how requests are filtered — is governed declaratively by [policies](https://docs.diagrid.io/concepts/policies).

## Audit logging and compliance

User and application **audit logs** capture who did what and when across the control plane — which user created an app, who rotated an API key, which service account deployed a component. Audit logs are available on Catalyst Enterprise plans and support compliance review; see [Observability › Audit logs](https://docs.diagrid.io/operate/project-operations/observability#audit-logs).

For workflow-based processes, Catalyst can additionally sign each recorded step so the execution history itself is tamper-evident and independently verifiable. See [Tamper-evident attestation](https://docs.diagrid.io/concepts/workflows#tamper-evident-attestation).

Diagrid is **SOC 2 Type II** certified. You can request the SOC 2 Type II report by contacting [sales@diagrid.io](mailto:sales@diagrid.io).

## Shared responsibility model

Catalyst is a managed runtime, and the line of responsibility shifts with the [deployment model](https://docs.diagrid.io/operate/hosting). The table below summarises the split for [Catalyst Cloud](https://docs.diagrid.io/operate/hosting/catalyst-cloud), [Dedicated Cloud](https://docs.diagrid.io/operate/hosting/dedicated-cloud), and [managed BYOC](https://docs.diagrid.io/operate/hosting/byoc/managed); on [self-managed BYOC](https://docs.diagrid.io/operate/hosting/enterprise-self-hosted) and [Enterprise Server](https://docs.diagrid.io/operate/hosting/enterprise-server), customer responsibility expands to cover the Kubernetes cluster, the regional PKI lifecycle, and any backing infrastructure you choose to bring (PostgreSQL, Kafka, etc.).

| Area | Diagrid is responsible for | Customer is responsible for |
|------|----------------------------|-----------------------------|
| Control plane | Availability, patching, hardening, secret storage | Managing users, API keys, and roles |
| Data plane (Dapr runtime) | Runtime versioning, mTLS, certificate issuance and rotation, isolation between projects | Configuring apps, components, and policies for your workloads |
| Workload identity | Issuing and rotating SPIFFE SVIDs for in-platform components | Binding applications to their IDs and protecting app API tokens |
| Encryption in transit | mTLS everywhere on the data plane | TLS termination on your own application endpoint if Catalyst calls back to it |
| Secrets | Encrypted storage in the managed or BYO secret store, never in the control plane DB | Choosing the secret store, rotating long-lived credentials it holds |
| Network isolation | Deny-by-default NetworkPolicies between project namespaces | Allowlisting Catalyst's project egress on your application network |
| Application code | — | Application logic, dependencies, callback authentication, input validation |
| Compliance | SOC 2 Type II, audit log capture, status reporting | Your own compliance posture and access reviews for users and keys |

See [System Architecture](https://docs.diagrid.io/operate/hosting/enterprise-self-hosted/system-architecture) for the full Self-Hosted responsibility breakdown, including outbound connectivity to Diagrid Cloud.

## See also

- [Application Identities](https://docs.diagrid.io/concepts/identities) — ID as the unit of identity and access.
- [Organisations and Projects](https://docs.diagrid.io/concepts/organisations-and-projects) — top-level isolation scopes.
- [Policies](https://docs.diagrid.io/concepts/policies) — declarative runtime behaviour bound to apps.
- [Manage Access](https://docs.diagrid.io/operate/platform-operations/identity-and-access) — users, roles, and API keys.
- [Managing Secrets](https://docs.diagrid.io/operate/project-operations/secrets) — transparent extraction and BYO secret stores.
- [System Architecture (Self-Hosted)](https://docs.diagrid.io/operate/hosting/enterprise-self-hosted/system-architecture) — dual-sentry trust model, regional PKI, network policies.
- [Dapr Open Source security guide](https://docs.diagrid.io/dapr-open-source/security-guide) — the OSS security baseline Catalyst builds on.