What it can reach,
and what it can't

There is no WireHop server: no account, no coordination service, no company in the middle that could be breached to reach your machines. That includes us. Here are the boundaries, and where they stop.

If an agent is compromised What this doesn't protect you from

Reach

Every member has a role and every machine has tags. Traffic is forwarded only if the role covers the tags. Default-deny: a new member reaches nothing until it is granted a role.

Confinement

A session runs inside an OS sandbox, Seatbelt on macOS and Landlock on Linux: which commands may run, which paths are visible, whether it can reach the network. A client can ask for more restriction than the host set, never less.

Privilege

The daemon may listen as root, but shells, commands and file transfers run as the ordinary user bound into the invite. That user is fixed when the invite is made.

Record

Every machine keeps its own audit log of connections, commands, transfers and denials. No central collector, no telemetry. Read it with hop audit.

Identity and transport

Each machine's identity is an Ed25519 key generated on first run. Connections are QUIC with TLS 1.3 end to end; a relay only ever sees ciphertext. Releases are signed, and the installer refuses a mismatch.

If your AI agent is compromised

The fair question about any tool that lets software run commands on your machines.

An agent holds exactly one thing: an invite you issued it. It is single-use, time-limited, and carries the limits you set when you made it. It is not a master key, and it cannot grant itself more than it was given.

A scoped agent can

  • Reach only the machines its role permits
  • Run only the commands you allowed, if you set an allowlist
  • Read only the paths you scoped it to
  • Work until the invite expires, then stop

It cannot

  • Escalate its role or mint invites, unless you gave it admin
  • Reach a machine its role's tags don't cover
  • Write anywhere, if the invite is read-only
  • Act without a record on the machine it acted on

Give an agent the least invite that works. A monitoring agent wants read-only access to one machine with two allowed commands, not membership in your network.

# a monitoring agent: read-only, two commands, one machine, one hour $ hop invite --tier client --read-only \ --allow-command df --allow-command uptime --expiry 3600 # a deploy agent: one directory, no network egress $ hop invite --preset deploy --scope /var/www --no-network # see what it actually did, on the machine it did it to $ hop audit --since 1h

Every restriction an invite can carry, with defaults, is in the docs: everything an invite can restrict.

What this does not protect you from

A security page that only lists strengths isn't a security page.

Bad judgment within limits

Scoping bounds the blast radius; it does not make an agent's judgment good. If it can write to a directory, it can delete the wrong file there. Scope to the job and read the audit log.

A compromised machine

Root on one of your machines is that machine's identity. Revoke it with hop fleet prune or an admin revoke.

A mishandled invite

An unredeemed token is a bearer credential. Short expiries and single use limit the window; they do not close it. Treat it like a password.

People outside your control

WireHop is for machines you own. No multi-tenant model, no per-customer isolation, no SSO. If you need those, it is the wrong tool and we would rather say so.

Traffic analysis at a relay

A relay cannot read your traffic, but it can see that two machines exchanged packets and roughly how much. If that matters, run your own.

An unaudited codebase

There has been no third-party security audit. The code is public and the threat model is written down, which is not the same thing.

Found something? Report it privately through GitHub's security advisories on the repository. We aim to acknowledge within 72 hours.

Security policy Full threat model Standing self-audit