Put a CI Permission Gate Before AI Agent Pull Requests

An AI agent pull request should not get privileged CI just because it looks like normal code review.

Short answer: Treat every AI agent pull request as untrusted until a human or deterministic policy approves the code, workflow changes, and deploy path. First-pass CI should run with a read-only token, no repository secrets, no deploy credentials, no privileged checkout of untrusted code, and no ability for automation to approve or merge its own pull request. Only after review should a separate privileged workflow get access to secrets, release keys, deployment environments, or write-capable repository tokens.

The risky part is not only that the agent might write bad code. The risky part is that the pull request can become executable input to your CI system.

A coding agent can read an issue, write a patch, open a pull request, and trigger automation. If that automation has secrets, write access, package publishing rights, deployment credentials, or a privileged GITHUB_TOKEN, the agent is now one step away from a supply-chain boundary.

That boundary needs a gate outside the model.

The old CI assumption breaks with agents

Traditional CI assumes a pull request is code waiting for tests and review.

Agentic CI has a different shape. A public issue, pull request body, review comment, README change, test fixture, workflow file, or repo script can steer the agent. Then the agent produces code that CI executes.

VibeSec Advisory already treats GitHub issues as agent input. The next boundary is what happens after the agent opens the pull request.

If the first CI run can see secrets or write back to the repository, a malicious or poisoned agent output does not need to bypass code review. It only needs CI to execute something before review happens.

OWASP CICD-SEC-4 calls this poisoned pipeline execution. OWASP says pipelines triggered from pull requests or arbitrary branches are more susceptible because the code has not gone through review or approval. OWASP also notes indirect cases where the protected pipeline calls repo-controlled files such as scripts, Makefiles, tests, linters, or scanner configuration.

That maps cleanly to agent PRs. The workflow file might be protected, but the workflow can still execute files the agent changed.

GitHub's guidance points to the same gate

GitHub's secure use reference recommends setting default GITHUB_TOKEN permissions to read-only for repository contents, then increasing permissions only for jobs that need more.

GitHub also warns about pull_request_target and workflow_run when they are combined with checkout of untrusted pull request content. Those workflows are privileged. They may have repository write access and access to referenced secrets. GitHub's guidance says to avoid those triggers with untrusted pull requests or code content, and that privileged workflows must not explicitly check out untrusted code.

That is the core design rule.

Do not let untrusted agent output enter the privileged runner context.

GitHub's GITHUB_TOKEN documentation adds one more detail that matters for agents: an action can access the token through github.token even if the workflow did not explicitly pass it. Permission settings are not cosmetic. They define what a compromised step or overpowered action can do.

The agentic case is already real enough to plan for

A Microsoft Security Blog case study reported that an AI workflow could expose CI/CD workflow secrets when agents processed untrusted GitHub content such as issue bodies, pull request descriptions, and comments. The reported issue involved a file-read path that could reach sensitive runner environment files.

The transferable lesson is not that every tool has that exact bug. The lesson is simpler: untrusted repository content, file-read tools, runner secrets, and external communication do not belong in the same default path.

If you combine them, prompt injection becomes a CI/CD security problem.

Use a five-part CI permission gate

I would put this gate in front of every agent-created or agent-modified pull request.

1. Classify the pull request before CI starts

Record how the pull request was created.

Use labels or workflow conditions to distinguish:

• Human-authored pull requests from trusted maintainers.
• Agent-authored pull requests from trusted users.
• Agent-authored pull requests influenced by public issues, public comments, external docs, or forked code.
• Pull requests that modify workflow files, scripts, tests, package scripts, build configuration, or deployment code.

The label should change CI behavior. It should not just decorate the pull request.

2. Run first-pass CI with a read-only token

Default the first run to the smallest useful authority.

For GitHub Actions, that usually means explicit job-level permissions and a read-only repository token unless the job has a narrow reason to write. Do not rely on implied defaults.

The first-pass job can build, typecheck, lint, and run tests. It should not publish packages, update branches, approve pull requests, write releases, comment with privileged tokens, or trigger deployments.

