Access policies

Two gates: who may ask, and who must approve. Access policies are the first gate. They decide which principals may act on which secret paths. The second gate, the approval quorum, decides who must countersign a release. The two compose, and the access policy can only ever tighten the result.

Path-scoped access policies ship on Team and above.

How policies work

A policy is a JSON document in the familiar AWS/S3 style. Each statement names principals (roles, users, groups, agents), the actions they may perform (request, store, approve, manage), and the secret paths those actions apply to. Paths support S3-style * wildcards.

Evaluation is default-deny. Nothing is allowed unless a policy grants it. An explicit deny always wins over any allow. The org owner is root and is never locked out.

Example

Allow an agent to request secrets under db/prod/:

{
  "statements": [
    {
      "effect": "allow",
      "principals": ["agent:ci-deployer"],
      "actions": ["request"],
      "paths": ["db/prod/*"]
    }
  ]
}

Access and approval are independent

Access decides who may ask for or act on a secret. Approval decides who must countersign its release. They are separate gates, evaluated independently. An access policy can narrow who may request a secret, but it can never weaken the human-approval requirement on a path. To change who countersigns, configure approver groups.