Boundlane Sheet D-403 / Known limits

D-403 Reference

Known limits

What the sandbox does not stop, and what Boundlane does not claim. Each item is here because a reviewer would find it anyway.

Read before a security review

The machine's owner can change the machine

On Free and Team, the developer administers the runtime on their own laptop. They can approve their own requests, load rules by hand, or run an agent outside Boundlane. Team records what it can see as drift. Enforcement the owner cannot change needs a gateway they do not administer, on the License plan.

Tools the model vendor runs on its side

Claude Code's web search runs at Anthropic. The sandbox sees one call to the model API, and the search query travels inside it. The sandbox matches method and path, not request bodies, so it cannot block the search without blocking the model. Treat search queries as a channel out, through the vendor. To close it, turn web search off in the agent's settings or in your Anthropic organization. That setting is the vendor's, and the sandbox does not enforce it.

The model API is a channel

Whatever the agent reads, it can send to its model in a prompt. That is how agents work. The sandbox decides which files and hosts the agent can reach. It does not inspect what the agent says to its model.

Desktop apps are not contained

Boundlane starts command-line agents. A desktop editor with an agent built in, such as the Cursor app, can open a terminal on the host outside any sandbox, so it is outside the line. Start the agent through boundlane run.

Blocked file writes are not logged

The runtime records network decisions. A write the filesystem rules block fails with Permission denied and leaves no line in the log.

Unlisted hosts look like a network outage

A host that is not in the policy is refused before any request is sent, so the agent sees a failed DNS lookup or connection rather than an explanation. The reason is in boundlane log --deny. Hosts that are listed get a descriptive HTTP 403 when a request breaks the rule.

Paths cannot change in a running sandbox

Filesystem and process rules are fixed when a sandbox is created. A change to paths or workspace access takes effect in the next sandbox. Only network rules change live.

Rule types the policy cannot express

GraphQL, MCP, WebSocket, and JSON-RPC rules are not in the policy file, because the prover cannot check them. Neither are raw TCP and TLS passthrough. Wildcard host names and address pinning are not in the file either. A listed host that resolves to a private address can reach it.

Windows runs through WSL 2

There is no native Windows enforcement. On Windows, the sandbox runs inside WSL 2, which upstream marks experimental.

Subscription logins

Agents run with API keys. A subscription login would leave its token where the agent can read it, so it is not supported.

What the prover proves

The policy check shows what a policy allows, against a boundary. It is not a statement about the model or the agent. A policy that passes can still allow something unwise if the boundary allows it.

Lost log events stay lost

The runtime's event buffer is limited and does not survive a gateway restart. When events are lost, the console shows the gap. It does not reconstruct the missing decisions.

What we do not claim

  • That AI is safe, or that we stop an agent from wanting something. We stop it from doing things outside the policy.
  • That every program calling itself an agent is covered. Only agents started inside the sandbox are.
  • A cryptographic ledger, memory snapshots, or in-silicon quarantine. None of those are part of this product.