D-203 Use

Requests and approvals

When the agent needs a host the policy does not allow, the call is blocked and a request is filed. A person reads it and decides. The agent never approves itself.

Where a request comes from

Every blocked network call becomes a draft request, with the host, port, and the program that tried. The sandbox drafts it on its own.

The agent can also file a request itself, with a reason, such as "install the project's Python dependencies". When Boundlane starts an agent that supports it, it adds a short guide to the agent's instructions: how to see what was blocked, how to ask for the narrowest access the task needs, and how to wait for the answer. boundlane run prints a guide line when it does. Claude Code, Codex, OpenCode, and Grok get the guide today.

The reason helps the reviewer. It does not change the decision rules. A request with a convincing reason still waits for a person.

What can be requested

Network access only: a host, a port, the program allowed to use it, and, for inspected hosts, the methods and paths. That is a door, and it applies to the running sandbox.

A request for a new folder is not something the agent can file. Paths are walls. Changing them means editing the policy, and the next sandbox picks it up. See Walls and doors.

Approving on Free

List what is waiting, then decide.

■ 1 request from the agent  bl-web-4f2a

    7f3a91c2  crates.io:443
              /usr/bin/curl  “User asked for the newest serde version from the crates.io API.”

    1 more was drafted by the sandbox from refused connections, not asked
    for by the agent: sentry.io:443.

    boundlane requests --all  list the drafts too

The list shows what the agent asked for, with its reason. Drafts the sandbox made from blocked calls are counted under it, with their hosts. Many come from the agent's own program working in the background, not from the task. boundlane requests --all lists them as well, under their own heading, so you can approve or deny one.

Boundlane tells the two apart from the sandbox log, which marks each request the agent filed, and from the reason. A draft's reason is generated, in the form "Allow node to connect to sentry.io:443 (HTTPS)."

The id is the start of OpenShell's longer one. Any start that matches only one request works.

An approval becomes a new policy revision for the running sandbox. The sandbox picks it up on its next poll, about 10 seconds later, and the agent can retry. A denial is kept with its reason. If the agent filed the request and is still waiting, it is told the reason and can ask for something narrower.

An approval lasts as long as the sandbox. To keep a host for the project, add it to boundlane.yaml.

Approving on Team

1. The CLI on the developer's machine sees the blocked call and sends the request to the control plane.
2. A reviewer opens it in the console and approves or denies it, with a reason.
3. The CLI picks up the decision on its next check and applies it to the sandbox. The connection is always from the machine to us.
4. The control plane records who decided and when, and matches it to the sandbox's own record of the change.

If the control plane is unreachable, the request waits and the call stays blocked. If someone approves a request on the machine itself, outside the console, it shows up as drift.

What the reviewer sees

The reviewer does not see the agent's conversation, the code, or the terminal. Those stay on the developer's machine.

Never automatic

OpenShell can be set to approve requests on its own. Boundlane never turns that on. boundlane doctor fails on a gateway where automatic approval is set for every sandbox, boundlane doctor --fix turns it off, and the policy file has no field for it.

An approved request never reaches a private network address, even when the host name resolves to one.