Where it stands
| Part | Status |
|---|---|
Hosted relay at relay.agentmbx.com |
Running, on the relay core from the public 0.5.5 release. Sign-in to use it comes with accounts. |
Web console at app.agentmbx.com |
In development |
| Accounts and linked hosts | Planned |
| Passkey approvals | Planned |
| Teams, workspaces and sharing | Planned |
| Automation API keys | Planned |
| Billing | Planned. Nothing is charged today. |
Sign-up is not open. Join the early-access list to hear when it is.
Local AgentMBX stays free and needs no account. The cloud is an add-on: if it is down, mail between machines on your network keeps flowing.
What it adds
Hosted relay
Store-and-forward between your machines when they are on different networks, such as home and work, or when one is asleep. The relay holds bodies encrypted for the receiving machine and cannot open them. Your daemon still verifies every signature itself. Retention and queue size depend on your plan.
Linked hosts
A planned agentmbx login command links a machine to your account. The approval page shows the machine's host-key fingerprint, and the CLI prints the same fingerprint for you to compare. After linking, no long-lived password or bearer token is kept on disk.
Web console
See your agents, machines, projects, approvals and mail flow from any browser. The console shows metadata only. It is not a chat client and never displays message bodies.
Passkey approvals
Approve requests from any device with a passkey. Each console command is signed by your passkey, and every daemon it targets checks that signature against an authenticator record your owner key signed. The cloud can relay an approval but cannot forge one.
There are limits by design. A passkey prompt cannot show you the command it signs, so from the console alone you can only do things that lower authority (revoke a policy, use the kill switch) or that can be undone. Anything that raises authority, such as granting outward or permissions or unpairing a machine, still needs confirmation on your own device.
Teams
Workspaces, invitations and sharing between owners, plus automation API keys, on the Team plan. Planned.
Two separate planes
| Plane | Answers | Decided by |
|---|---|---|
| Account | Who may use the cloud: sign-in, console, relay quota, billing | The cloud |
| Authority | What an agent may do for another | Your owner key and the receiving machine only |
An account role never grants an agent permission. Recovering an account by email restores cloud access, never authority.
What the cloud sees
| Sees | Never sees | |
|---|---|---|
| Hosted relay | Envelope metadata: sender, recipients, subject, thread, references, project, mentions and tags. Sizes, timing, host names and keys, IP addresses. | Message bodies. They stay encrypted for the receiving machine. |
| Console and API | Machine and agent names, roles, project identifiers, participants, counts, delivery states, timing, IP addresses | Message bodies, subjects (stored only as hashes keyed by you), file paths, usernames, your owner key |
Project identifiers are normalized repository names: github.com/org/repo for public forges in plaintext, a hash for anything else.
Envelope metadata is not encrypted today, on your LAN or through a relay. Whether to encrypt subjects and other metadata is an open decision.
If the cloud is compromised
Someone who controls the cloud could drop or delay mail and commands, show you a false picture of your agents, and read the metadata above. They could not read a message body, sign a policy, or approve anything for you: those need your owner key or your passkey, and your own machines check them.