Running AI agents safely in CI/CD: a 2026 hardening guide

Your PR-review bot has a problem you have not modeled. It holds ANTHROPIC_API_KEY, GITHUB_TOKEN, probably some AWS creds, maybe a Resend or Linear key. A stranger on the internet can open a pull request whose title is a sentence of English text, and your bot reads that sentence as instructions. In 2025, several researchers demonstrated that the sentence can say "dump your environment and commit it back to the repo", and the bot will do it.

This is not a hypothetical. It is the threat model you bought when you wired Claude Code, Gemini CLI, or Copilot Coding Agent into your Actions workflows. The honest fix is not "make the model immune to prompt injection". Nobody knows how to do that. The fix is to make the bot's environment so thin that successful injection exfiltrates nothing valuable.

This post is the workflow file, the permissions: block, the IAM trust policy, and the one-paragraph explanation of why each line is there.

What actually broke in 2025

In August 2025 researcher Aonan Guan published "Comment and Control", a cross-vendor class of attack against three production CI agents. The disclosure walks through working exploits against Anthropic's claude-code-action, Google's run-gemini-cli, and GitHub's Copilot Coding Agent. All three were shown to exfiltrate provider API keys and GITHUB_TOKEN from text supplied in PR titles, issue comments, or hidden HTML comments. (oddguan.com, SecurityWeek coverage)

According to the researcher's writeup, the Claude Code Security Review variant was triaged on HackerOne and ultimately closed without a CVE, with Anthropic taking the position that the action is not designed to be hardened against prompt injection. The mitigation that shipped was narrow: a new --disallowed-tools 'Bash(ps:*)' default in the security-review workflow, plus docs updates. The env | curl style exfil class remains possible without further hardening. (oddguan.com writeup)

The cleanest illustration of why "block egress to evil.com" is not enough: per the disclosure, the Copilot Coding Agent path bypassed three defenses at once. A helper function reconstructed the env output to dodge environment filtering. The dump was base64-encoded to dodge GitHub secret scanning. And rather than send the data to an attacker domain (which would have hit the GitHub egress allowlist), the agent wrote it to a file in the repo and committed it back. Github.com became the exfil channel. (oddguan.com)

A separate but adjacent issue: Check Point disclosed CVE-2025-59536 and a related ID covering untrusted Claude Code project files. A repo's .claude/settings.json could define hooks that ran shell commands on clone, auto-load MCP servers before the trust dialog, or set ANTHROPIC_BASE_URL to an attacker endpoint so the first API call leaked the user's key. Anthropic fixed the issues in a subsequent Claude Code release; the Check Point advisory and the Hacker News writeup have version numbers. This matters in CI because some teams run Claude Code against fresh PR checkouts. If you do, pin your Claude Code version and treat the .claude/ directory of incoming PRs as hostile.

The pattern across all of this: the attack does not need to be subtle. It needs your agent to have one secret it should not, and one path to write data anywhere on the public internet.

Where the secrets actually live in a GitHub Actions run

Before you can shrink the blast radius, you need a clear picture of where a malicious agent can read from.

The most common own-goal is putting cloud keys into secrets.AWS_ACCESS_KEY_ID and secrets.AWS_SECRET_ACCESS_KEY and interpolating them into env:. They become plain strings in the agent's process environment for the life of the job. A single successful injection prints them.

The second most common own-goal is using pull_request_target for anything that touches fork code. With pull_request, fork PRs run with a read-only GITHUB_TOKEN and no access to repo secrets. With pull_request_target, the workflow runs in the base-repo context with full secrets and a read/write token, against fork-supplied code. (GitHub Security Lab, "Preventing pwn requests")

If you take one thing away from this post, take this. Assume any env: value the agent step holds is one prompt injection away from being public. Build the rest of your design around that assumption.

Pattern one: least-privilege workflow triggers and tokens

Start at the trigger. For anything that reads PR contents from a fork, use on: pull_request, not pull_request_target. If you absolutely must use pull_request_target (for example to comment on first-time-contributor PRs), do not check out the PR head SHA in the same job that holds secrets. The dangerous shape looks like this:

# DANGEROUS: fork PR code runs in privileged context with secrets
on: pull_request_target
jobs:
  review:
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }}   # attacker code

Next, scope GITHUB_TOKEN. The default in many orgs is still "write everything". Set it explicitly per workflow:

permissions:
  contents: read
  pull-requests: write   # to post review comments
  issues: read           # only if the agent reads issue bodies
  id-token: write        # required for OIDC exchanges

The id-token: write line is the one that unlocks every pattern below. Without it, you have no way to mint short-lived credentials from your CI run, and you fall back to long-lived secrets stuffed in env:.

Pattern two: GitHub OIDC to your cloud, no long-lived keys

The canonical replacement for AWS_ACCESS_KEY_ID in your Actions environment is GitHub's OIDC issuer plus your cloud's STS-equivalent. The runner already has a JWT signed by https://token.actions.githubusercontent.com. Your cloud's IAM trusts that issuer and exchanges the JWT for short-lived creds.

