Beem0807/reach

reach

Let AI agents operate your production machines - safely. Reads run; every write is blocked and queued for a human to approve before it touches anything. No SSH, no VPN, no open ports.

The one idea: on a production agent, an AI (or any automation) can inspect everything the agent can reach, but it cannot change anything until a person approves the exact action.

# your agent asks to do something destructive on prod...
$ reach exec --agent prod -- kubectl delete pods --all -n payments
  Status: REJECTED - approval required; a request was sent to your operator.

# ...an operator approves the pending rule once - structured, not a string:
#   { verb: delete, resource: pods, namespace: payments, name: * }
$ reach approvals approve appr_9f2c
  Approved.

# ...and now it runs - this time and next, without re-asking.
$ reach exec --agent prod -- kubectl delete pods --all -n payments
  Status: SUCCEEDED

You approve a rule, not a command string - so an approved action can't be extended (… | tee /etc/x, … && rm -rf) to smuggle something past it. That's the difference between "AI on prod" being a liability and a system you can operate with confidence.

⚡ 2-minute Quick Start

Zero to your AI agent running commands on a real machine, in three steps:

1. Start Reach. One command runs the backend, creates your tenant and first agent, installs the CLI, and logs you in:

curl -fsSL https://reach-releases.s3.amazonaws.com/local-setup.sh | bash

2. Install the agent on the machine you want to control. The script prints a ready-to-paste command - a curl … | sudo bash for a host, or helm install … for Kubernetes.

3. Connect your AI tool. reach agent-init writes the context file for Claude Code / Cursor and prints the MCP server config to drop in - now your agent can drive that machine through Reach:

reach agent-init

Now ask your AI agent to run something - or check it yourself:

reach exec -- hostname

That's it: your AI agent has controlled, audited access to the machine - no SSH, no VPN, no open ports. Setup asks you to pick the mode and defaults to readonly (safe: the agent can look but not touch) - a new agent never runs writes by default. For real operations, choose approved (Agents → [agent] → Policy) so reads run and writes stop for sign-off - that's the posture up top; wild (unrestricted) is opt-in for personal/dev boxes. On AWS instead? Swap step 1 for lambda-setup.sh. Docker, Kubernetes, and production hardening are in SELFHOSTING.md.

---

### ⚠️ What Reach is - and isn't Reach gives AI agents controlled, audited command execution on machines you own. It is not a sandbox for arbitrary untrusted commands. - On production, run approved mode - the posture above: reads run, every write needs a human-approved structured rule, everything else is blocked and queued. This is the intended way to point an AI at real infrastructure. - wild mode is the opt-in exception - it runs anything (reboots, deletes, package installs). Use it only on personal/dev boxes where you're the sole user. - Reach is not a security boundary against the machine's own owner/root - whoever controls the host can read the agent's token. See SECURITY.md for the full threat model, and POLICIES.md for how the modes work.

---