A security tool installed in a repository is useful only if the development process actually uses its result. For teams accepting AI-generated changes, start with a small exercise: prove that an unsafe change cannot pass the controls you rely on.
DevPro Journal’s November 3 playbook highlights agent permissions, dependency checks and risk-based review. The workflow below turns those themes into a practical verification task. It also follows the broader principle in NIST’s Secure Software Development Framework: integrate security practices into the development lifecycle.
1. Check what the agent can do before it writes
Choose a test repository and a harmless change. Record the agent identity, repository permissions and available credentials. Confirm that it can perform its assigned task without receiving production secrets or permission to alter the rules governing its own changes.
For GitHub Actions, GitHub recommends minimum token permissions, with repository-content access read-only by default and additional permissions granted per job. Its guidance also warns against checking out untrusted pull-request code in privileged workflows. Review the workflow context, not just the permissions shown on one token.
2. Make the checks visible and enforceable
Open a pull request that adds a dependency in the test repository. Review the exact package name, source and lockfile changes. GitHub’s dependency review exposes direct and indirect dependency changes and known-vulnerability information. Its action can block merging when configured as a required check. Availability depends on repository type and enabled security products.
Enable an appropriate code-security scan and check its coverage for the project’s language. For credential exposure, GitHub secret scanning can detect supported credential types; a detected live credential should be rotated. Use approved scanner test fixtures for your exercise, never real credentials. Confirm that the fixture fails the intended check and prevents the agent identity from merging the test pull request.
Then inspect the merge rules. Branch protection can require checks and code-owner approval, but administrators and bypass roles are exempt by default unless the relevant restriction is enabled. Confirm which actors can bypass your intended gate.
3. Give the reviewer a question, not just a diff
For an authorization change, ask: can another user access this record? For a dependency addition, ask why the package is necessary. Protect changes to workflow and agent-instruction files with named ownership, since those files influence later work.
Record the test commit, checks that ran, reviewer decision and any bypass discovered. Fix gaps and repeat the exercise after changing the pipeline. Passing this exercise demonstrates that particular controls worked for the tested case; it does not certify that generated code is secure.
