Security

Permissions & scope

Anvil asks before it does something risky. When it's told no — or there's no one to ask — the request doesn't vanish; it becomes something an admin can decide later.

Anvil is built to act, but not to overstep. It runs under a permission mode and within ceilings, and when it wants to do something those don't already allow, it asks. What happens to that ask — in the moment, and when there's nobody at the keyboard — is one of the quietly important differences between working alone in the terminal and working with AnvilHub.

Ceilings and permission mode

Two things bound what Anvil may do:

  • A permission mode sets the posture for a session — from read-only (look but don't touch), through plan mode (reason and propose, don't execute), up to modes that let it act with or without prompting.
  • A ceiling is a hard maximum on a worker — see bot ceilings. A task can always ask for less than the ceiling; never more.

Together they mean a given action is either already permitted, or it triggers a scope request.

Scope requests in the terminal

In a normal interactive session, a scope request is a prompt: Anvil explains what it wants to do and why, and you allow or deny it. A grant can be one-time (just this once) or standing (from now on). This is /scope, and it works entirely offline — no account needed.

What AnvilHub adds: approvals that outlive the session

The terminal prompt has a limit: it only works if someone is there. Close the session and an unanswered request is gone.

When a machine is paired to AnvilHub, a scope request it can't resolve becomes a durable item instead — a row in the Inbox that an admin can decide later, even after the original session has ended and the machine has moved on. The decision is carried back to the host the next time it checks in, and a one-time grant is spent exactly once.

This is what lets an agent keep useful momentum without being handed broad powers up front: it can ask for exactly what a task needs, and if the answer has to wait for a human, the request waits with it rather than forcing you to pre-authorise everything just in case.

The Inbox

On AnvilHub, the Inbox is the queue for things that need a person: approvals, org business, and security records. An "actionable" badge means someone is genuinely blocked on you — distinct from the in-the-moment permission prompt inside a live session, which is still handled where it happens.

Where to next