🚦 Autonomy policy

By now, you’ve connected tools and assembled a team. There’s one question left, the one that decides whether you can sleep easy: what can the agent do without you?

A runtime/POLITICA.md responds with five levels, from N0 to N4. The file's first line sums up the idea: the greater the impact of the action, the more the human is involved.

What to look for in the table: it’s the exact copy of the “Autonomy levels” section from the POLITICA.md. The difference between N1 and N2 is who presses the button: in N1, you do; in N2, the agent does, with your approval.

How to read the diagram: each step gives the agent more freedom. The amber step (N2) is where the kit puts everything with an impact. The blue steps are for actions that, if they go wrong, you can undo without trouble.

The levels alone don’t mean anything. They make sense when you connect each action type to a maximum level. It's the second table in the POLITICA.md, the one for cap.

The last two columns show how each cap becomes a configuration: in Claude Code and Codex. You’ll see both in topics 4 and 5.

What to look for in the table: The ceiling drops as the possible damage increases. Reading doesn't break anything (N4). Spending and deleting can't be undone (N1): the agent prepares it, and you do it.

Leia runtime/POLITICA.md e responda em uma linha qual é o teto de 'Enviar'.

respondeu "N2" lendo a POLITICA

When Claude Code asks for permission, it offers "yes," "no," and an option to stop asking. By the tenth question in a row, the temptation is to click the third option. In one of the mod videos, there was even a helper that approved permissions on its own.

A POLITICA.md close that door with a sentence: a "always allow" permission never exceeds the action limit. You can allow reading forever. You can't allow payments forever.

In Claude Code, the policy becomes the file .claude/settings.json, which is included in the kit. Claude Code reads this file automatically when it opens in the folder.

The part that matters here is the list deny: commands the agent doesn't run; ask whoever requests them. These are the basic blocks that the POLITICA.md mentions "delete" and the forced push.

{
  "permissions": {
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(git push --force:*)",
      "Bash(git push -f:*)",
      "Bash(git reset --hard:*)"
    ]
  },
  "enabledMcpjsonServers": [
    "ponte-modelo"
  ],
  "hooks": { ... }
}

How to read the diagram: both requests go through the same amber box. Anything not on the list follows the blue arrow. Anything on the list stops at the red arrow, without asking and without depending on you watching.

Codex doesn't read the .claude/settings.json. In it, the policy comes through the sandbox, selected with the option -s for each call. The quota table already tells you which one to use.

The bridge runtime/pontes/codex-exec.sh, which you used in module 2.1, only accepts two values. Any other value is rejected before Codex is called.

What to look for in the table: sending, spending, and deleting have no sandbox in the bridge. For those rows, POLITICA says "no auto-approval" or "do not execute": Codex prepares it, and the action is up to you.

runtime/pontes/codex-exec.sh "x" . danger-full-access

sandbox recusado pela POLITICA, saída 2

case "$sandbox" in
  read-only|workspace-write) ;;
  *) echo "sandbox recusado pela POLITICA: $sandbox" >&2; exit 2 ;;
esac

Beyond the levels and the cap, the POLITICA.md has a short section called Integration. These are three rules about how the tools connect to one another.

They protect what no deny takes: your account, password, and system stability.

How to read the diagram: the amber bridge only passes text: the request goes in, the response comes back. Logins each stay in their own box. The red dashed line is the path that rule 2 prohibits.