Security and Control Boundaries

Key considerations

Architecture at a glance

Authentication is only the first boundary

Pulsar uses authenticated sessions and scoped API access, but access to a workspace does not imply access to every administrative or execution capability. Backend checks own authorization decisions and product controls determine what each deployment exposes.

• Role checks protect administrative data and mutations.
• API keys are scoped, rotatable, and revocable.
• Rate and concurrency controls protect shared resources.
• Organization and product policy remain server-owned.

Sensitive administration requires stronger proof

Actions near database access, security configuration, email configuration, or other privileged settings can require recent reauthentication. The reauthentication token is short-lived and administrative mutations are added to the audit history.

Secrets are configuration, not content

Runtime credentials and application secrets belong in restricted environment configuration or an approved secret manager. Saved secret values are masked in administrative views and should never be included in screenshots, exports, logs, or public documentation.

• Generate strong unique secrets during installation.
• Restrict secret-bearing files to the service account.
• Encrypt supported third-party credentials at rest.
• Never render saved secret values back to an operator.

Private services are not public endpoints

Postgres, Valkey, SeaweedFS, application APIs, and model services should be reachable only across required network paths. The reverse proxy is the controlled public edge; dependency services remain bound to local or private interfaces according to the deployment design.

Repository work remains approval-gated

Starbuck is not an arbitrary host-shell interface. Repository policy, task events, artifacts, runner boundaries, redaction, and explicit approvals control writes, package work, pull requests, and other higher-risk execution.

Audit, recovery, and shared responsibility

Pulsar exposes operational evidence and known-safe recovery actions, but the deploying organization still owns infrastructure hardening, identity-provider policy, network policy, backup retention, model governance, and incident response. Pulsar does not claim a compliance certification by default; controls must be evaluated in the context of the final deployment.