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 secret scanning with push protection turned on is specifically designed for this scenario. When push protection is enabled, GitHub scans each push for known secret patterns, such as API keys, connection strings, and tokens from many providers, before accepting it. If a secret is detected, the push is rejected with an explanation, and the developer or agent 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 repository history. Standard secret scanning without push protection alerts after the commit is already in history, which is why the key was exposed for four hours in this scenario. For the agent workflow, the correct integration is to call the git push tool after the git commit tool and treat a push rejection as a blocking error, halting the workflow and alerting a human rather than silently retrying or bypassing. The system-prompt instruction not to include secrets is the lowest-efficacy control because the agent generated the secret because it appeared in context, not because it disobeyed instructions; prompt-level guardrails don't catch incidental secret inclusion. Requiring two human reviewers to approve every commit before it reaches the remote repository would work, but it is operationally impractical for an autonomous agent and defeats the efficiency goal. Rotating all secrets on a one-hour schedule mitigates the damage window but does not prevent exposure; improving a four-hour exposure window to one hour is better, but the goal is zero exposure.