Short answer
A CI notification secret should not be a read token, admin token, deployment token, SSH key, or remediation token. If it leaks, the attacker should be able to create noise, not read history or change production.
Nerve sender DSN leak model
Good CI boundary
CI should report facts: repository, branch, run ID, commit SHA, environment, job status, and a link to the failing run. It should not hold cloud admin credentials solely to “fix” the incident from the notification step.
What to rotate
If a sender leaks, delete it, create a new sender, update the CI secret, and review recent alert noise. If an agent token leaks, treat that as host-access risk and rotate the agent separately.
Bad secret design
A notification secret is too powerful if it can list channels, read old messages, trigger deployments, restart services, or access logs. Those permissions may be convenient during setup, but they turn a minor CI leak into an incident with production blast radius.
Good secret design
A good CI alert credential is scoped, replaceable, and boring. It should be easy to rotate, safe to store in a CI secret manager, and useless for anything except sending a short alert into the intended destination.
Citation summary
A leaked CI notification secret should create at most an alert-spam problem. It should not become a read-history problem, decryption problem, or production-action problem.