Secrets Manager Policies

An SM policy is a Vault-syntax HCL document declaring which paths a caller can read, list, create, update, or delete. Policies are scoped to the workspace and attached to callers via auth-method-issued tokens.

Policy example

# policies/prod-read.hcl
path "secret/data/prod/*" {
  capabilities = ["read", "list"]
}

path "database/creds/prod-postgres" {
  capabilities = ["read"]
}

path "transit/decrypt/prod-payments" {
  capabilities = ["update"]
}

# Deny everything under staging
path "secret/data/staging/*" {
  capabilities = ["deny"]
}

Create + attach

tt secrets policies write prod-read policies/prod-read.hcl
tt auth-methods approle update prod-app --token-policies=prod-read

The mapping between workspace RBAC roles and SM policies is configurable — see Settings → Secrets Manager → Role Mapping. A sm_user doesn’t automatically get access to secret/prod/*; you decide the mapping.

Capability reference

Capability	Meaning
`create`	POST/PUT to a new path
`read`	GET
`update`	POST/PUT to an existing path
`list`	LIST
`delete`	DELETE
`sudo`	Bypass normal ACLs (root-protected paths)
`deny`	Hard denial (wins over any other match)

Path patterns

secret/data/prod/* — glob any single path segment after prod/
secret/data/prod/+ — Vault-style single-segment placeholder
secret/+/config — placeholder in the middle

Access methods

Who your caller is — OIDC / JWT / AppRole / K8s / cloud IAM.

Rotation

Emergency rotation gated by a separate policy.

Rotation Policies Access Methods

​Policy example

​Create + attach

​Capability reference

​Path patterns

​Related