A vendor engineer read a service credential aloud on a support call — what does a promise not to keep it buy?

## Why this event is different from every other exposure Containment normally has a target. A value in a cache has a cache you can clear; a value on a device has a device you can wipe; a value a system fetched has a session you can end. Each of those actions has a checkable result. A value a person read has none of the three properties containment relies on: - **Nothing holds it.** There is no object to delete and no holder to revoke. - **Nothing records use of it.** Read records cover reads that went through the store; a memory is consulted without touching anything. - **Nothing can confirm disuse.** The standard signal that a withdrawal is safe — the old value has not been read for a while — is unavailable, because the copy was never in the system that keeps that count. That is the whole reason an observation sits on a trigger list. It is not that a support engineer is untrustworthy; it is that trust is the *only* control available, and controls that cannot be checked are not controls. ## What the assurance is actually worth It is worth scope and a clock, and those are not nothing: | What you get | What it lets you do | |---|---| | Which value was seen | Replace one value instead of guessing at a class | | When it was seen | Set the window you assume exposure across | | Whether the session was recorded | Decide whether a second party now retains a copy, and for how long | | Who else was present | Establish how many people hold the copy, which is the scope you record | What it is not worth is a decision not to replace. An assurance cannot be verified, cannot be revoked, and does not survive the other party's own staff turnover or retention rules. ## The copies nobody mentions A spoken or displayed value rarely stays spoken or displayed. Assume, until told otherwise: - The call was **recorded**, and the recording is retained under the other party's schedule, not yours. - An **automatic transcript or caption** exists and is indexed as text, which is worse than audio. - The value reached the **ticket** as a paste or an attachment, because that is how support conversations carry evidence. - One or more **screenshots** were taken to attach to a follow-up. Each of those turns a human copy into a stored copy in a place you do not administer — which does not make containment possible, it makes the exposure longer-lived. ## The action, in the right direction 1. **Replace the value** so holders have somewhere to move. 2. **Move the holders across.** 3. **Refuse the old value** at the system that accepts it. Deleting it from your store is not this step; the accepting system has never heard of your store. 4. **Record what was seen, by whom, when**, and that the replacement was completed — because this is the class of event that otherwise leaves no trace at all. ## The prevention that actually works The structural fix is to make the value unavailable to be read in the first place: credentials fetched by the process rather than displayed, values never rendered into a screen a support session might share, and where a human genuinely must act, a short-lived credential minted for that task so the observed value expires on its own. Where designs differ is in what the store can offer here — some can mint a credential for a single task with a lifetime in minutes, others only hand back the long-lived value you put in. Say which capability your plan assumes rather than assuming every store has it. ## What an interviewer is listening for The weak answer treats the promise as the control, or reaches for a signed acknowledgement as though paperwork contained anything. The strong answer names the missing properties — nothing to revoke, no record, no disuse signal — and lands on replacement plus withdrawal, with the assurance demoted to what it really is: the scoping input.