A build script echoes a deployment token into the pipeline log. The log is private to the engineering team. Is the token compromised?

The short answer

Yes. Rotate it. "Private to the engineering team" is a much weaker statement than it sounds, and the cost of assuming otherwise is asymmetric.

The mechanism: where the log actually goes

A pipeline log is not one artefact in one place. By default it is typically:

• Retained for weeks or months by the CI system, long after anyone remembers the incident.
• Readable by everyone with repository access, which usually includes contractors, bots and anyone added since.
• Copied into log aggregation, where retention and access are governed by a different team's rules.
• Available through the CI provider's API, to any token with read scope - including integrations installed for other reasons.
• Cached in browsers and in chat, because someone pasted the failing section into a channel.

Each copy has its own lifetime and its own access list, and you control none of them. So the question is not whether the log is private today; it is whether every copy will remain private for the credential's whole lifetime.

The asymmetry that settles it

Rotating a deployment token costs minutes. Not rotating it means a credential of unknown exposure remains valid, and if it is ever used maliciously you cannot tell from the audit log whether the use was legitimate, because the token is a shared secret with no identity attached.

What prevents the class

• Short-lived credentials instead of static ones. Workload identity federation exchanges the pipeline's own identity for a token valid for minutes, so a leaked value expires before it is useful. This removes the problem rather than mitigating it.
• Secret masking in the CI system, enabled and verified - it works by matching known values, so it does not catch a secret the system was never told about, or one that has been transformed (base64-encoded, split, or embedded in a URL).
• Scope every credential narrowly: one environment, one action, one repository. The question after any leak is "what could this do?", and the answer should be short.
• A scanner on logs and repositories, which catches the leak you did not notice. Assume a leaked static credential is exercised within hours: public-repository secret leaks have been observed being used within minutes since at least 2019.
• Never pass secrets as command-line arguments, which appear in process listings and in shell traces.

When not to rotate

If the value was a short-lived token that has already expired, rotation is unnecessary - the expiry did the work, which is exactly the argument for short-lived tokens. And if the secret protects nothing of consequence, such as a read-only key for public data, the honest answer is to fix the logging and move on.

Everything else gets rotated. The rule to carry: the moment you find yourself arguing about whether a leaked credential really needs rotating, you have already spent more than the 10 minutes the rotation would cost.