Images are AI-generated illustrations, not documentary photographs or product screenshots.
Client secrets: identify secrets before sharing files
Credentials, private keys, tokens and certain connection details should not be treated as ordinary project text. List where they enter the workflow and which tools genuinely require them. Use an approved secret-storage mechanism rather than copying values into a README or task description. Keep client ownership and access responsibilities clear. If a demonstration needs configuration, use fictional placeholders and explain how an authorized operator supplies real values without publishing them.
Keep values outside source control
Do not hardcode production credentials in application code or workflow files. Use the supported configuration and secret facilities for the relevant platform. A local ignored file is not automatically secure; it can still be copied into backups or uploaded elsewhere. Review build artifacts and example files as well as the main repository. Never provide client secrets to an unapproved AI tool to troubleshoot an error. Explain the issue using redacted context and non-sensitive reproductions.
Limit which jobs and people receive access
Grant only the permissions needed and avoid making production secrets available to untrusted code paths. GitHub’s secure-use guidance discusses least privilege, environment reviews and risks around privileged workflow triggers. Read those rules in the context of the actual repository. Do not copy a deployment example without understanding when it runs and what inputs it executes. A workflow that works successfully once can still expose credentials under a different event or contributor path.
Inspect logs instead of trusting masking
GitHub notes that automatic redaction is not guaranteed, especially when values are transformed or structured. Avoid printing secrets in the first place and check how errors are reported by commands and third-party actions. A token can appear in a URL, debug message or encoded form. Review appropriate test logs using valid and invalid non-production inputs. Keep logging useful for diagnosis while minimizing sensitive material, and protect access to the logs themselves.
Rotate exposed credentials
Deleting the visible value from the latest file does not invalidate a copied secret. If exposure occurs, revoke or rotate the credential through the provider’s supported process and assess related access. Follow the client’s incident procedure and document what was affected. Do not conceal the event because the deployment still works. Removing a log or repository value may reduce continued exposure, but it is not a substitute for invalidating an already compromised credential.
Make handover include secret ownership
Record where credentials are managed, who owns them and how future authorized rotation works, without including the values in an ordinary document. Remove contractor access that is no longer required and test the client’s supported maintenance path. Review third-party integrations periodically. A safe workflow includes provisioning, use, monitoring, rotation and offboarding. Its success is not measured by how many secrets it hides from view, but by whether unnecessary exposure and authority are reduced.
Sources and further reading
GitHub Docs: secure workflow use and secrets