A secret store hands a caller a bounded session at authentication — what is fixed at that moment, and what is not?

## What authentication actually hands back A secret store rarely re-checks a caller's proof of identity on every request. Authentication is an exchange: the caller presents whatever proof the store accepts, the store decides **which identity** that proof belongs to, resolves **which rights** that identity has, and hands back a handle the caller presents on every later call. That handle is a **bounded session**. *Bounded* means two things at once — it stops working at some point, and it carries a fixed set of rights rather than open-ended membership. One distinction has to come first, because the two objects are swapped constantly. A **session** bounds *the caller's own access to the store*. A **lease** bounds *a credential the store issued, on that caller's behalf, to some downstream system* — a generated database account, for instance. They expire differently, they are ended differently, and only the first is the subject here. ## What is settled at the moment of issue - **The identity.** The proof is evaluated once. Later calls are accepted because they carry the session, not because the proof is re-examined. A proof that would be rejected today does not retroactively invalidate a session issued while it was good. - **The rights resolved for that identity.** The store reads the rules attached to the identity and turns them into this session's authority — which branches of the name space it may read, write or list. - **That a validity window exists, and when it started.** How long that window runs, how it is extended, and the ceiling past which nothing extends are a neighbouring subject. What belongs here is that the window is attached at issue and is not open-ended. - **Whether there is anything to end.** Some stores record the session and hand back a reference an operator can use to end it; others hand back a self-contained proof they verify without consulting any record. That is decided at issue too, and it decides containment later. ## What is not settled - **The values behind the rights.** A read is live. Whatever the store holds at the moment of the call is what comes back. A session is permission to ask, not a snapshot of answers. - **Which of those rights the caller will use.** Nothing is declared in advance; the access trail is written as calls happen, not predicted at issue. - **The downstream credentials the caller may go on to request.** Those are separate objects with their own expiry stories. ## The consumer that authenticated three weeks ago A message consumer authenticated once at deploy time and has been running on the same session ever since. Today someone narrows the rule behind its identity — the branch of names it may read shrinks. Ten minutes later, the consumer is still reading the value it always read. That is not automatically a bug, and it is the most common surprise in this material. Two designs are both in the field: | Question | Rights resolved at issue | Rule consulted per request | |---|---|---| | When does a narrowed rule bite? | at the next session, not this one | at the next request | | What is on the request path? | the session record only | the rule store as well | | What can you tell an incident commander? | exactly what this session can reach, from the session itself | what the rule allows right now | | How do you cut a live caller off? | end the session | edit the rule, or end the session | Neither behaviour is universally true of secret stores, so the answer an interviewer is listening for is not a verdict. It is *"it depends on whether this store froze the rights or re-reads them, and here is how I would find out."* ## Finding out 1. Issue a session for a test identity and confirm it can read a chosen name. 2. Narrow the rule so that name is no longer covered. 3. Read again on the **same** session. Success means the rights were frozen at issue; refusal means the rule is consulted per request. 4. Authenticate afresh and read again, to confirm the narrowed rule is genuinely in force for new sessions. ## Why it matters past curiosity Narrowing a rule is often someone's first containment move. If the store froze the rights, that move does nothing at all to sessions already issued, and the action you actually needed was to end the session. It is also worth keeping the three verbs apart: **rotation** puts a new value in place, **revocation** makes an existing credential stop working, and **narrowing a rule** changes what future resolutions allow. Only one of them reaches a caller that is already holding resolved rights, and on some designs none of them does until the window runs out. One practical habit follows: record the resolved rights *in* the session record. Then an external audit that asks what a given session could have reached is answered from one row, rather than by replaying the history of every rule edit since it was issued.