TUE, SEPTEMBER 15, 2026
Independent · In‑Depth · Practitioner‑Tested
Claude Code Tools

Agents in CI Prompts: 6 Before You Let One Run Without You

GitHub put coding agents inside Actions this week. CI is a tempting place for an agent because the work is repeatable, and a dangerous one because it runs unattended with whatever your repository secrets hold. METR traced 1,200 agents through a package repository nobody was watching, which is roughly the shape of a CI environment. These six prompts are for deciding what to let one do.

⌨️ 6 prompts 🕐 Updated Sep 15, 2026
💡 How to use these prompts: Replace everything in [BRACKETS] with your specific details before sending. Click Copy to copy any prompt to your clipboard instantly.
1
Work out what the agent can reach
A CI agent inherits everything the workflow can see. That is usually more than a local one has.
I want to run an agent in CI doing: [DESCRIBE THE TASK]

My workflow has access to: [LIST SECRETS, TOKENS, NETWORK ACCESS]

Tell me:
- Which of those the task genuinely needs
- What each unnecessary one would let a misbehaving agent do
- The narrowest set that still works
- What breaks if I remove each

Assume I would rather the job fail than overreach.
2
Decide what it may never do
Instructions are not controls. Knowing which rules you cannot enforce is the useful part.
My CI agent will handle: [DESCRIBE]

Write the list of actions it must never take, regardless of what it concludes is correct.

Then tell me how each one would be enforced technically rather than by instruction, and which ones I cannot enforce that way.

The last group is the risk I am accepting.
3
Size the diff before it opens a PR
Capping diff size improves merge rate and cost at the same time. Rare to get both.
My agent will open pull requests for: [DESCRIBE]

Tell me what limits to set on diff size, files touched and scope per run — and why each limit helps.

Research on agent pull requests found larger diffs merge less often. Use that as the starting assumption.
4
Write the failure runbook first
Write this before the first run. Writing it after an incident is a different and worse document.
My CI agent runs unattended doing: [DESCRIBE]

Write what happens when it goes wrong:
- How I find out
- How I stop it mid-run
- What I check to see what it touched
- What I would need to roll back

If any step is I would not notice, say so.
5
Test the injection surface
An agent that reads issues reads whatever a stranger typed. That is the attack, and it is free to attempt.
My CI agent reads: [ISSUE TEXT, PR DESCRIPTIONS, COMMIT MESSAGES, EXTERNAL FILES - LIST WHAT APPLIES]

For each, tell me whether a third party can put text there, what they would try to make the agent do, and what in my setup would stop it.

Public repositories mean anyone can write an issue. Treat that as untrusted input.
6
Decide whether CI is the right place at all
Some tasks are worse automated. Asking first is cheaper than finding out from a deploy.
I am considering running this in CI: [DESCRIBE]

Argue against it. What makes it worse unattended, what a person would catch, what happens if it runs at 3am on a Sunday, and whether the time saved justifies the exposure.

Then tell me whether your argument holds.