A CI leak drill measures the time between spotting a key in the log and revoking it

The containment happens in the API that accepts the token. The test job gets a read-only fixture token, the deployment job gets a deploy token, and the post's requirement is that neither is accepted by the other API surface ^[6]. Each token carries one audience, one action set and one expiry, with the workflow identity bound to the repository and ref where that is available ^[5]. This only holds if the issuing service will mint per-job tokens and check the audience on every route. Where one key is honoured everywhere, the scoping in the workflow file leaves a printed string exactly as powerful as it was.

The example pipeline publishes a worker, runs integration tests and uploads a diagnostic bundle. The post calls those different trust boundaries ^[3]. One account-wide key spans three of them in a single run ^[2]. A line printed by a Node.js dependency becomes access to billing data, or transcripts, or unrelated queues ^[4].

"I treat the build log as public until proven otherwise," the author wrote ^[7]. "Masking helps, but it is not a security boundary: a transformed value, an error object, or a verbose child process can evade a simple exact-string masker" ^[8]. Masking stays. The change sits upstream of the log, by keeping the secret out of commands that do not need it and passing it through the runner's secret mechanism only at the step that uses it ^[9]. For a Node.js job that means holding the key in process memory and not interpolating it into a shell command ^[12].

The sample revocation step is Python: a DELETE to /v1/account/keys/revoke/{key_id} with a Bearer token and an explicit ten second timeout ^[13]. It treats 200 and 204 as success and raises on anything else ^[14], so a gateway that answers 202 Accepted for an asynchronous revoke would fail the drill on a successful revocation ^[1]. A 429 raises with an instruction to wait for the server-provided Retry-After delay ^[15]. Revocation is idempotent by nature, and repeating it for the same key ID leaves the key revoked; for other writes the post asks for an idempotency key and backoff instead of an immediate retry loop ^[16].

A cancellation halfway through a deployment, a retry after revocation, and a forked pull request that must not inherit write credentials are all in the drill ^[17]. GitHub Actions environments can require approval for protected deployments, while repository and organization secrets still need a policy that separates trusted branches from untrusted forks ^[18]. The post also asks teams to document what the runner can read and what it can persist between jobs ^[23]. On the negative path, a revoked key must fail clearly and the pipeline must stop before publishing artifacts that depend on an authenticated call, without retrying a 401 forever ^[22].

Two of the three failure modes the post lists survive a perfect rotation schedule. A rotated key that retains access to every project is still overbroad, and access left behind after a branch or repository is deleted stays live ^[20]. "Rotation does not fix a policy that never removes old subjects," the author wrote ^[21]. This is a design note written against a fictional endpoint, api.example.test, with the control flow and the explicit timeout offered as the point ^[24], and it does not include measurements from a real leak ^[3].