Plexus

English

中文

English

中文

Appearance

Get running ​

Plexus is the resource side: a gateway you own that fronts the tools on your machine, so an AI agent reaches them only through a default-deny, fully-audited boundary — never a raw key. That model is identical everywhere. What you choose first is only plumbing: where the gateway runs, and who can reach it.

So pick a cell below — the machine the gateway lives on, and how far its network reaches. Then, in Watch the trust loop, learn the one thing that never changes: how a call is discovered, granted, invoked, and revoked.

The fastest way in: let your agent set it up for you. Pick your cell, copy the prompt, paste it into Claude Code or Codex — it reads the real runbook and drives the whole setup, narrating each step and pausing for your decisions and approvals.

Fastest start

Pick where it runs and who can reach it

Two decisions — the machine the gateway runs on, and how far its network reaches. Pick a cell, copy the prompt, and paste it into Claude Code or Codex. It clones the repo, reads the real runbook, and sets everything up — pausing whenever it needs your decision or approval.

Paste this into Claude Code or Codex — it reads the real runbook and drives the setup.

You're helping me try **Plexus** — a local capability gateway that lets you (my AI agent) reach the tools on my Mac only through a governed, default-deny, fully-audited boundary, instead of me handing you a raw key or a shell.

Set it up and run it now. Work **in order and idempotently** (safe to re-run), and **narrate each step in plain language** so I follow along and learn how Plexus works as you go. Whenever a step needs my **decision** or my **approval** (clicking Approve in the Plexus console), **stop and ask me** — never guess past those.

1. Clone https://github.com/nemori-ai/plexus (or cd into it if I already have it) and read **docs/getting-started.md**.
2. Install, boot the gateway on loopback, and open the /admin console. Run the built-in onboarding: expose the demo — one open folder (demo-intro) and one protected folder (your-secret) — then connect yourself as an agent using your own per-agent credential (never my admin connection-key).
3. Walk me through the loop: read demo-intro (flows), then read your-secret (**pends for my approval** in the console). Point me at the console URL when something needs me.

At the end, summarize in a few lines what I just saw: the two credentials, why the protected read pended for me, and how one revoke would cut you off.

Next — the one thing that never changes: Watch the trust loop →

What every setup shares ​

Two roles, kept straight throughout — this never changes across machines or wires:

  • You are the admin. You hold the connection-key, the management credential; it authenticates the /admin console. You never give it to an agent.
  • The agent gets its own credential. When you connect an agent, it enrolls for a durable per-agent PAT and calls with that — never the connection-key.

Reaching the gateway buys an agent nothing on its own: enrollment needs a code you minted, calls need grants you approved, execute stays per-use unless you explicitly opted that agent + capability into standing at connect (default off, double-confirmed), and the connection-key appears on no agent-reachable route. That's why publishing to a LAN or a tunnel is just reachability, not a new trust story.

Platform

macOS (Apple Silicon or Intel) is the primary target; the Apple Calendar / Reminders sources are macOS-only. A headless Linux gateway is verified end-to-end (Ubuntu + Bun, in Docker) and serves the platform-portable sources — see the Linux runbook.

New to the mental model? The concepts (Connector → Source → Capability, provenance, the three clocks, the self-describing Floor) makes the rest click. The authoritative trust boundary is the security model.