Permissions

Choose what your agent can reach

lnk agent permissions                  # what's on, what each opens, and whose
lnk agent allow read-home
lnk agent deny network
lnk agent allow host api.anthropic.com # only these hosts, then
lnk agent allow tcp github.com:22      # a port beyond HTTPS and HTTP
lnk agent allow tool gh                # a tool running outside the sandbox
lnk agent allow calls 600              # at most 600 calls a minute on its proxy
lnk agent start --sandbox sandbox.toml # all of it from a file

What you grant is your agent's own and follows it to any harness. allow and deny restart the agent if it runs, and lnk agent permissions marks each permission as yours or its harness's (Allow what a harness needs).

By default its harness writes only its home, your files folder and /tmp/<name>*, and reaches the internet only through Link's filtering proxy, never this computer's other servers or your home network. Permissions open more. They're kept in the agent's sandbox file, ~/.config/lnk/agents/<agent>/sandbox.toml, which --sandbox reads and allow writes. It takes the same names:

permissions = ["network", "developer-tools", "read-home"]
hosts = ["api.anthropic.com", "api.telegram.org"]   # none: any host
tcp = ["github.com:22"]
tools = ["gh"]
calls = 600

[files]                       # its files folder: what it may write, what only read
write = ["instructions", "skills", "work"]
read = ["conversations"]

Left out, permissions is Link's defaults. A line is refused, and the error names it, when it holds an unknown key, an unknown permission, unsandboxed (which only a harness can be given) or another agent's memory or scheduler (memory-<id>, scheduler-<id>).

lnk agent permissions and help show only this machine's own: developer-tools only on a Mac, and each permission as it works there. Another machine's is still taken, so an agent's grants and a script work on both.

• Hosts: with a list, its proxy lets it reach only those. Keep its model's host and its channels' on it, which are api.telegram.org, slack.com and *.slack.com, discord.com and *.discord.gg, web.whatsapp.com and *.whatsapp.net, and *.signal.org. With no list, any host.
• Ports: the proxy passes HTTPS and HTTP. Name anything else as host:port, such as github.com:22 for git over SSH with a key in the harness's ~/.ssh. On Linux a database client reaches a named endpoint too, but on a Mac only a client that takes a proxy command, like git over SSH, does.
• Tools: add one with lnk sandbox tool add, then allow tool. Any other harness finds it in its own MCP settings, and Link Harness at $LNK_TOOL_<NAME>. Each is an HTTP MCP server on its proxy, and calls you didn't allow by name ask you first.
• Calls: with a limit, its proxy takes at most that many calls a minute and answers the rest with a 429 until the minute has room.
• Files: its files folder holds instructions/ (what it's told to be), skills/, conversations/ and work/ (anything else it makes). [files] write names the folders it may change, and read those it may only read, so put instructions under read to lock its instructions. conversations is written only by its harness. Link Harness's sandbox then reads the folder and writes only those and its conversations. A harness from outside Link works in the whole folder, so for it [files] holds only for Link's tools, and a start says so.
• lan: for a NAS, Home Assistant or a model on another computer. It brings back the known gaps that lnk agent <harness> check shows as open.
• unsandboxed: no sandbox at all, for a harness that can't run in one, so it reads your whole home folder. Only a harness asks for it (Allow what a harness needs). lnk agent <harness> allow unsandboxed gives it to one that does, every start warns, and lnk agent <harness> deny unsandboxed takes it back. lnk agent start --no-sandbox is the same for one start.

The sandbox itself, its proxy, its log (lnk sandbox log) and stopping every agent's way out at once (lnk sandbox stop) are on the sandbox page.

Allow what a harness needs

lnk agent use openclaw          # shows what it needs that your agent hasn't, and asks
lnk agent use openclaw --yes    # allows it without asking, for a script
lnk agent openclaw permissions  # what it needs and has now
lnk agent openclaw deny lan     # take it back
lnk agent openclaw allow lan    # give it back: only what it asks for
lnk agent openclaw repermit     # ask again, at its next start

What a harness needs beyond your agent's grants is the harness's. It's asked when your agent switches to it, held only while it runs, and never given to another harness. A harness that needs nothing, such as Link Harness or DeepSeek Harness, runs with your agent's grants alone.

A harness says what it needs beyond Link's defaults, with why. That can be a permission such as lan, no sandbox at all (unsandboxed), or a risk of its own, by its own name, like Hermes's whatsapp-bridge. lnk agent use shows every line the new harness needs that your agent hasn't, what it was given here before, and asks before anything changes:

  openclaw may do more on this machine than link:
  + lan              network as it is, in place of its filtering proxy: ...
                     openclaw says: Slack's websocket ignores Link's proxy (HTTPS_PROXY)
  This holds for main, and every other agent here that runs openclaw.
  Switch main to openclaw with these? No keeps it on link, and nothing changes. [y/N]

What it may do less of is said in a line and asks nothing. The first start on a harness, and any start after its needs grew, ask the same way before it runs.

• No, or Enter, changes nothing, and your agent stays on the harness it had, running. Its next start asks again.
• Yes grants exactly those to the harness, for every agent here that runs it, and starts it.
• What your agent has of its own asks nothing, so a harness needing read-home runs without a question for an agent you granted it.
• Without a terminal, --yes answers for you, and without it the switch or start fails and says so. --yes never allows unsandboxed. That takes a yes in a terminal, --allow-unsandboxed from a script, lnk agent <harness> allow unsandboxed, or lnk agent start --no-sandbox for one start. A machine whose ~/.config/lnk/machine.toml says unsandboxed = false refuses them all.
• A risk the harness can run without, such as OpenClaw's browser, is asked on its own, and no leaves it off while the harness runs. Without a terminal, or with --yes, it stays off until you allow it.

It asks once. A later start asks only for what's new, never for what you allowed or took back, and lnk agent <harness> allow, deny and repermit change or forget an answer. lnk agent move asks in your terminal before the agent starts where it goes, and no leaves it where it was, running.

Every start of a harness running with more than the defaults says so, and how to take it back, as in openclaw runs with lan, beyond Link's defaults (lnk agent openclaw deny lan). lnk agent status shows the same in its Sandbox row.

Check the sandbox

lnk agent link check
lnk agent hermes check

check tries, from inside the sandbox, what the harness shouldn't be able to do, such as reading your home folder or other programs' secrets. It reports each try as:

• blocked: the sandbox stopped it.
• allowed: a permission you granted let it through.
• open: a known gap, listed in Security.
• LEAK: something no permission allows got through. The command fails, and please report it.

Run a command in its sandbox

# reach what your agent reaches, and nothing more
lnk agent link run -- curl -sI https://example.com
# a shell, as your agent
lnk agent link run -- sh
# another harness's home
lnk agent hermes run -- sh -c 'ls ~'

run starts the command the way the harness runs, with its home as HOME, in your agent's files folder, with its permissions and through its proxy. So lnk sandbox log shows its calls, as <agent>-<harness>-run. It runs beside your agent, which keeps running.

Troubleshooting