Reconnecting
Restoring connection…
Reconnecting
Restoring connection…
Docs navigation
Get started
AI agents
Connect
The fleet
Operate
Day to day
When it breaks
Govern access
Team & account
Access
Identity concepts
Provider guides
Account
Manage agents & keys
Manage the agents connected to your account, and the keys behind them.
To connect a new agent, see Claude.ai, ChatGPT, or CLI agent. For bridge versions and updates, see Upgrade the MCP bridge.
Your connected agents#
Every agent that has connected appears on AI agents, grouped by the member who owns it. One row is one connection: the client it runs in, the bridge version it last reported, when it last called, and when its key expires. The list shows live connections by default.
- — The status is about the connection. A row reads dormant, idle, or never used from its own last call — and unsupported when the bridge it reported is below the version emisar supports. A rotation in flight shows as a swap pending until the successor's first call retires the old key.
- — Each row carries its own actions. View activity opens the audit trail filtered to that agent. Rotate and Revoke act on the key behind it, which is the rest of this page. Copy ID copies the key's identifier — the safe handle for a support request, since the secret is never shown again.
- — Removing an agent is revoking its key. There is no separate disconnect: the key is the connection, so revoking it ends the agent's access on its very next call.
What an agent key is#
An agent key is the credential an AI agent presents to reach emisar's tool API. It rides as
Authorization: Bearer emk-…
on every call to the MCP endpoint. Keys start with
emk-
followed by a short public identifier.
- — Shown once. The full secret appears exactly once, at creation (and again at rotation). Copy it into the client's config then — emisar keeps only the hash, so a lost key is replaced, never recovered.
- — Identity, not authority. A key is an identity, an optional expiry, and audit attribution — nothing more.
- — One key per connection. Each connected client gets its own key, so you can see and revoke agents one at a time. Cloud clients that connect over OAuth follow the same idea.
A key has no scope of its own#
An agent key carries no scope of its own — there is no per-key runner list or permission dial to set, and none to forget. What a connected agent can do is decided by two things that live on the member who minted the key, not on the key:
- — Runner access. The key can reach exactly the runners available to the member who minted it. A member is scoped to runner groups on the Team page. The key inherits that scope, and emisar resolves it from that member on every call, not once at mint time.
-
—
What it can run there.
Your account's policies and the approvals they require — the same gate a human dispatch
passes. A key authenticates as a fixed
api_clientrole. It can discover the catalog, dispatch actions, and read run state. It cannot approve its own requests or edit policy. The member role does not transfer. Owner and operator keys have the same capability.
Scoping the person also scopes their agents. To limit an agent, narrow the key owner's access on the Team page page. You do not tune keys one by one. Remove that member's access to stop every key they issued from resolving to a runner. An unbound key is never usable.
Minting a key#
Keys are minted from AI agents in the console — the same place you connect and revoke agents. Pick the client you are connecting and emisar mints a key for it on the spot. The secret drops into a pre-filled config snippet you copy into that client. Cloud clients like Claude.ai and ChatGPT do not use a pasted key. They connect over OAuth. emisar mints their backing key only after you approve the connection.
- — Minted on demand, per client. emisar mints a manual key when you open that client's snippet or approve its installer. It does not mint one earlier. The agents list therefore shows real connections only.
- — Operator and above. Connecting an agent — minting a key — needs an operator, admin, or owner role. A viewer can see the agents list but cannot mint. Operators can rotate or revoke their own keys. Admins and owners can manage any key in the account.
Rotating a key#
Rotating swaps a key's secret without downtime. From an agent's row, Rotate mints a successor. It inherits the old key's name, scope, and kind. It has a new secret and expiry. Both keys work through the overlap. The old one keeps authenticating until the successor's first successful call, which retires the old key automatically. Update the client's config with the new secret any time in that window — nothing breaks while you do.
- — Copy the new secret now. Like the original, it is shown once. If you lose it before the client swaps, rotate again.
- — You can still revoke the old key. To skip the overlap, revoke the old key by hand. Rotation keeps this option available. A predecessor the successor retired is spent, not revoked — revoke it yourself when you need it provably dead rather than merely superseded.
-
—
An OAuth-backed key does not rotate.
OAuth consent creates a non-expiring key for a Claude.ai or ChatGPT connection, and
OAuth manages its life through the refresh token. The client never receives a new
emk-secret. Reconnect the client to replace that key, or revoke it to end access. - — MCP bridge keys are short-lived and rotate themselves. The bridge rotates a key during its last seven days. It prepares and proposes a successor. It promotes the successor only after emisar confirms the exact new key. Long-running local agents keep working through the change. This needs the bridge's credential directory to be writable and persistent. OAuth tokens, arbitrary Bearer tokens, and audit-export tokens bypass local rotation state.
Revoking a key#
Revoke is the kill switch. The moment you confirm, the key is dead and the connected client is refused on its very next call. Reach for it when a key leaks, an agent misbehaves, or a connection is finished. It asks you to type the agent's name first, because it cannot be undone.
Revoking cascades: every downstream key in that key's rotation chain dies with it, and any OAuth access or refresh token backed by it stops exchanging and refreshing. That reach is what makes revoke, not rotate, the containment lever for a leak.
For a lost or stolen device, revoke everything at once: Revoke all on the member's group revokes every usable key that member owns — each connected client is refused on its next call, with the same cascade per key. It asks you to type the member's name. A member can do this for their own keys; anyone else's need an admin.
A key that suddenly returns
401
has expired, been revoked, or been retired by a successor —
Troubleshooting
walks the check.