RFC: ADR-009 — Security posture and blast radius for development-time agents

[scottschreckengaust]

Summary

Define the security boundaries, identity separation, and blast radius controls for agents that contribute code to this repository — distinct from the runtime agent that executes inside MicroVMs. Planners and implementors must be separated by context roles and identity, with no self-approval capability.

Use case and motivation

Problem today:

1. Development-time agents (writing code, creating PRs) operate with the same credentials as the human who invoked them — no separation of privilege.
2. An agent could theoretically modify CI workflows, security policies, or approval gates — then approve its own changes.
3. No protocol distinguishes "planning" (what to do) from "implementation" (doing it) from "review" (verifying it's correct) — one agent could do all three.
4. Blast radius is undefined: what can an agent touch? What requires human-in-the-loop?

After this ADR:

• Role separation: planners, implementors, and reviewers are distinct contexts (ideally distinct identities)
• No self-approval: the identity that writes code cannot approve or merge it
• Blast radius classification: every action has a defined risk level
• Bypass requires 2-person (2P) review — no single identity can override

Proposed role separation

Identity model

Role	Capability	Cannot do
Planner	Create/edit issues, write RFCs/ADRs, define roadmap items	Write code, push branches, approve PRs
Implementor	Write code, create PRs, push branches, run tests	Approve own PRs, merge own PRs, modify CI/security config
Reviewer	Approve PRs, request changes, merge	Write code on the same PR they're reviewing
Admin	All of the above + modify policies, approve issues, override gates	Should still require 2P for policy changes

Blast radius classification

Action	Risk	Gate
Edit code in existing patterns	Low	CI + peer review
Add new dependency	Medium	Security scan + review
Modify IAM policy / security config	High	2P review + admin approval
Modify CI/CD workflow	High	2P review + admin approval
Modify branch protection / approval rules	Critical	Admin-only + audit trail
Modify the governance ADRs themselves	Critical	Admin-only + 2P review
Delete or force-push to protected branches	Critical	Never automated; human-only

2P (two-person) review

For High and Critical actions:

• The author cannot be one of the two approvers
• At least one approver must be a human (not an agent reviewing its own planner's work)
• Approvals must reference the specific risk being accepted

No self-approval (structural enforcement)

• GitHub branch protection: require review from someone other than the pusher
• Agents MUST use an identity distinct from the human who directed them (or the review must come from a different human)
• If an agent plans AND implements, the review must come from an identity that did neither

Credential scoping

Agent context	Minimum credentials needed
Planning (issues, RFCs)	GitHub Issues write, read-only repo
Implementation (code, PRs)	Repo write, PR create, no merge capability
Review	PR review write, no push capability
Deployment	Separate deploy key, gated by environment approval

Open questions

1. How do we enforce role separation when using personal PATs (which have all permissions)?
2. Should planning and implementation be separate GitHub Apps with different permission sets?
3. How do we handle the case where a human is both directing an agent AND reviewing its output?
4. What's the minimum 2P bar — two humans? One human + one agent? Two agents with different principals?
5. How does this interact with the Cedar HITL gates already in the runtime agent?

Alignment

Aligns with Security (execution guardrails) and is a prerequisite for safe Agent swarm operation.

Dependencies

• ADR-003 (RFC: ADR-003 — Contribution governance for async agents and humans #134) — governance (defines approval gates this ADR enforces technically)
• Existing docs/design/SECURITY.md — runtime agent security (this ADR covers development-time)
• Cedar HITL gates (PR feat: Cedar HITL approval gates for agent tool use #88) — runtime tool-call governance (complementary, not overlapping)

---

• RFC PR: (pending approval)
• Approved by: (pending)
• Reviewed by: (pending)