Coding agents make GitHub controls more important, not less. When automation can create branches, change dependencies and trigger workflows, a pull request becomes a security and quality boundary.

These seven controls turn an informal agent workflow into a reviewable delivery system.

1. Rulesets and protected branches

Prevent agents and developers from pushing directly to the default branch. Require a pull request, successful checks and the approvals appropriate to the change.

A practical baseline is:

• no direct push to main;
• required test, lint and security checks;
• conversation resolution before merge;
• no force pushes;
• restricted bypass permissions;
• an additional approval for production or infrastructure paths.

Agents should create proposed changes, not silently redefine repository policy.

2. CODEOWNERS for high-risk paths

Use CODEOWNERS to route sensitive changes to people who understand their impact:

AGENTS.md                   @platform-team
.github/workflows/          @platform-team @security-team
/src/auth/                  @security-team
/src/providers/             @ai-platform-team
/infra/                     @platform-team
/migrations/                @backend-team

CODEOWNERS is most useful when a ruleset actually requires code-owner review. Without enforcement it is only a notification mechanism.

3. Least-privilege Actions permissions

Workflow tokens should start read-only and receive write access only for the job that needs it:

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test

Avoid giving every workflow contents: write, package publishing or deployment rights. Review third-party actions as dependencies and pin sensitive automation to a trusted revision.

See CI/CD pipelines for AI applications for evaluation and deployment patterns.

4. Environments with human deployment approval

GitHub environments separate passing CI from permission to deploy. Use a production environment for protected secrets, reviewers and deployment history.

An agent-authored pull request can build and test automatically, while production remains gated:

jobs:
  deploy:
    environment: production
    permissions:
      contents: read
      id-token: write

Prefer OpenID Connect and short-lived cloud credentials over a permanent cloud key stored as a repository secret.

5. Dedicated identities for agents

Do not let an autonomous agent operate through a maintainer’s personal token or SSH key. Use a dedicated GitHub App, bot account or workload identity with repository-specific permissions.

This lets you distinguish human and agent actions, revoke one integration without locking out a developer and limit which repositories the agent can change.

For SSH automation, use Git permission denied for agents and CI.

6. Repository instructions and pull-request templates

Give agents explicit repository context: build commands, test expectations, architectural constraints and prohibited actions. Keep instructions versioned with the code so changes receive review.

A pull-request template should require:

• what changed and why;
• tests performed;
• security, data or migration impact;
• generated files or dependencies changed;
• rollback plan;
• facts still requiring human verification.

Instructions guide behavior; protected branches and CI enforce it. Do not confuse the two.

7. Audit the whole path

For a consequential change, reconstruct:

task → agent session → branch → commits → pull request
     → checks → human approval → deployment

Retain identifiers connecting those stages. A green check alone does not prove which prompt, tool permission or external service produced the change.

Review installed GitHub Apps, Actions permissions, deploy keys, environment secrets and bypass lists periodically. Remove identities that no longer have an owner.

A minimal coding-agent policy

1. Agents work on branches, never directly on main.
2. Default tokens and workflow permissions are read-only.
3. CI runs deterministic tests before model-based review.
4. High-risk paths require human code-owner approval.
5. Production credentials are isolated behind an environment.
6. Agent identities are separate, scoped and revocable.
7. Every deployment is traceable to an approved commit.

Use the Git foundation for AI workflows for branch and rollback mechanics. Compare platform trade-offs in GitHub vs GitLab for AI development teams and connect repository policy to AI Security & Credentials.

Primary documentation

• GitHub protected branches
• GitHub CODEOWNERS
• GitHub Actions token permissions
• GitHub deployment environments