Permissions — concepts

Kin separates three questions: whether the workspace is trusted, whether a particular tool call is approved, and what the operating system lets the process do. Modes and approvals covers the controls; workspace trust covers launch.

Decisions are a property of the tool

Each call has a risk kind: read, edit, shell, meta, MCP, network, or publish. The active mode maps it to Allow or Ask; planning can impose Deny. Multi-operation tools such as Git resolve risk from the actual operation. A generic kind never bypasses a tool’s more specific review boundary.

The decision chain

Workspace trust is established before project instructions/configuration or inference load. Tool execution then follows this order:

1. Resolve the operation’s risk kind.
2. Apply planning vetoes, including named configuration/handoff mutations.
3. Apply Auto or Strict policy; Strict classifies narrow shell reads.
4. Change protected Auto file edits to Ask.
5. Apply an exact reusable grant to Ask, if the call permits reuse.
6. Run the call or obtain its required human decision.

Unknown kinds fail closed. A grant can turn Ask into Allow, never Deny into Allow. Credential and MCP trust checks retain their own boundaries.

Spawning a subagent is free — the runtime gate is the safety net

Dispatch itself is a Meta operation. Children inherit root trust, mode, planning, and a narrowed tool registry; naming a tool cannot restore missing authority. Their individual calls still pass through review. The agent panel and model-facing controls provide inspection and cancellation.

Tri-state answers

Once approves one call; Session remembers its displayed scope; Deny returns a refusal. Fresh-state calls omit reuse. Scope may be a shell command head, exact compound command, repository/operation/remote/branch, or tool identity. Read the scope shown before accepting it.

Git credential trust is separate from permission to fetch or publish. Trust host stores a route fingerprint, not a push grant. A changed route asks again. Connecting GitHub can resume a parked call but does not authorize a different operation.

MCP is special

A server can change descriptions and schemas. Mutating MCP calls ask until explicitly covered by a tool/session/server grant. A read-only hint is used only after the server definition is trusted. Persistent server grants bind both configuration and the initial tool surface; additions/redefinitions need review. See MCP for exact trust and revocation behavior.

Mode is human-only

Only the person changes Auto/Strict through launch configuration or live controls. Tools, skills, fetched text, and child agents cannot change mode or create workspace trust.

Planning is a freeze, not a mode

The model can reduce its capabilities by entering planning; only the person can leave it. The freeze denies implementation, network/publication, and configuration/handoff mutations, including in children. It takes effect before later calls in the same batch. Saved plans survive, but the transient freeze is not restored as authority on resume. See the planning lifecycle.

What’s a “dangerous” tool, really

Auto shell/code run as the launching OS user. Structured file protections and approval rules prevent mistakes at their own interfaces; they do not contain arbitrary code. Hard isolation requires an operator-owned process boundary, such as a container, VM, or dedicated account.

Revoking grants

/grants manages workspace trust, tool approvals, related-directory scopes, MCP trust, and Git-host routes. Revocation removes the matching grant; persistent trust revocation affects subsequent launches/connections. See Managing grants.