The release manager says your build-runner finding was an engineer debugging a failing job. How do you settle it?

## The two honest outcomes A hunt hit on build infrastructure resolves one of two ways, and the vocabulary matters because interviewers listen for it. - **Benign true positive.** The behaviour happened exactly as your query described, and it was legitimate. Your query was right; your suspicion was not. This is not a false positive — a false positive is when the matched records do not represent the behaviour you were looking for at all. - **Intrusion.** The behaviour happened and nobody with authority accounts for it. The release manager's statement is a hypothesis about which of these it is. It is testable, and it is not evidence until it reconciles with records. ## What actually separates them **Does the work exist in the pipeline definition?** The strongest single check. A build job's steps come from a definition in the repository. Commands appearing in step output that are not in that definition for that revision came from somewhere else — an injected step, an interactive session, or a compromised dependency of the build. Reconciling step output against the committed definition at the commit the job ran is cheap and decisive. **Which identity, arriving how?** There is a large difference between activity performed by the runner's own job execution and a human shell session to the runner host. Establish the authenticated identity and the path: platform job trigger, an interactive login, an agent, or automation credentials. Remember what an authentication record proves — that a credential was accepted, not that the named person was present. **Is there a paper trail on the human side?** A change record, an incident ticket, a chat message, a failing build the engineer was chasing. Legitimate debugging usually leaves a trail somewhere other than the runner, because it happens in the middle of someone's working day and someone else usually knows. **Does the shape of the activity match debugging?** Debugging tends to be iterative, repetitive, and locally scoped: re-running a step, printing a variable, retrying with a flag. Collection and staging look different: a single sweep over a broad set of paths, an archive written outside the workspace, a bulk dump of environment or credential material, then an outbound transfer. Both can be scripted; the difference shows in the breadth and the direction of the data. **Did it touch things the job does not need?** A publish job needs its publishing credential. It does not need the whole home directory's container-registry configuration, and it does not need every environment variable dumped to a file. Access beyond the job's purpose is the sharpest indicator on this surface. **Did anything leave?** Here be precise about what your evidence supports. A job log showing an upload command proves a process ran and a request was issued. It does not prove delivery, and it says nothing about the content. Delivery is a question for proxy or flow records — and a flow record carries a five-tuple, byte and packet counts and timestamps, and **no payload at all**, so it can show that bytes moved and never what they were. ## Talking to the engineer Ask. Directly, through a channel that is not the possibly-compromised system, with specific times and specific commands rather than "did you do anything unusual". Two cautions. First, an account holder's denial and an account holder's confirmation are both assertions — a compromised account is used by someone who is not its owner, so a confident "yes that was me" from a person who was asleep does not exist, but a confident "no" from someone whose credentials were stolen is entirely consistent with an intrusion. Second, if you genuinely suspect the person rather than their credentials, that conversation is not yours to open unilaterally. ## The manager's real problem The release manager is not being obstructive. Freezing the runner stops the release train, and in this environment the security team has read access to build infrastructure and no authority to stop a pipeline. That makes the burden on you concrete: bring a reconciliation, not a suspicion. "These four commands are not in the pipeline definition at that commit, they ran between two of its steps, and they read the registry credentials this job does not use" is a sentence a manager can act on. "The activity looked suspicious" is not. ## Closing it either way If it reconciles: close as a **benign true positive**, record the legitimate pattern so the next hunter does not re-litigate it, and note the practice itself as a risk if it involved humans running ad hoc commands on shared build agents. If it does not reconcile — nobody claims it, no change record, commands absent from the definition, credentials read that the job never needs — you escalate with what you have, and you say plainly that the reconciliation was attempted and failed. That negative result is a substantial part of the case.