skip to content

For an exposed pipeline credential, which record shows it being taken from the store and which shows it being used?

level: seniorimportance: should knowfreq 45%

answer

  1. two sides, two records
  2. custody versus use
  3. the holder never calls your store
  4. ask for call source, not a verdict
  5. a stolen credential authenticates successfully

basics

~20 s

The store's read record shows which identity fetched the value and when. The counterparty's usage record shows what was called with it, and from where. Neither sees the other side, so a response needs both.

solid answer

~40 s

Two records answer two different questions. The store's read record answers *who took a copy out*, which is how you narrow the set of candidates for the escape path. The counterparty's usage record answers *what was done with it*, including calls that never came from your estate at all. This matters because whoever holds the public copy authenticates straight to the service and never touches your store: during a live exposure your own access record can look perfectly ordinary. Ask the counterparty for their record explicitly, with the call, the time and the source address on each entry, since the source address is usually the only field that separates your jobs from a stranger's calls. Neither record covers copies taken outside its retention.

code

json · 23 lines
json
{
  "storeReadEvent": {
    "at": "day 12 08:31Z",
    "identity": "pipeline-runner",
    "name": "scoring/pipeline-credential",
    "action": "read",
    "sourceAddress": "198.51.100.24",
    "result": "allowed"
  },
  "counterpartyUsageEvent": {
    "at": "day 19 03:02Z",
    "credentialFingerprint": "...c41f",
    "call": "batch:submit",
    "sourceAddress": "203.0.113.77",
    "result": "accepted"
  },
  "answers": {
    "whoCouldHaveCarriedItOut": "storeReadEvent.identity",
    "whatWasDoneWithIt": "counterpartyUsageEvent.call",
    "isThisOurTraffic": "counterpartyUsageEvent.sourceAddress",
    "neitherAnswers": "copies taken outside both retention windows"
  }
}

go deeper

for a junior

Know that there are two sides to an exposed credential: your store, which handed the value out, and the service that accepts it. Only the second sees what was actually done.

for a middle

Explain why the store's record stays ordinary during a live exposure, and why alerting built on failed authentication is silent when a valid stolen credential is used.

for a senior

Show the request you would make to the counterparty — calls, times, sources, retention boundary — and how you use source addresses to separate your own traffic from a stranger's.

for a principal

Decide what your organisation should require of a counterparty before depending on them: what usage evidence is available, in what time, and what a contract that never mentions it costs you during a response.

Reconstructing what happened to an exposed credential is a two-sided exercise, and the common failure is doing one side and reporting the result as the whole picture. ## Two records, two questions The **store's read record** shows the value leaving the store: which identity asked for it, at what time, from where, and whether the request was allowed. It is a record of *custody*. The **counterparty's usage record** shows the credential being presented to the service it authenticates to: which call, at what time, from which source, with what outcome. It is a record of *use*. | Question you must answer | Record that answers it | What that record cannot say | |---|---|---| | Who had a copy to lose? | The store's read record | Nothing about use by a holder who never read from the store | | What was done with it? | The counterparty's usage record | Nothing about how the value got out | | When did the copy leave? | Neither, directly | Bounded by the value version and what appeared beside it | | Did anyone outside call it? | The counterparty's record, by source | Only if that side records the source at all | ## Why your own record looks normal This is the part that misleads people at 2am. Someone who picked the value off a public page does not need your store, your network or an identity in your estate. They present the credential directly to the service. Consequently: - **No unusual read appears.** The store sees the same handful of identities it always sees. - **No failed authentication appears anywhere.** A valid credential succeeds; alerting built on failures is silent by construction during exactly this event. - **The volume on your side does not change.** Your jobs run at their usual rate whatever anyone else is doing. So an untroubled store record is not reassurance. It is the expected appearance of a store that was never involved in the abuse. ## Asking the counterparty, and what to ask for The usage record you need belongs to someone else, and in most arrangements you do not see it by default. Ask for it explicitly and ask for fields, not a verdict: 1. **Every call accepted with that credential** over the exposure interval, not only ones they consider anomalous — their notion of anomalous is built from your normal, which is what you are trying to establish. 2. **The source of each call**, because comparing sources against the ranges your own jobs run from is usually the only way to separate your traffic from a stranger's. 3. **Their retention boundary**, so you know where the answer stops rather than reading an absence as a negative. 4. **Whether the credential was accepted anywhere else on their side** — a second environment, an older interface — which turns a scoping assumption into a fact. ## What neither record covers - **A copy taken before either retention window begins.** The value may have left long before the page appeared. - **Use against a second acceptor that logs separately**, or does not log at all — designs genuinely differ on whether reads are recorded. - **Calls that are indistinguishable from yours.** A holder who mimics your usage pattern from a similar source is invisible in a record that only carries call, time and outcome. - **Anything derived afterwards.** If a call handed back another credential or a delivery address, the later use of *that* appears in a third place entirely, or nowhere. ## Putting them together The reconstruction that survives review reads like this: over the exposure interval, these identities read the value from the store, which bounds who could have carried it out; these calls were accepted by the counterparty, of which these came from sources we operate and these did not; and these parts of the interval are covered by neither record. The last clause is what makes the first two trustworthy. A reconstruction without it is a claim about the whole interval built from part of it, and it is the claim most likely to be repeated back to you later as a promise you did not make.

  • The counterparty's record shows only accepted calls, with no source address. What is left of the reconstruction?
    Volume and shape. Compare the count and timing of accepted calls against what your own jobs report having made; a surplus is use you did not generate, and a match is weak comfort rather than proof, because a holder mimicking your pattern is invisible. Record the missing field as a finding — it is the field that would have answered the question, and it is cheap to ask for before the next incident.
  • Why is a quiet store read record during a live exposure not reassuring?
    Because the abuse path does not pass through the store. Whoever read the value off a public page presents it straight to the service, so the store sees nothing unusual and nothing failed. A quiet record is the expected appearance of a store that was never involved, not evidence that the credential sat unused.

saying these in an interview costs you the question

  • The access record shows no odd reads, so it was unused.
  • The store would have logged the intruder's access.
  • Failed authentication alerts would have caught this.
  • The counterparty's logs are not ours to ask for.
  • The fingerprint on their record tells us who called.