Action Safety Tiering
Overview
Action Safety Tiering is a risk-based confirmation policy for agentic prompts: classify each candidate action by reversibility and reach, then gate it accordingly. Local, reversible work (editing files, running tests) is performed freely; actions that are hard to reverse, reach shared external systems, or are otherwise risky or destructive require explicit user confirmation before execution. The pattern appears verbatim as the <action_safety> block in grok-build’s system prompt.
The Tier Model
The policy defines a two-axis classification:
| Axis | Low | High |
|---|---|---|
| Reversibility | Edits, tests, local scaffolding — cheap to undo | rm -rf, force-push, git reset --hard, amending published commits, dropping tables, killing processes |
| Reach | Local filesystem, current workspace | Shared/external state: push, PRs/issues, Slack/email/GitHub messages, shared infra, permissions, CI/CD changes |
Rule: act freely on low-low; confirm before anything high on either axis. The prompt gives concrete exemplars of each risky class and emphasizes that confirmation default can be overridden only by an explicit user grant of greater autonomy.
Key Tenets
- One approval is not a blank check. Approving an action once (e.g., a git push) does not approve it in every later situation; each high-risk action is re-confirmed unless the user authorized it in advance.
- Investigate unexpected state before touching it. Unfamiliar files, branches, or configuration may be the user’s in-progress work — the prompt instructs the agent to investigate before deleting or overwriting.
- Confirmation is cheap; a mistaken action is not. The asymmetry of cost (lost work, unsendable messages, deleted branches) is the economic justification for the tier.
- User override is explicit. Autonomy grants must come from the user; the agent does not self-escalate.
Relationship to Other Gate Patterns
Action Safety Tiering is a permission gate — it decides whether an action may be taken. It is complementary to, and distinct from:
- plan-before-implement-gate — decides what/when to plan before acting. A plan gate is a workflow discipline; action safety tiering is a risk classification over individual tool calls.
- cooldown-heuristics — timing/repetition guards against runaway loops; action safety tiering guards the blast radius of single actions.
- anti-prompt-injection — defense against instruction subversion; action safety tiering constrains legitimate actions, assuming the instruction channel is trusted.
Implications
This pattern converts the implicit “confirm before dangerous actions” habit into an explicit, enumerable policy with worked examples — a teachable and testable contract for agent harnesses. Because the classification lives in the prompt rather than in code, it is inspectable, leakable, and overrideable by the model — which is both its strength (auditable) and its weakness (a hijacked agent may ignore it, so harness-level enforcement is the true backstop). Its “one approval is not a blank check” rule is a sharp antidote to session-scoped permission grants in long agent runs.
Open Questions
- Is the tiering enforced at the harness layer in production Grok Build, or is it prompt-persuasion only?
- How does the model weigh borderline cases (e.g., editing a file then committing it) — per-call or per-composite-operation?
- Should the “investigate unexpected state” tenet be elevated to a general agent-safety principle beyond this prompt?
Related
- grok-build — the system prompt that instantiates this pattern as
<action_safety> - plan-before-implement-gate — the planning-discipline counterpart to the permission gate
- cooldown-heuristics — loop-level guard, contrasted with the per-action tier
- anti-prompt-injection — safety posture complementing the action tiering