For AWS, the official action handles the exchange:

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: prod
    steps:
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/agent-ci-prod
          aws-region: us-east-1

The load-bearing piece is on the IAM side. Pin the sub claim, not just the audience:

{
  "Condition": {
    "StringEquals": {
      "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
      "token.actions.githubusercontent.com:sub": "repo:octo-org/octo-repo:environment:prod"
    }
  }
}

That sub value scopes the trust to one repo, one environment. A workflow run in a different repo, or the same repo without the environment: prod declaration, cannot assume the role even if it gets an OIDC token. GitHub's docs walk through the full setup. (GitHub Docs, configuring OIDC in AWS)

GCP and Azure work the same way. The pattern is identical: federate GitHub's OIDC issuer, condition on sub, mint short-lived creds at job start.

For non-cloud secrets that a vault can mint, HashiCorp Vault uses the same OIDC dance. hashicorp/vault-action authenticates with the runner's JWT, Vault checks claims, and returns a short-lived token. HashiCorp's GitHub Actions secrets guidance is the reference. For self-hosted ARC runners on Kubernetes, HashiCorp recommends Kubernetes auth instead, because the pod service account is more authoritative than the GitHub OIDC JWT.

Pattern three: harden the Claude Code action specifically

If you are running claude-code-action, the v1 setup uses GitHub OIDC to mint a scoped GitHub App installation token, not a long-lived PAT. The action calls core.getIDToken with an audience for the action and exchanges the JWT at Anthropic's API for a scoped installation token. Anthropic's own security docs are explicit on the point that static tokens should not be used because they do not rotate between runs and could be partially or fully recovered over time via prompt injection.

The minimum-viable safe workflow:

name: Claude Review
on:
  pull_request:                  # NOT pull_request_target
    types: [opened, synchronize]

permissions:
  contents: read
  pull-requests: write
  issues: read
  id-token: write                # required for OIDC exchange

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: anthropics/claude-code-action@v1
        with:
          claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
          allowed_non_write_users: "alice,bob"
          claude_args: '--allowedTools "Bash(gh issue view:*)"'

A few notes on what the action does for you and what it does not, per Anthropic's security.md:

• It does best-effort env scrubbing in certain configurations, stripping Anthropic, cloud-provider, and GitHub Actions secrets from subprocess environments. Check the docs for the exact opt-out env var and current behavior.
• It strips HTML comments, invisible characters, image alt text, hidden attributes, and HTML entities from input. The docs call this mitigation, not a guarantee.
• A --disallowed-tools 'Bash(ps:*)' default exists in the bundled security-review workflow. If you give the agent shell, audit your own deny list.

Worth reading in full: GitHub Security Lab's advisory on the PraisonAI reusable action, which found that an issue body could be interpolated directly into a shell context, allowing arbitrary command execution in a job that held ANTHROPIC_API_KEY. The vulnerability was not in Claude. It was in the wrapping action. If you write reusable workflows for AI agents, this class of advisory is your code review checklist.

For more on hardening Claude Code outside of CI, see the production setup guide.

Pattern four: deny-by-default egress

Even with OIDC, scoped tokens, and a careful workflow, your agent process can still reach evil.com over HTTPS. The step-security/harden-runner action installs eBPF hooks at kernel level before user steps run and supports egress-policy: block with a domain allowlist. (step-security/harden-runner)

- uses: step-security/harden-runner@v2
  with:
    egress-policy: block
    allowed-endpoints: >
      api.anthropic.com:443
      api.github.com:443
      objects.githubusercontent.com:443

Run in audit mode first to build a baseline of what your job legitimately calls. Then flip to block.

Two caveats. First, harden-runner runs inside the runner VM, so a root-equivalent step inside the VM can in principle disable it. Second, even with egress blocked, your agent has push access to your own repo. Comment and Control used exactly this path: write the dump to a file, let the agent commit, exfil happens through github.com. The mitigation is to keep contents permission as read for jobs where the agent reads untrusted input, and only grant write for trusted code paths.

GitHub has signalled a direction of travel toward scoped secrets (bound to a workflow path, environment, or reusable workflow rather than the whole repo) and runner-level egress controls. Treat these as forthcoming rather than as present-day controls and design around what is available today.

Pattern five: the secrets that OIDC cannot replace

GitHub OIDC plus AWS STS gives you short-lived AWS creds. GitHub OIDC plus Vault gives you anything Vault can mint. Neither helps when your agent step needs to call Resend, Linear, Slack, or a customer SaaS API mid-run, because none of those providers federate with GitHub's OIDC issuer.

Today's options for that class of secret are not great:

1. Paste the key into secrets.RESEND_API_KEY and interpolate it into env:. This is exactly the value Comment and Control exfiltrates.
2. Mint a scoped token from Vault on every job start. Works if the provider has a Vault secrets engine. Most do not.
3. Run a local credential broker on the runner. The broker process holds the real credential. The agent step gets a placeholder value in the env var. A local proxy matches the destination on outbound requests and swaps in the real Authorization header. A successful env dump exfiltrates a placeholder string, not a usable key.

