Protocol
Block secrets before they become repository history
Deleting a secret after merge is slower than never committing it.
When it fits
- A coding agent may see local configuration, examples or logs containing credentials.
When to avoid it
- Secret scanning has coverage gaps and bypass paths; prevention still starts with credential handling and least privilege.
Why it matters
Keep real secrets out of prompts and repositories, and enable pre-push or equivalent secret detection where available. Exclude sensitive files from agent context when the tool supports it. If a detector fires, remove the credential from the change and investigate why it entered the agent's path.
Steps
- Secrets stored outside source.
- Sensitive context exclusions configured.
- Pre-push scanning enabled where available.
- Blocked secret investigated.
- Bypasses are exceptional and reviewed.
An example
A generated test accidentally includes a live API token; push protection blocks the commit and the team replaces it with a test fixture.
Check your result
Supported secrets are stopped before the protected repository receives them.
Keep this limit in mind
- Secret scanning has coverage gaps and bypass paths; prevention still starts with credential handling and least privilege.
Connected ideas
Use beforeRotate an exposed credential even after the text is removed
Evidence and sources
GitHub push protection can block supported secret patterns before they reach protected repositories, while GitHub notes that scanning coverage has limits.
Not all secrets or encodings are detected, and bypass mechanisms exist.
Push protection · What is push protection; supported behavior
OWASP's current secure-coding-with-AI guidance treats repository content, issues, PRs, comments, fetched pages, logs and tool responses as potential indirect prompt-injection inputs for coding agents.
Threat likelihood depends on who can influence the content and what permissions the agent has.
Secure Coding with AI Cheat Sheet · Indirect Prompt Injection in the Development Loop