Bind a slot to a session under a new grant, and stamp the occupancy #35

New issue

Closed

opened 2026-09-03 18:24:39 +00:00 by larandar · 0 comments

larandar commented

2026-09-03 18:24:39 +00:00

Owner

Proposal

Allocate a pool slot to a session under a fresh immutable grant, and write the occupancy onto the slot's OpenBao entity alias so the session's secret paths are its own.

Delivery class

agent-unit — allocation and the alias write, against OpenBao capture doubles.

Design

Checkout binds a slot under a new immutable AssignmentGrant, inheriting no lease, token, or authority from any previous occupancy. Reuse of a slot is not reuse of its history.

The occupancy is stamped onto the slot's entity alias as custom_metadata. This is what makes the swarm KV path per-occupancy rather than per-slot: the consumer is written and under review in flake-ops#471, rendering swarm/data/<swarm>/drones/<slot>/<assignment>/*, and that path shape is this record's acceptance.

Two things a reader will otherwise get wrong, both found the expensive way:

It cannot be a claim. A kanidm claim map is valuesByGroup, so a claim carries only what the directory asserts about an account. Occupancy changes per allocation and has no group to hang on; one group per assignment would leak the pool's churn into the directory. Alias metadata is rewritten from claim mappings on every login — custom_metadata is written out of band and a login does not touch it, which is the lifetime this value needs.
The contract's assignment_id is not this. QueenAuthorityRef.assignment_id names the queen's tenure assignment that authorized a request — one value shared by every drone under a queen. It cannot separate two occupants of one slot, and a path built on it looks isolated and is not.

This record does not decide when a slot is free. That gate is #37 and waits on an unresolved mechanism; allocation here presumes a slot already judged available.

Tasks

Bind a slot to a session under a new immutable grant.
Prove the binding inherits no prior lease, token, or authority.
Write the occupancy to the alias custom_metadata, not to metadata and not via a claim.
Prove two successive occupants of one slot cannot reach each other's paths, against flake-ops#471's shape.

Specification Delta

Requirement: occupancy is what isolates, not the slot

Scenario: two successive occupants of one slot

GIVEN a slot allocated, returned, and allocated again
WHEN the second occupant reads its workspace and report paths
THEN it cannot reach the first occupant's workspace or reports

Requirement: a binding inherits nothing

Scenario: a slot is allocated after a previous session

GIVEN a slot previously bound to a completed session
WHEN it is allocated again
THEN the new session holds a new immutable grant
AND no lease, token, or authority from the previous session is valid

OpenSpec

OpenSpec 30

Structural parent

Vedanta#31

## Proposal Allocate a pool slot to a session under a fresh immutable grant, and write the occupancy onto the slot's OpenBao entity alias so the session's secret paths are its own. ## Delivery class `agent-unit` — allocation and the alias write, against OpenBao capture doubles. ## Design Checkout binds a slot under a **new immutable `AssignmentGrant`**, inheriting no lease, token, or authority from any previous occupancy. Reuse of a slot is not reuse of its history. The occupancy is stamped onto the slot's entity alias as **`custom_metadata`**. This is what makes the swarm KV path per-occupancy rather than per-slot: the consumer is written and under review in [flake-ops#471](https://jo.et0.pw/lar.ad/flake-ops/pulls/471), rendering `swarm/data/<swarm>/drones/<slot>/<assignment>/*`, and **that path shape is this record's acceptance.** **Two things a reader will otherwise get wrong, both found the expensive way:** - **It cannot be a claim.** A kanidm claim map is `valuesByGroup`, so a claim carries only what the directory asserts about an account. Occupancy changes per allocation and has no group to hang on; one group per assignment would leak the pool's churn into the directory. Alias `metadata` is rewritten from claim mappings on every login — `custom_metadata` is written out of band and a login does not touch it, which is the lifetime this value needs. - **The contract's `assignment_id` is not this.** `QueenAuthorityRef.assignment_id` names the *queen's tenure assignment* that authorized a request — one value shared by every drone under a queen. It cannot separate two occupants of one slot, and a path built on it looks isolated and is not. **This record does not decide when a slot is free.** That gate is [#37](https://jo.et0.pw/Ting/Vedanta/issues/37) and waits on an unresolved mechanism; allocation here presumes a slot already judged available. ## Tasks - [ ] Bind a slot to a session under a new immutable grant. - [ ] Prove the binding inherits no prior lease, token, or authority. - [ ] Write the occupancy to the alias `custom_metadata`, not to `metadata` and not via a claim. - [ ] Prove two successive occupants of one slot cannot reach each other's paths, against flake-ops#471's shape. ## Specification Delta ### Requirement: occupancy is what isolates, not the slot #### Scenario: two successive occupants of one slot - **GIVEN** a slot allocated, returned, and allocated again - **WHEN** the second occupant reads its workspace and report paths - **THEN** it cannot reach the first occupant's workspace or reports ### Requirement: a binding inherits nothing #### Scenario: a slot is allocated after a previous session - **GIVEN** a slot previously bound to a completed session - **WHEN** it is allocated again - **THEN** the new session holds a new immutable grant - **AND** no lease, token, or authority from the previous session is valid ## OpenSpec [OpenSpec 30](https://jo.et0.pw/Ting/Vedanta/wiki/OpenSpec-30-agent-identity-pool-lifecycle) ## Structural parent [Vedanta#31](https://jo.et0.pw/Ting/Vedanta/issues/31)

~~larandar referenced this issue 2026-09-03 18:25:13 +00:00~~

Free a slot only on explicit release — never by inference #37

larandar added the

Kind/Feature

Kind/Security

labels

2026-09-03 18:25:21 +00:00

larandar added a new dependency

2026-09-03 18:25:30 +00:00

#31 Session: pool checkout and return — the steady-state slot cycle

larandar referenced this issue from a commit

2026-09-03 22:28:11 +00:00