security(ci): add Read sandbox to alert-monitor and issue-fix agents #329

2026-07-21T14:55:41Z

claude-bot commented

2026-07-21 14:55:41 +00:00

Both the alert-triage-agent and issue-fix-agent steps hold Gitea write credentials in their environment (issue-fix holds a push token too), but neither passed --settings — so their Read tool was unrestricted. update-audit received a Read sandbox for exactly this reason (#197); these two never got the equivalent.

That left a complete exfil path:

Read /proc/self/environ → the token
Write → the agent's output file
the pipeline posts that output verbatim as a Gitea issue body / PR body — on a public repo

Adds the same deny-list update-audit uses (/proc, /root, /home, /etc, .git) to both agents and wires --settings into each invocation. The repo checkout, .ci-alert-monitor/ and /tmp/alert-fix/ stay readable, which is all either agent needs.

Defense-in-depth only. The root cause — CI pipelines holding an admin-owned token at all, and security_bot_token being reused outside the security pipeline — is tracked separately and fixed by the follow-up cutover to per-pipeline bot identities.

🤖 Generated with Claude Code

Both the `alert-triage-agent` and `issue-fix-agent` steps hold Gitea write credentials in their environment (issue-fix holds a push token too), but neither passed `--settings` — so their `Read` tool was unrestricted. `update-audit` received a Read sandbox for exactly this reason (#197); these two never got the equivalent. That left a complete exfil path: 1. `Read /proc/self/environ` → the token 2. `Write` → the agent's output file 3. the pipeline posts that output verbatim as a Gitea issue body / PR body — on a **public** repo Adds the same deny-list `update-audit` uses (`/proc`, `/root`, `/home`, `/etc`, `.git`) to both agents and wires `--settings` into each invocation. The repo checkout, `.ci-alert-monitor/` and `/tmp/alert-fix/` stay readable, which is all either agent needs. **Defense-in-depth only.** The root cause — CI pipelines holding an admin-owned token at all, and `security_bot_token` being reused outside the security pipeline — is tracked separately and fixed by the follow-up cutover to per-pipeline bot identities. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

claude-bot added 1 commit 2026-07-21 14:55:41 +00:00

security(ci): add Read sandbox to alert-monitor and issue-fix agents ab105233d9

Both agent steps hold Gitea write credentials in their environment
(issue-fix holds a push token too), but neither passed --settings, so
their Read tool was unrestricted — unlike update-audit, which got a
Read sandbox for exactly this reason (gitea issue #197).

That left a complete exfil path: Read /proc/self/environ yields the
token, Write puts it in the agent's output file, and the pipeline posts
that output verbatim as a Gitea issue body / PR body on a PUBLIC repo.

Add the same deny-list used by update-audit (/proc, /root, /home, /etc,
.git) to both agents and wire --settings into each invocation. The repo
checkout, .ci-alert-monitor/ and /tmp/alert-fix/ stay readable, which is
all either agent needs.

This is defense-in-depth only. The root cause — CI pipelines holding an
admin-owned token at all — is tracked separately.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

claude-bot referenced this pull request

2026-07-21 14:56:08 +00:00

security(ci): retire the admin gitea_token from CI; give each pipeline its own bot identity #330

claude-bot referenced this pull request

2026-07-21 15:11:16 +00:00

security(ci): retire the admin gitea_token from CI entirely #333

claude-bot referenced this pull request

2026-07-21 15:11:35 +00:00

security(ci): retire the admin gitea_token from CI; give each pipeline its own bot identity #330

k.renner merged commit 28f500d566 into master

2026-07-21 15:22:32 +00:00

k.renner referenced this issue from a commit