← Docs
Helix CLI docs
Browse Helix CLI docs

Policy Governance (who can change profiles)

Objective: make policy/profile selection an auditable, role-gated decision.

Roles

  • Org admin: defines allowed profiles (dev-fast, lab-default, audit-strict) and sets defaults per project/workspace.
  • Project owner: can choose among admin-approved profiles for their project; cannot widen capabilities.
  • Operator/user: cannot lower the profile; may request temporary elevation with approval.

Controls

  • Profiles are stored per project in .helix_project.json with policy_profile and policy_path; changes require a signed commit or change-ticket ID recorded in project metadata.
  • Switching to a weaker profile (e.g., audit-strictdev-fast) must:
    • be executed via an admin-approved script or UI flow that logs who/when/why,
    • emit an audit log entry in project_logs/policy_changes.jsonl,
    • mark subsequent runs with taint policy_override until reverted.
  • Studio builds for enterprises should disable in-app profile changes unless the user is in the admin group; CLI honors HELIX_POLICY_LOCK=1 to refuse weaker profiles.
  • How to select a profile (CLI): HELIX_POLICY_PATH=policies/audit-strict.json helix run <spec.json> out --backends cpu-reference
  • Defaults: CI pins HELIX_POLICY_PATH=policies/audit-strict.json; Studio launchers can set HELIX_POLICY_PATH=policies/dev-fast.json unless a policy lock is enabled.
  • Escape hatch: HELIX_ALLOW_UNPINNED_POLICY=1 permits D2 runs with policies outside */policies/ but renders the run “not D2 pinned compliant” for audit purposes; treat any such run as downgraded trust.

Locking per project

  • Ship a read-only policy directory; set HELIX_POLICY_ROOT to that path and HELIX_POLICY_LOCK=1 in launcher scripts.
  • Keep the trust store and policy set under version control; include their sha256 in the project readme.

Logging and attestations

  • Every run records the active policy_profile and policy hash in manifest.json.
  • Policy changes should append to attestations/ or your SIEM with: user, timestamp, old→new profile, justification, and git SHA of policy files.

Review cadence

  • Quarterly: re-certify profiles and trust store; run tools/conformance.sh under each profile to ensure enforcement hasn’t drifted.