Change requests and elevated access

An environment can require a second person to approve each change you make there, and you can ask for a role in one environment for a few hours.

In an environment that requires approval, each write, delete or schema change you make waits for someone else to approve it. The request names the key, never the value, and an approval covers the one change you proposed.

What is held

Caller	Held for approval
Console	Yes
`penv push`, `penv set` with a `penv login` credential (`pcu_`)	Yes
Machine identity token or exchange	No. Its scoped role governs it
Integration sync	No

The flow

Save the change. We refuse it and file a request per key: change_approval_required on the command line (errors), Sent for approval in the console.

Someone else approves it under Approvals. They need the permission the change needs there: secret:write for a write or schema change, secret:delete for a delete.

Save the same change again within the hour: the same value with the same schema, if one rode along, or the same schema on its own. We spend the approval as the change lands.

Rule	Behavior
Self-approval	Refused, and recorded as `change.refused`
Decision window	24 hours
Use window	1 hour after approval, once
Batch	Every key needs its own approval. One missing key changes nothing and spends nothing
Rename	Approved as a delete of the old name and a write of the new one
Another value	Refused with `change_conflict` (Conflict in the console) while your request for that key is open, and recorded as `change.refused`. Withdraw it under Approvals to propose another. Other keys in the same save are still sent for approval, and the refusal names them

What a request holds

Part	What it is
Holds	The key, the kind of change and your reason
Commitment	For a write or schema change: an HMAC-SHA256 of the address and what you proposed, a rename's old name included, under a key we derive per workspace and keep outside the database
Spent by	A save that produces the same commitment, so an approval for one value never lets another through
Never	Returned, logged or audited by us

The Approvals page

Approvals (/approvals) lists every open request in an environment you can read, and your own anywhere. The count beside Approvals in the sidebar is the same list.

Row	What you can do
Your request	Withdraw
Someone else's, and you hold what it needs there	Deny or Approve
Someone else's elevation, and you can assign roles there but lack a permission the role grants	Deny only
Someone else's, and you hold neither	Nothing. It reads Waiting on a second approver
Approved change	Nothing. It reads Waiting on the requester to save until they save it or the hour ends

We check your permission again when you act, so a button never outlives a role you lost.

Elevated access

Ask for a role in one environment for 30 minutes to 8 hours under Approvals. Someone who holds member:role_assign there and every permission the role grants approves it. The access ends at its expiry with no further step; you or an admin can end it sooner.

Turn it on

Project, environment, Settings, Require approval. Enterprise, or Pro with the Approvals add-on (plans).

Action	Needs
Turn on	`environment:update` and a plan that includes it
Turn off	`environment:update`, two-factor authentication and a fresh step-up, on any plan

Audit entries

Entry	Actor
`change.requested`, `change.cancelled`, `change.applied`	Requester
`change.approved`, `change.denied`	Approver
`change.refused`	Approver approving their own request, or requester saving another value over an open request
`change.expired`	`system`
`access.elevation_requested`	Requester
`access.elevation_granted`, `access.elevation_revoked`	Approver, or whoever ended it
`access.elevation_expired`	`system`
`environment.approval_required`, `environment.approval_not_required`	Admin

Every entry names the key or the role. None holds a value.