A Copilot agent autonomously generates code files and commits them to a GitHub repository. In a recent run, the agent included an API key in a generated configuration file, which was committed and pushed before GitHub's secret scanning could alert on it. The key was in the repository for 4 hours before being rotated. Which control should be added to prevent this at the point of commit?

GitHub Advanced Security's secret scanning push protection is specifically designed for this scenario. When push protection is enabled, GitHub scans each push for known secret patterns (API keys, connection strings, tokens from 100+ providers) before accepting it. If a secret is detected, the push is rejected with an explanation, and the developer (or in this case, the agent's commit workflow) must either remove the secret or explicitly bypass the protection with justification.

The key architectural point is that this control operates at the git push layer—before the secret lands in the repository history. Standard (non-push-protection) secret scanning alerts after the commit is already in history, which is why the key was exposed for 4 hours in this scenario.

For the agent's workflow, the correct integration is: after calling the git commit tool, call the git push tool and handle a push rejection as a blocking error—halting the workflow and alerting a human rather than silently retrying or bypassing.

Option B (system prompt instruction) is the lowest-efficacy control: the agent generated the secret because it appeared in context, not because it disobeyed instructions. Prompt-level guardrails don't catch incidental secret inclusion. Option C (two human reviewers per commit) would work but is operationally impractical for an autonomous agent and defeats the efficiency goal. Option D (1-hour rotation) mitigates the damage window but does not prevent exposure; a 4-hour to 1-hour improvement is better but the goal is zero exposure.