Permissions

The Permissions tab decides what a machine identity may reach. Everything attached here applies to every key of that identity — keys differ only in their envelope and in whether they were narrowed.

You need secrets:policy:manage to attach or detach. Seeing what a machine already holds is a lower bar — secrets:secret:read is enough — so a teammate can review a machine's reach without being able to change it. If this tab says it cannot show you the permissions, that is about your access, not the machine's: see Who may see and change permissions.

Attach here, author in the library#

This tab attaches existing permissions. Writing one — choosing actions, writing path patterns, setting an expiry — happens on the Permission library screen and only there.

That split is deliberate: when both screens could author a permission, the two copies of the pattern rules drifted, and which screen you happened to be on changed what you were allowed to express. If there is nothing left to attach, the tab links you to the library to define a new one.

Search the library by name, pattern or action, tick as many as you need, and attach them in one action.

Templates need a path#

A library entry with no patterns of its own is a template: it names an intent — "read this environment" — and the path is supplied when you attach it. The list marks these template — needs a path.

Entries that may match across environments are badged cross-env. In a space where an administrator has enabled the guardrail, creating such a permission requires an organization admin — an existing one keeps working, so turning the guardrail on never breaks a running pipeline.

Blast radius#

Above the tabs, the blast radius panel resolves the machine's patterns against the project's real secret paths:

reaches 16 secrets across 3 environments — including prod

This is the number to review, not the count of policies. "Holds 4 permissions" tells you nothing about exposure; "reaches prod" does. Check it after every attach, and treat an unexpected environment in that list as the finding it is.

What a permission grants#

Each carries actions (read, write, delete, list, rotate, or *) and patterns over the canonical path {project}/{env}/{namespace}/{secret}. A machine may do something only if one of its permissions allows it — and an explicit deny always wins, even over an allow granted elsewhere.

The pattern language, wildcard rules and evaluation order are on Access policies.

Permissions may also expire, both in the library entry itself and in this machine's attachment of it. Expiry is evaluated, never swept: a lapsed grant simply stops matching, so there is no window in which it still works because a job has not run yet. An attachment's own expiry is how you give one machine temporary elevation without loosening the library entry everyone else uses.

Detaching#

Detaching removes the permission from this machine. Inheriting keys lose that reach immediately; limited keys that were narrowed to it lose it too.

A machine with no permissions#

An identity with nothing attached authenticates successfully and then fails every request with a denial. That is intended: authentication answers who, authorization answers what, and collapsing them would make "this key is broken" and "this key may not do that" the same message. The Permissions tab says so plainly when the list is empty.

Related#

• Re-scope & settings
• Access policies · Default permissions
• Namespace access (people & teams) — the human-plane equivalent