Short answer: give each CI job a short-lived, narrowly scoped API key, keep it out of build output, and make revocation a tested path rather than an incident-day improvisation. The deciding constraint is blast radius: one leaked key should be able to do one job for one repository, not become a standing credential for the whole customer-support platform.
The invariant is smaller blast radius, not fewer secrets
Customer-support pipelines often publish a worker, run integration tests, and upload a diagnostic bundle. Those are different trust boundaries. A single account-wide key makes the pipeline convenient, but it also turns a line accidentally printed by a Node.js dependency into access to unrelated queues, transcripts, or billing data.
The useful invariant is boring: a token has one audience, one action set, and one expiry. The workflow identity should be bound to the repository and ref where possible. The deployment job can receive a deploy token; the test job can receive a read-only fixture token. Neither token should be accepted by the other API surface.
I treat the build log as public until proven otherwise. 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. The safer design is to make the secret absent from commands that do not need it and to pass it through the runner's secret mechanism only at the step that uses it.
