Safety and authority model

Helmhive follows one governing rule: models propose; schemas constrain; application policy authorizes; named people approve; narrow brokers execute; evidence verifies; audit records.

Where automation stops

AI implementation ends at a pull request with approved local checks, an independent review, and a human handoff. Merge, release, deployment approval, and production execution remain separate actions with their own authority and audit history. Helmhive never merges a pull request, creates a release, or deploys on its own.

Authority is explicit and bounded

• Provider permission is only a ceiling. A repository source may see many repositories. Each service’s execution policy and the people assigned to it grant less, never more.
• Discovery never enrolls. Someone with the right capability enrolls a repository explicitly and confirms its policy.
• Approval binds one exact thing. Implementation plans, deployment plans, and rollback plans each hash everything they depend on. If any input changes, the approval no longer applies and a fresh plan is required.
• Roles never inherit. Workspace and service roles are independent, and approval permissions are evaluated one by one. See Roles and permissions.
• Labels route, capabilities authorize. Runner labels and placement constraints select compatible infrastructure and never grant a user, service, or job any authority.

Credentials stay where they belong

• AI runners never receive repository-source credentials or the pull-request bot token. They receive a bounded archive of the exact source snapshot.
• Pull requests are opened by a server-side broker with a separate, validated bot identity and an exact repository allowlist.
• Deployment runners keep SSH, encryption, registry, cloud, and platform credentials on their host. The workspace sees only authority aliases and non-secret connection configuration.
• Provider logins for AI runners are made on the runner host. The console sees only whether they are healthy.
• Browser code never receives connector, runner, or administrator credentials. One-time tokens and invitation links are shown once and stored only as hashes.

Deployment execution is gated

Deployment authority is separate from change delivery: a deployment runner is a trust domain the change workflow cannot reach. Production plans need a workspace Administrator and an explicit production acknowledgment. On top of that, a server-side gate controlled by the people operating your installation decides which workspace, service, and environment combinations may execute at all; in the current release only the sandbox marker adapter can run and production execution is disabled. See Deployment model.

Everything privileged is audited

Every privileged transition writes an append-only, workspace-scoped audit event whose details are bounded and redacted at the write boundary. Human, machine, and on-behalf-of actions carry their correlations to the request, plan, approval, commit, and artifact involved. Reading or exporting the trail is itself audited. See Review activity and the audit trail.

Deliberate limits

• No automatic merge, release, or production deployment.
• No AI-drafted criteria shown to Requesters directly: the draft goes through a Developer, and the original requester confirms the final criteria.
• No automatic memory promotion, embeddings, or semantic retrieval.
• No automation whose authority is inferred from natural language. Every write remains constrained by explicit capabilities, scopes, deterministic policy, and auditable gates.