A developer is designing the guardrail policy for a deployment agent that can perform four actions: (1) read repository files, (2) create feature branches, (3) force-push to the main branch, and (4) deploy to the production environment. How should these four actions be classified by risk level for the purpose of autonomy assignment?

Risk classification for agent actions is based on two primary dimensions: reversibility (how easily can the action be undone?) and blast radius (how many people/systems are affected if something goes wrong?).

Read repository files: Read-only operations carry minimal risk. No state is changed; no data is written. The agent gains information but cannot cause harm through reading alone.

Create feature branches: Low risk. Branches are isolated from main development lines by design. Wrongly created branches can be deleted without affecting other developers or production systems. The impact scope is contained.

Force-push to main branch: High risk. Force-pushing rewrites git history on the primary branch, potentially destroying commits, breaking other developers' local branches, and violating code review processes. It is difficult to fully recover from without careful git archaeology. Scope affects the entire team.

Deploy to production: Critical risk. Production deployments immediately affect live users. Bad deployments can cause downtime, data loss, security vulnerabilities, or incorrect behavior for all users. Rollback is possible but may not be instant and has its own risk.

Why the other options fail: - The claim that all four actions are equally low-risk because they are standard Git and deployment operations ignores the fundamental difference between read-only and write operations, between reversible and irreversible actions, and between local and global scope. - The classification that rates reading as minimal, branch creation as high, force-push as low, and production deployment as low inverts the classification of force-push and branch creation. Creating branches is isolated and reversible; force-pushing to main is the opposite of both. - The classification that rates reading and branch creation as high-risk because they could expose code, while force-push and deploy are low-risk because they are automated, misunderstands risk classification. Read operations do not modify state and cannot cause outages or data loss. Classifying reads as high risk would make normal agent operation impossible. Automation does not make force-push or production deployment low-risk, because automation does not reduce irreversibility or blast radius.

Proper risk classification is the prerequisite for assigning appropriate autonomy levels — actions with higher risk classifications require higher levels of human oversight.