Access and approval policies

API authorization and execution policies serve different purposes. Access assignments grant operations to users or teams; policies govern approval and skipping for prepared work.

Assign the appropriate role

Use named Environments to scope non-admin assignments. admin requires environment: '*'. The API also accepts '*' for broad non-admin assignments; use a specific Environment when granting scoped access.

Create a user interactively, then apply a team and assignment:

pyplines user create alice

name: operations
members:
  - alice

name: development-operators
subject: team:operations
role: operator
environment: development

pyplines team apply ./team.yaml
pyplines access apply ./access.yaml
pyplines access list

For a direct user assignment, set subject: alice. Applying a team replaces its membership list; include everyone who should remain in it.

Require approvals

This example requires one eligible approval for each prepared step in development and prevents self-approval by the Run's initiator:

name: development-approval
environment: development
approvals: 1
allow_self: false
allow_skip: false

pyplines policy apply ./policy.yaml
pyplines policy info development-approval

Ensure another eligible Operator or Admin is available to approve. Use environment: '*' for an appliance-wide rule. Matching policies combine the highest approval count and intersect their permissions; an Environment rule cannot weaken the appliance policy.

There is no mandatory default approval. Configure policies before exposing operational workflows when approval is required. Approval counts range from 0 to 10; the current policy model has no externally loadable policy language or per-step selector.

Review changes

Policy, context, and secret changes can invalidate preparation and approval evidence. Inspect waiting Runs after changes. See approvals for operator behavior and recovery for skip and retry semantics.