CI surface blast radius
What you'll learn
Claude Code in CI runs with the same permissions as a developer with the same token. CI's higher autonomy means damage potential is higher, not lower.
- CI = same permissions as a dev with the equivalent token. No new boundary.
- Repo secrets, registry tokens, cloud creds — all in scope for the agent.
- Hooks that protect local surface should also be present (or stronger) in CI.
Running Claude Code as a GitHub Actions step (or in any CI surface) does not create a new permission boundary — the agent runs with the *same* permissions as a developer with the same access list. Repository secrets are accessible. The deployable artefacts are reachable. The package registry tokens, cloud credentials, and database URLs that live in CI are all in scope. The blast radius of a misbehaving agent in CI is the same as the blast radius of a developer with the equivalent token.
The implication: the same hooks that protect the local developer surface (PreToolUse refusing rm -rf, PreToolUse refusing --no-verify) need to be in place — or stronger — in the CI surface. The CI surface often *also* needs additional guards: 'don't push to protected branches', 'don't tag releases', 'don't publish packages without approval', 'don't run migration scripts'. Each of these is a candidate for a PreToolUse hook with a deny-decision.
The mistake to avoid: assuming CI is 'safer' because it's automated and unattended. The opposite is true — without a developer to glance at the screen and stop a bad action, the ceiling for damage is higher, not lower. The agent's permission set times the agent's autonomy = blast radius. CI usually has higher autonomy; the permission set must compensate.
Two operational notes. Repo-level secrets are exposed via env vars to the running step; an agent with shell access can read them. Reasoning about blast radius in CI means reasoning about every secret in the environment. The mitigation isn't 'hide secrets from Claude' (impossible if the workflow itself uses them); it's 'reduce the secret set the workflow exposes' and 'gate side-effecting operations behind explicit approvals'.
Key points
- CI = same permissions as a dev with the equivalent token. No new boundary.
- Repo secrets, registry tokens, cloud creds — all in scope for the agent.
- Hooks that protect local surface should also be present (or stronger) in CI.
- CI's higher autonomy raises the ceiling on damage, not lowers it.
- Mitigation: scope secrets tightly + gate side-effecting operations.
Examples
Team relies on developer review to stop bad agent actions locally. They run the same agent in CI without additional guards. A misbehaving prompt asks the agent to 'clean up old branches' and the CI step has push permissions to all branches. Damage is real and unattended.
CI step runs with a token scoped to read-only on protected branches, read-write on docs/. PreToolUse hooks deny `git push.*main`, `npm publish`, and any shell containing `--no-verify`. Side-effecting operations require an explicit approval step in the workflow.
Pitfalls
- Treating CI as a sandbox just because it's not the dev's machine. It's not.
- Forgetting that env-var secrets are accessible to a shell-capable agent.
- Reusing high-privilege tokens in CI 'because it's easier.' The principle is least-privilege, especially when the operator is automated.
Source notes: 00-academy-basics/notes/06-claude-code-in-action.md
Ask Claude
Build a prompt with this lesson + your question, copy it, and open the Claude Project in a new tab.