Approve a reveal
A coding agent asks for one value, and a person answers within ten minutes.
When a coding agent runs penv reveal KEY, it gets an approval id and exit code 4 back. The value is never in that answer. A person opens /approvals/[id] and decides.
What the page shows
| Field | What it tells you |
|---|---|
| Key | The path and name being asked for. Never a value |
| Project and environment | Where the key lives |
| Who asked | The person whose session the agent is running under |
| Device, harness and session | The machine, the tool driving it, and that session's id |
The harness and the session are labels the command line sent. They authorize nothing and are cut off at 128 characters. What they are for is asking, weeks later, which keys one agent session touched.
A request that was already answered, ran out, or belongs to another workspace reads as "No such request". A distinct answer would confirm that an approval exists.
The ten minutes
A request expires ten minutes after it is filed. That window covers the whole exchange rather than the wait for your answer, so an approval you gave and the agent never collected expires too.
One approval is spendable once. The row is claimed before anything is decrypted, because a claim burned by a failed decrypt costs one more click and a value opened twice costs the secret.
Approving
Answering needs secret:reveal at that environment, the same grant that would let you open the key yourself, and then confirming it is you (step-up). The permission is checked first, so somebody who was never allowed is told that rather than sent to fetch a code that would not have helped.
Both the permission and the step-up are read fresh at the moment you decide, so an approval never outlives the role it rested on.
Read the key name and the session before you approve. You are opening one specific value to whatever is driving that session.
What each action needs
| Action | Needs | Confirm it is you | Recorded as |
|---|---|---|---|
| Open the page | secret:reveal at that environment | No | not recorded |
| Approve | secret:reveal at that environment | Yes | secret.reveal_approved |
| Deny | secret:reveal at that environment | Yes | secret.reveal_denied |
Four entries, five when a collection is turned away
One approval lands four entries in the record:
secret.reveal_requested, the agent's asksecret.reveal_approvedorsecret.reveal_denied, your answersecret.read, the read itself, in the name of whoever askedsecret.reveal, naming you beside the session that asked
A redemption the server turns away adds secret.reveal_refused, carrying the state that turned it, which is one of pending, denied, expired or already spent.
The read is recorded in the requester's name, because that is whose credential opened it. Who allowed it is the separate fact secret.reveal holds.
Requests that ran out are settled quietly. Nobody acted, and the refusal an agent gets when it comes back late is the entry worth having.
Next: workspace name and region.