This repository is the Dynapps installation of systemprompt: the extensions, services configuration, desktop-bridge white-label and deployment bundles built on the published systemprompt-* core crates. It runs inside Dynapps's own environment, and a vulnerability here can expose governed AI traffic, audit data or credentials, so reports are handled by coordinated disclosure.

Email: ed@systemprompt.io

Include, where possible:

• Affected version(s) and commit hash
• Reproduction steps or proof-of-concept
• Impact assessment (confidentiality / integrity / availability)
• Any suggested mitigation

Do not open public GitHub issues for security reports. If you need an encrypted channel, ask for one in your first email. A report that turns out to sit in core is handled under the core security policy with the same contact and targets.

If a fix needs longer than this, we will say why and agree a timeline in writing.

Dynapps releases track core minor versions (this release is 0.63.1 on core 0.63.1).

The previous minor receives Critical and High fixes until the next minor ships, then leaves support, mirroring core's policy. Deployments should run the latest 0.63.x release.

In scope:

• This repository: the extensions under extensions/, the configuration under services/, the scripts and deployment bundles (deploy/), the published container image and the white-labelled desktop bridge built from bridge/.
• The systemprompt-* core crates this repository builds on, as consumed here. Core fixes are made and released in core and adopted by a core pin bump.

Out of scope:

• Third-party kits and MCP servers not maintained in this repository.
• Upstream dependency vulnerabilities we cannot remediate (we forward them to their maintainers).
• Denial of service through unrealistic resource consumption against a local development build.

Audit tables (ai_requests, ai_safety_findings and the other audit logs) are guarded by database triggers that refuse, or in warn mode record, any update, delete or truncate outside the retention floors. That refusal is immediate: it runs inside the offending statement. The hash chain over ai_requests and ai_safety_findings is eventually consistent: the audit_chain_seal job links new rows every 10 seconds, so a row can be unsealed for up to one seal interval, and audit_chain_verify reports the waiting count as unsealed_rows. See extensions/web/schema/51_audit_integrity.sql.

Workflow write-backs and farm runs act as service accounts that core refuses for every interactive login. Their machine credentials (GitHub App keys) are sealed with the master key, bound to one account and provider, never returned by any endpoint, and issued as a bearer only to a workflow:<id>:write or farm:<id> caller. Dynapps stores and gates them; every token is minted by core's connector_grant, the one machine-credential minter for both config-declared connectors and service accounts. See extensions/web/schema/53_connector_machine_credentials.sql.

A self-hosted Dynapps instance sends nothing to the vendor. Neither this repository nor the core it builds on has crash reporting, usage or licence pings, or an update check. Every outbound connection is one the operator configures:

1. Model providers. The upstream endpoints in services/ai/providers.yaml (Vertex AI, Anthropic, Gemini), called when a gateway request is routed to them.
2. Vertex rate-card discovery. At boot, the Vertex model list is read from the configured Vertex project to price and list the models it serves.
3. OpenTelemetry export. The collector named in the profile's observability.otlp block. Unset in the shipped profiles, so nothing is exported until a deployment names one.
4. Container images from GHCR. The deployment pulls the instance image from ghcr.io; the server process itself does not.
5. Bridge release feed. When the services manifest declares a bridge releases repository, the gateway resolves the newest bridge release from that GitHub repository on a desktop bridge's request.
6. Identity and connectors. Microsoft Entra ID (OpenID Connect) for sign-in, and the configured MCP connectors (dynapps-odoo, dynbrain) when a user uses them.

The desktop bridge checks for its own updates against the gateway it is enrolled with, never against the vendor. A cloud profile (target: cloud) or the systemprompt cloud commands additionally contact api.systemprompt.io for tenant credentials and deployment; a self-hosted profile never does.

• Branching and Releasing
• Observability Export
• Governance Modes