Security · Orpheus

The connector

The connector is a small program that runs on your machine next to your agents. It opens one outbound secure WebSocket to Orpheus. It does not listen on any port and accepts no inbound connection.

It can

List the tmux sessions your policy exposes
Stream the output of those sessions
Type text into them with tmux send-keys
Send a key from a fixed list: up, down, left, right, enter, escape, space, tab, backspace
Start a new agent session from an allowed list of commands
Share transcripts and usage readings, if your policy allows

It cannot

Run an arbitrary command. There is no exec frame in the protocol.
Reach sessions your policy hides. Plain shells are hidden by default.
Be reconfigured by us. The server cannot change the policy file.
Be reached from outside. It only dials out.

The connector is an open package under the MIT license, so you can read every line your agent installs. It is published to npm after its security review.

Worth knowing: typing into an agent session is powerful, because the agent can act on what it is told. That is the product. The limits above control which sessions can be typed into and who may type; they do not limit what your own agent does with an instruction.

Tokens and credentials

Item	What it is	Lifetime	Where it lives
Connect token `oc_ct_…`	32 random bytes. Single use. Valid for one workspace. Used once by `pair`, then burned.	15 minutes	Shown to you once. We store its sha256 hash.
Connector credential `oc_cc_…`	Issued in exchange for the connect token. Bound to one workspace and one server.	Long-lived. Rotates every 30 days over the open connection.	On your machine in `~/.config/orpheus-connector/credential` (mode 0600), or the keychain on macOS. We store only a hash.

Each time the connector connects, the server checks the credential's hash, its revocation flag and that your workspace's plan allows the server. Revoking a server closes its connection at once and the credential stops working.

Local policy

The file ~/.config/orpheus-connector/policy.json is edited only on the machine. It decides:

Which tmux sessions are exposed. Default: all Claude Code and Codex sessions, no plain shells.
Whether input is allowed. Default: on for agent sessions, off for shells.
Whether transcripts are shared.
Whether usage is read.

The server cannot change the policy.

Sending input

Before text or a key is sent to a session, the server requires:

A signed-in member of the workspace with the operator role or above.
A fresh step-up: if the device has not been verified in the last 12 hours, a passkey or a fresh email code.
That the request passes a per-user and a per-server rate limit.

Workspace isolation

Every row of customer data carries a workspace id, and the database enforces isolation itself with row-level security. The application connects with a role that does not own the tables and cannot bypass row-level security. Each request runs in a transaction scoped to one workspace, set only after your membership in that workspace is checked.

A query that forgot to filter by workspace would return nothing from another workspace, instead of leaking it.

Accounts and sessions

Sign-in: Google, or a 6-digit email code with a magic link. Codes expire after 10 minutes and allow 5 attempts. Requests are rate-limited, and the response is the same whether or not an account exists for that email.
Passkeys: optional. They can be added only from a signed-in session.
Sessions: an opaque random 256-bit token in an HttpOnly, Secure, SameSite=Lax cookie. We store its sha256 hash. Sessions expire after 30 days without use. You can see every session and sign out everywhere.
Recovery: your email is the root. Changing it needs a code from both the old and the new address.

Audit log

Every send, key, new session, pairing, revoke and role change is written to the workspace's audit log with who did it and when. Workspace admins can read it.

What we never hold

SSH keys for your machines
Passwords for your machines
An address to connect in on. We have no way to open a connection to your machine.
Your connect token or connector credential in readable form. Only hashes.

What we do see

To show you your sessions, the following passes through our servers:

The names and state of the sessions your policy exposes, and the label you gave the machine.
The terminal output of sessions you open, and the text you send.
Transcripts and usage readings, when your policy shares them.
Your account email, and the IP address and browser of your sign-ins, shown to you in your session list.

If you don't want a session's content to leave the machine, hide that session in the policy file.

Staff access

There is no owner bypass and no back door in the application. Staff admin access can be granted only from the server's command line, not through the product.

Report a problem

Found a vulnerability? Write to security@example.com. Please include steps to reproduce it.

What we can and cannot do on your machine.