A long-running consumer asks the store to derive a child credential from its own bounded session — what can that child carry?

## Derivation, and the one thing it cannot do A caller that already holds a bounded session can often ask the store for a second, narrower credential to hand to something else — a worker it is about to start, a one-off task, a sidecar job. The new credential is **derived**: the parent session is the authority being spent to create it. The invariant is that derivation cannot amplify. The child holds a **subset** of the parent's rights, never a superset, and never something the parent does not hold at all. This matters most in the case where the two might differ: if the parent session's rights were narrowed relative to what its identity could get — because it asked for less, or because the rule was tightened before it authenticated — the child is bounded by the *session*, not by the identity behind it. A caller cannot derive its way back up to the identity's full grant. ## What a well-shaped child carries You normally take *less* than the ceiling allows, on three axes: - **Names.** One branch of the name space, matching what the receiving worker actually reads. - **Verbs.** Read where the parent holds read and write. Withholding *list* matters on its own, because the right to list a branch discloses what exists there even when every read is refused. - **Time.** A window sized to the work, not to whatever the parent has left. A child that lives for the batch is a credential you do not have to chase afterwards. The gain is containment arithmetic: if the child leaks, the blast radius is the slice you handed over, and the exposure ends when its window does. ## Whether the parent's end reaches the child This is the part that genuinely differs between designs, and the part candidates state as universal in both directions. | If the store… | Ending the parent… | Containment means… | |---|---|---| | records the parent-child link | walks it and ends the children too | one action against the parent | | cuts the child loose at creation | leaves every child alive to its own window | finding and ending each child, or waiting out its window | A cut-loose child is not a defect by itself — it exists precisely so a worker does not die when the process that started it goes away. It becomes a defect when nobody wrote down that it works that way, because then the incident plan says "end the parent session" and quietly achieves nothing for the credentials that are actually being used. ## The consequence in an incident Work the message-consumer case. The consumer authenticated at deploy time, three weeks ago, and has since derived a short-lived child for each batch it runs. You now believe the host is compromised. Ending the parent session is one call and it feels decisive. Whether it *is* decisive depends entirely on the link: 1. If children are tied to the parent, the derived credentials stop with it, and the residual exposure is whatever was in flight. 2. If children are cut loose, the attacker keeps every child already minted, for as long as each one's window runs, and you are now enumerating credentials you never inventoried. Either way, ending the parent does stop *new* children being derived — which is why it stays the first move, not the only one. ## Practical rules - **Know the link behaviour before you need it.** Derive a child, end the parent, try the child. The result takes one minute and settles the argument permanently. - **Size the child's window to the work**, so that the wait-it-out path is short even when the kill path does not exist. - **Keep a record of what was derived and for whom.** Where children are cut loose, the only thing standing between you and an unbounded search is that record. - **Do not use derivation to work around a narrow rule.** If a worker needs rights the parent does not have, the answer is its own identity and its own rule, not a child. ## The distinction people lose A derived credential is still the caller's *access to the store*. It is not a credential the store generated in a downstream system on the caller's behalf — that object has its own expiry story and is withdrawn by acting on the system that accepts it. Keeping the two apart is what lets you answer precisely when someone asks what the compromised host can still do.