Vault

Access policies

Decide who may read, use, change or manage which secrets. Owners and admins can do everything; everyone else needs a policy, and deny always wins

Who may do what

Organization owners and admins can do everything.
Members and Staff agents need an allow policy that matches. If a deny policy matches, they are refused, whatever else allows them.
End users of your apps cannot use the Vault.

A personal API token acts as the person who owns it.

Refusals are recorded in the audit log with the reason.

Permissions

Permission	Allows
`list`	See that the secret exists, never its value
`read`	Reveal the value
`resolve`	Pass the value to a step in a workflow, without showing it
`use`	Call an API with the secret through API access, without seeing it
`write`	Add new versions
`delete`	Delete and restore versions
`destroy`	Erase versions or the whole secret for good
`admin`	Manage policies, read the audit log, rotate the key

Permissions are separate. use does not allow reading the value.

use lets the holder do whatever the credential can do on the API it is bound to. Give the credential itself only the permissions it needs at the provider.

Who a policy applies to

`principal_kind`	`principal_ref`
`member`	A member's user id, or `*` for every member
`role`	A role name, such as `member` or `admin`
`agent`	A Staff agent's id, or `*` for every agent

Which secrets

* matches one part of a path: aws/*/deploy matches aws/prod/deploy.
** matches any number of parts: aws/** matches everything under aws/.

Write a policy

In the Console: Vault → Policies. From the API: vault.policy.set.

Input	Meaning
`name`	A unique name. Using an existing name replaces that policy
`principal_kind`, `principal_ref`	Who it applies to
`path_pattern`	Which secrets
`capabilities`	One or more permissions from the table above
`effect`	`allow` (default) or `deny`
`description`	Why the policy exists
`disabled`	Keep the policy but stop applying it

vault.policy.list shows your policies and vault.policy.delete removes one.

Examples

Let a Staff agent call GitHub with one token, and nothing else:

{
  "name": "ci-agent-github",
  "principal_kind": "agent",
  "principal_ref": "<agent id>",
  "path_pattern": "github/ci/token",
  "capabilities": ["use"]
}

Let every member see and reveal shared secrets:

{
  "name": "members-shared",
  "principal_kind": "role",
  "principal_ref": "member",
  "path_pattern": "shared/**",
  "capabilities": ["list", "read"]
}

Keep production secrets away from every agent:

{
  "name": "no-agents-on-prod",
  "principal_kind": "agent",
  "principal_ref": "*",
  "path_pattern": "**/prod/**",
  "capabilities": ["read", "resolve", "use", "write", "delete", "destroy"],
  "effect": "deny"
}

Only owners and admins can set API access on a secret. Give admin only to people you would trust as admins.

Secrets

Store a secret at a path, keep its versions, reveal it to the person who asks, and delete, restore or destroy it

API access

Let workflows and agents call an API with a Vault secret they never receive. The Vault calls only the hosts you allowed and removes the secret from the response