Permissions and approvals

Permissions define the maximum authority of a Task. An approval may authorize one operation within the selected access level; it cannot change that level or override administrator policy.

Authoritative access profiles

Kairo recognizes five Task access profiles. The ordinary Task access selector offers the four interactive profiles Auto, Request approval, Full workspace access, and Full access. Read only is a real Host-enforced profile that the UI displays for review, planning, scheduled, or otherwise constrained work; it is not another ordinary approval preset in that selector.

UI profile	Host value	File and command behavior	Process network with the default Host policy
Auto	default	Routine tools inside Task roots run automatically. Explicit protected-file, dangerous-command, and other rules can still ask or deny.	Starts offline. An approval-capable invocation can request one network grant, subject to administrator rules.
Read only	read-only	Reads and Agent-internal state updates are allowed. File changes and mutating commands are denied rather than approved.	Read-only process activity remains inside the configured sandbox and network policy.
Request approval	strict	Reads are automatic; every file change and command asks first.	Starts offline. A command can request one network grant, still limited by administrator destination and method policy.
Full workspace access	bypass	Tools run without approval inside Task roots. Outside-root access and independent safety rules remain blocked.	The process sandbox remains. Under the default network-deny policy, no approval prompt exists to widen it, so Agent processes remain offline.
Full access	full-access	Removes Task-root confinement, the process sandbox, and local command approvals. It is available only when administrator policy permits it.	Removes the normal process-network boundary. Browser/site approvals and external-service policies remain separate.

Only Full access removes the filesystem and process-network sandbox. Full workspace access does not. Choose the narrowest profile that can complete the Task; administrator policy can further restrict any selection, and an approval cannot widen that ceiling.

Full access affects the whole machine

Full access can read or change files outside the Project and use the network without a command approval. Use it only in an isolated environment that you control, review the request first, and return to a narrower level when the exceptional operation is complete.

When a change takes effect

• In the new-Task composer, the selected level is captured when you create the Task.
• For an idle Task, changing the level is saved for its next run.
• During a run, a change applies only to new tool decisions. It does not rewrite an approval that was already issued or alter an operation already in progress.

To narrow access immediately, stop the run, inspect any partial effect, choose the new level, and then continue. Opening the Task from another client does not replace its saved level with that client's default.

Read an approval request

Before approving, check:

• the exact tool and arguments;
• the workspace root or external location affected;
• whether the action writes, executes, connects, publishes, or deletes;
• which Agent or subagent requested it;
• whether approval is once-only or scoped to an identical invocation for this Task.

Reject the request when its impact is unclear. Add a steering message with a safer alternative so the Agent can continue productively.

Permission boundaryDecision required

Kairo Code

Workspace write · local command

Know what will happen before it runs

Run affected testsDecision required

1. 01Review action
2. 02Choose once or rule
3. 03Inspect receipt

Browser, network, and external tools

Browser and MCP-backed operations use the same Task permission boundary. Seeing a browser page does not authorize an action on it, and adding a Plugin or Skill does not grant its tools broader access. Remote Projects evaluate permissions on the remote Host, where the work actually runs.

Cancellation and recovery

Stop cancels the active run at a safe boundary. Pending approvals do not survive as free-floating authority: recovery reconnects them to the exact durable Task state, and stale requests are not silently replayed against a different operation.