If the job needs to comment back, route that through a separate narrowly scoped job after the untrusted code path has finished.

3. Keep secrets out of unreviewed runs

Unreviewed agent pull requests should not receive production API keys, cloud credentials, signing keys, package registry tokens, database credentials, or customer data access.

GitHub's secure use reference says required reviewers can protect environment secrets so a job cannot access them until approval is granted. Use that pattern for deployment credentials and high-impact secrets.

This pairs with the VibeSec Advisory credential boundary for AI coding agents: do not make the agent, its trace, or its CI run carry secrets it does not need.

4. Protect workflow files and referenced scripts

Protecting .github/workflows is necessary, but not enough.

OWASP's indirect poisoned pipeline example matters here. A protected workflow can still call repo files. If the agent can change scripts/build.sh, Makefile, package scripts, test setup files, linter config, scanner config, or deploy helpers, it can change what CI executes.

Put CODEOWNERS or required review on workflow files and the scripts they call. Treat changes to CI-adjacent files as permission changes, not routine code changes.

A good review question is: "Would this file run on a machine that has secrets, deployment reach, write tokens, or package publishing authority?"

If yes, it belongs in the CI permission gate.

5. Split validation from privileged release work

Use two lanes.

The first lane validates untrusted code with no secrets and no write authority.

The second lane runs only after review. It can use environment approvals, protected branches, release rules, signed provenance, or a manually approved workflow dispatch. That second lane is where deploy credentials, package registry tokens, cloud roles, or write-capable tokens appear.

This is boring by design. The agent can be fast in the first lane. The second lane stays deliberate.

Test the gate before trusting it

Do not validate this with a happy-path pull request.

Use a harmless test repository or a sandbox branch. Then seed the cases that break weak gates:

• An agent pull request that changes a workflow file.
• An agent pull request that changes a script called by a protected workflow.
• A package script change that would run during install, test, or build.
• A test fixture that tries to read environment variables.
• A pull request from a fork.
• A workflow using pull_request_target with checkout of pull request code.
• A first-pass job that attempts to create, approve, or merge a pull request.
• A deploy job that should require environment approval before secrets appear.

Use harmless canary values, not real credentials. The expected result is clear: first-pass CI should not see secrets, should not write to the repository, should not deploy, and should not approve its own path forward.

If the test can reach a token, a secret, a deploy role, or a write path before review, the gate is not real yet.

Evidence versus opinion

Evidence from the sources:

• OWASP describes poisoned pipeline execution as malicious code or commands entering the build process through CI configuration or files the pipeline executes.
• OWASP says pull request and arbitrary branch pipelines are more susceptible when code has not been reviewed or approved.
• GitHub recommends default read-only GITHUB_TOKEN permissions and job-level permission increases only when needed.
• GitHub warns against privileged workflow triggers with untrusted code checkout.
• GitHub says environment secret access can be protected by required reviewers.
• Microsoft reported an agentic CI/CD case where untrusted GitHub content, file-read tooling, and runner secrets crossed a dangerous boundary.

My opinion:

Agent pull requests should have a stricter CI default than human pull requests, not a looser one. The safest starting point is read-only, secret-free validation. Privileged CI should be a second step after the code, workflow impact, and release path are reviewed.

That is not anti-agent. It is how you make agent output safe enough to use.

Sources

• GitHub Secure Use Reference: https://docs.github.com/en/actions/reference/security/secure-use
• GitHub GITHUB_TOKEN authentication guide: https://docs.github.com/en/actions/tutorials/authenticate-with-github_token
• OWASP CICD-SEC-4, Poisoned Pipeline Execution: https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-04-Poisoned-Pipeline-Execution
• Microsoft Security Blog, Securing CI/CD in an agentic world: https://www.microsoft.com/en-us/security/blog/2026/06/05/securing-ci-cd-in-agentic-world-claude-code-github-action-case/

Next free step: Test your agent. Run one sandbox pull request through the gate and prove the first CI lane cannot access secrets, write to the repository, approve itself, or deploy.