# rc.center / AI hub (full description)

> rc.center is a hub for AI-assisted development. Its first product, AI hub (https://ai-hub.rc.center), does two things: it lets you start and supervise AI coding CLI sessions (Claude Code, Codex CLI) on your own machines from your phone or browser, and it keeps an end-to-end encrypted secrets vault that AI coding agents request secrets from through MCP, with a human approving every request on the phone or in the web panel.

Pricing: free for a vault with up to 25 items (machines, approvals and grants included); rc.center Pro removes the limit for US$ 9/month, or R$ 49/month in Brazil (promotional price, also includes OTPBox), at https://rc.center/account/plan. AI hub is provided by ZODO SOLUCOES EM TECNOLOGIA LTDA ("Zodo Studio"). Contact: contact@zodo.dev. The short version is at https://ai-hub.rc.center/llms.txt.

## The problem it solves

Handing a secret to an AI agent usually means pasting it into the conversation, where it stays in the transcript, the logs and sometimes the commits. With AI hub the agent asks for the secret by name, a person approves the request on a device they trust, and the value reaches that one session encrypted, for a limited time, with every step on the record.

## Components

- Hub: the managed service at https://ai-hub.rc.center (the same Go binary can be self-hosted). It serves the web panel, the account API, the remote MCP endpoint and the relay between your machines and your devices.
- Web panel: https://ai-hub.rc.center. Sign in, approve requests, manage vaults and items, grants, proposals, the audit trail, devices and machines. Unlocking the vault in the browser derives the key locally; the master password is never sent.
- Android app ("AI hub"): approvals with push notifications, the vault, grants, proposals, machines, and biometric unlock. Install it from Google Play: https://play.google.com/store/apps/details?id=center.rc.aihub (publisher Zodo Studio).
- Local agent `rc-agent`: a desktop binary for Linux, macOS and Windows (https://ai-hub.rc.center/local-agent). It pairs the machine with your account, starts and supervises Claude Code and Codex CLI servers per profile and working directory, reports machine metrics, and runs a per-session MCP server for secrets. Its local panel binds to loopback only. `rcctl` is the optional command-line client.

## How a secret request works

1. The agent calls `secret_request` with a name (a path such as `production/deploy/DB_URL`, or a folder such as `production/deploy/*`), a reason, and its own age public key (required).
2. The owner gets a push notification and sees the request, the reason and the requesting client on the phone or in the panel. The name is only a suggestion: the approver picks what to release, the lifetime (15 minutes, 1 hour, 8 hours or 1 day), and whether it is one-time. Long grants can require the master password again (8 hours by default, configurable).
3. The approving device seals the value for the requesting session and the agent reads it with `secret_get`. A folder approval covers exactly the items that existed when it was approved; `secret_ls` lists them.
4. Grants can be extended or revoked from the grants tab, which also shows how many times each grant was read. Every read is audited.

Lifetimes are capped at 24 hours and at the account's own `max_grant_seconds` (never lower than 60 seconds). A request above the cap is trimmed to it, and the answer says so.

## Two-factor (TOTP) secrets

The seed of a TOTP secret never leaves the vault. An approval produces a grid of codes for the next five minutes, sealed for the session; each `secret_get` returns the single code valid at that instant, with `valid_until`. A TOTP grant lasts five minutes and is not extensible. TOTP is always end to end: a remote request without a public key cannot be approved for a TOTP secret.

## AI proposals

An agent that creates a credential (for example a password or an API key during a setup task) does not paste it anywhere. It calls `secret_inbox_key`, seals each value to that age recipient, and calls `secret_propose` with the armored ciphertexts, a target vault and a reason. The private half of the inbox key lives inside the vault, so the hub cannot read proposals. The owner accepts all, some or none of the items on the phone, and may grant them back to the agent if it passed its own public key. Limits: 50 items, 64 KiB per value, 20 pending proposals per account; a proposal expires after 7 days. `secret_proposal_status` reports the decision.

## Security model

- Zero knowledge for vault contents: the vault key is derived on the device from the master password; the hub stores ciphertext and cannot decrypt it.
- A human decides: nothing lets a model grant itself access. Every request waits for an approval on a signed-in device, and a proposal becomes vault content only when the owner accepts it.
- Per-session sealing: remote sessions seal with age (X25519); local-agent sessions use a per-session key whose private half stays in the MCP server's memory. A grant is unreadable to neighbouring sessions and to the hub.
- The relay between machines and devices carries control metadata only (session lists, working directories, profiles, approval prompts, metrics), never session content or secret values.
- Tokens and passwords are stored as hashes or digests; the login password as an Argon2id hash.

Honest limits:

- Metadata is visible to the hub: secret names and folder paths, reasons, client and session labels, times and read counts. Proposal item names, types and notes are readable metadata too.
- End-to-end only, no exceptions: a remote client that sends no public key is refused. The key pair is generated on the client (`age-keygen -o <0600 file> 2>/dev/null` then `age-keygen -y <file>`, or `rc-agent keygen`); only the public recipient is sent, and the private key must never be printed or pasted into a chat.
- The machine that receives a secret holds it: whoever controls that machine during an active grant can read it. Short lifetimes and one-time grants shrink that window.
- A value delivered in plain form enters the model's context. The local agent's file mode keeps it out; remote tools instruct the agent to decrypt straight into a file or environment variable and never display it.
- Losing the master password means losing the vault: the hub cannot recover it.

## MCP tools

- `secret_request`: ask the account owner for a secret or a folder of secrets. Does not return the secret; returns a request_id and the delivery mode (always e2e). Requires `public_key`.
- `secret_ls`: list the names an approved request covers, with each item's kind and expiry. Names only.
- `secret_get`: read one item of an approved request. Returns `sealed` (armored age payload for the request's public key), or a file path in the local agent's file mode.
- `secret_inbox_key`: the account inbox public key (age recipient) for sealing proposals.
- `secret_propose`: propose sealed items for a vault; the owner reviews them on the phone.
- `secret_proposal_status`: pending, accepted (with the stored names and vault), rejected or expired.
- `system_status` (local agent only): CPU, memory, swap, load, disks and temperature, with 5, 15 and 60 minute averages.

## Connecting a client

Remote (nothing to install): add `https://ai-hub.rc.center/mcp` as a remote (streamable HTTP) MCP server in Claude Code, claude.ai, Cursor, VS Code or another MCP client with OAuth support. The client registers itself (OAuth dynamic client registration, PKCE S256), you sign in and approve the connection on the panel's consent page, and you can revoke it later from the devices list. For example, in Claude Code:

    claude mcp add --transport http ai-hub https://ai-hub.rc.center/mcp

Local (hardened): install `rc-agent`, pair the machine from the panel or the app, and register your CLI profiles. The agent registers its secrets MCP server in the profiles it runs, so its sessions can ask for secrets without further setup.

## Example session (illustrative values, no real secrets)

    # The agent creates a throwaway key for this session, outside the repo,
    # without ever printing the private key; only the recipient is shown
    $ mkdir -p -m 700 ~/.rc-center && (umask 077; age-keygen -o ~/.rc-center/session-key.txt 2>/dev/null)
    $ age-keygen -y ~/.rc-center/session-key.txt
    age1examplexxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

    -> secret_request {"name": "staging/deploy/DB_URL",
                       "reason": "run the staging migration",
                       "public_key": "age1examplexxxx..."}
    <- {"request_id": "3f2c...", "status": "pending", "mode": "e2e",
        "instruction": "Ask the user to approve this request on their device, then call secret_get ..."}

    (the owner approves on the phone: 15 minutes, one-time)

    -> secret_get {"request_id": "3f2c..."}
    <- {"status": "granted", "secret_name": "staging/deploy/DB_URL", "mode": "e2e",
        "sealed": "-----BEGIN AGE ENCRYPTED FILE-----\n...\n-----END AGE ENCRYPTED FILE-----"}

    # Decrypt straight into the destination, never to the terminal
    $ age -d -i ~/.rc-center/session-key.txt sealed.age > .env.staging

    # When the task is done
    $ shred -u ~/.rc-center/session-key.txt

## Pages

- Product page: https://ai-hub.rc.center/ (pt-BR: https://ai-hub.rc.center/?lang=pt-BR)
- Web panel: https://ai-hub.rc.center/login
- Android app (Google Play): https://play.google.com/store/apps/details?id=center.rc.aihub
- Local agent: https://ai-hub.rc.center/local-agent
- Privacy policy: https://ai-hub.rc.center/privacy
- Terms of service: https://ai-hub.rc.center/terms
- Delete your account: https://ai-hub.rc.center/delete-account
- rc.center home: https://rc.center/
- Contact: contact@zodo.dev