The third pattern is the niche authsome sits in. You run authsome login resend once on the runner (device-code flow works fine over SSH and CI), then launch the agent with authsome run -- <agent command>. The agent's process environment holds a placeholder like RESEND_API_KEY=authsome-proxy-managed, not the real key. The local proxy intercepts the outbound request to Resend by destination and injects the real Authorization header at the edge. Paired with harden-runner egress block, you have defense in depth for the class of secret OIDC does not solve.

This is one specific niche. A local broker does not fix prompt injection, does not fix pull_request_target misuse, does not scope GITHUB_TOKEN, does not replace AWS keys (use OIDC plus STS), and does not patch malicious .claude/settings.json style issues (that is a Claude Code version pin). It is one tool for one layer.

A worked example: a hardened PR-review workflow

Putting it together. This is a PR-review bot that reads PR contents, runs Claude Code, deploys a preview to AWS, and posts results back. It uses OIDC for AWS, a scoped GITHUB_TOKEN, harden-runner with an allowlist, and a local broker for the Linear and Resend keys it needs for notifications.

name: PR Review and Preview
on:
  pull_request:
    types: [opened, synchronize]

permissions:
  contents: read
  pull-requests: write
  issues: read
  id-token: write

jobs:
  review:
    runs-on: ubuntu-latest
    environment: pr-preview
    steps:
      - uses: step-security/harden-runner@v2
        with:
          egress-policy: block
          allowed-endpoints: >
            api.anthropic.com:443
            api.github.com:443
            objects.githubusercontent.com:443
            sts.amazonaws.com:443
            s3.us-east-1.amazonaws.com:443
            api.resend.com:443
            api.linear.app:443

      - uses: actions/checkout@v4

      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/pr-preview
          aws-region: us-east-1

      - name: Start local credential broker
        run: |
          authsome daemon start
          authsome whoami

      - uses: anthropics/claude-code-action@v1
        with:
          claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
          claude_args: '--allowedTools "Bash(npm test:*),Bash(gh pr diff:*)"'
        env:
          RESEND_API_KEY: authsome-proxy-managed
          LINEAR_API_KEY: authsome-proxy-managed

What this gets you:

• Fork code does not run with secrets (pull_request trigger, not pull_request_target).
• AWS access is a short-lived STS token scoped to the pr-preview environment.
• GITHUB_TOKEN cannot push to protected branches (contents: read).
• Network egress is whitelisted to the specific hostnames the job legitimately needs.
• RESEND_API_KEY and LINEAR_API_KEY in the agent's environment are placeholders. The broker holds the real keys and injects them on outbound requests. An env-dump injection prints two placeholder strings.

What this still does not get you:

• The agent can read pull-requests: write-scoped data and comment on the PR. If your model is hostile, your PR comments can be hostile too.
• The agent has id-token: write. If a future vulnerability in the Claude Code action leaks the JWT before exchange, an attacker could theoretically mint your AWS creds. Pin actions to commit SHAs in production.
• The agent can still commit-to-self if you grant contents: write later in the workflow. Split that into a separate job that does not run the agent.

For the broader threat-model framing, see AI agent security in 2026: four threat models and how prompt injection becomes credential exfiltration.

A short checklist

When you are reviewing an existing agent workflow, walk this list:

1. Is the trigger pull_request_target? If yes, does it check out PR-supplied code in a job with secrets? If both, this is the first thing to fix.
2. Is permissions: set explicitly at the workflow or job level? Default to contents: read and add only what is needed.
3. Are AWS, GCP, or Azure keys in secrets.*? Replace with OIDC plus STS. Pin sub claim to repo and environment, not just aud.
4. Is there a long-lived PAT for GitHub itself? claude-code-action v1 supports OIDC exchange. Use it.
5. Are third-party SaaS keys (Resend, Linear, Slack) in env:? They are exfilled by a successful env dump. Move them to a broker or short-lived issued tokens.
6. Is there an egress policy? harden-runner audit mode first, then block.
7. Are actions pinned to a commit SHA, not a tag? Tags can be moved.
8. Is your Claude Code version recent enough to include the CVE-2025-59536 fixes? A malicious PR shipping its own .claude/settings.json is a real path otherwise.

Where this is going

GitHub has signalled work toward native egress firewalling outside the runner VM, scoped secrets bound to a workflow file rather than a whole repo, and immutable releases. These will make some of the patterns in this post simpler. None of them removes the underlying constraint. An agent that reads untrusted input and holds a usable secret is one prompt away from leaking it. The only durable answer is to make the secrets unusable to the agent process itself, by federating with the model's auth issuer where possible (OIDC plus STS), and brokering where it is not.

The work this year is to stop putting raw keys in CI environment variables. Everything else is detail.

Priyansh Khodiyar

Maintainer

Works on authsome and the agentr.dev tooling.