Every tool call through Statio is made by someone the gateway can name. There are two kinds of someone: a person working in a client like Claude Code or Cursor, and an agent, a piece of automation with an identity of its own.
| A person | An agent | |
|---|---|---|
| Who it is | A member of your organization | A non-human principal created under Settings → Agents |
| Credential | Their sign-in, on a device enrolled by the desktop app or mcphub login | A client ID and client secret |
| Token | Bound to a key on their device, renewed by the local proxy | Lives five minutes, exchanged from the secret |
| Grants | Their own, plus their teams' | Its own, given to the agent directly |
| Shows up in Activity as | The person | The agent |
Use a person for interactive work: someone in their editor asking an AI client for help. The desktop app configures the client, the calls run as that person, and their grants decide what the client can do.
Use an agent for anything that runs without someone at the keyboard: a CI job, a scheduled task, an orchestrator, a bot. Giving automation a person's access means it acts with everything that person can do, stops working when they leave, and its calls are indistinguishable from theirs in the log. An agent fixes all three: it holds only the grants you give it, it belongs to the organization, and every call it makes is attributed to it.
Open Settings → Agents and choose New agent:
ci-deployer.Then issue a credential. The client secret is shown once, so put it straight into your secret store. Finally grant the agent the tools it needs, the same way you grant them to a person. A new agent can call nothing.
The simplest path is to let mcphub hold the credential. It keeps the secret
in the system keychain and renews the token before it expires:
mcphub serve runs the local proxy on 127.0.0.1:7777, signed in as the
agent. Point the client at http://127.0.0.1:7777/<server-name>/mcp with no
header. Prefer --client-secret-env over --client-secret: a value passed on
the command line is visible in the process list.
An agent can also exchange its credential for a token itself and send it as
Authorization: Bearer <token> to https://api.statio.dev/<server-name>/mcp.
The token expires after five minutes, so anything long-running should use
mcphub serve instead of a fixed header.
An agent can hold two active credentials at once, so rotation needs no downtime: issue a new credential, move the agent over to it, then revoke the old one. A third cannot be issued until one of the two is revoked.
| Action | What it does | Reversible |
|---|---|---|
| Suspend | The agent stops working until you resume it | Yes, Resume |
| Revoke a credential | That client ID stops working; the agent and its other credential carry on | No |
| Revoke the agent | The agent is retired for good | No |
| Expiry | An agent with an expiry date stops working after it | No |
Grant decisions are cached for up to 15 seconds and an agent's token lives five minutes, so suspending or revoking takes effect within that window, not a day later.
If the accountable member can no longer be accountable (they left the organization, for instance), the agent is frozen and shows Needs attestation. It cannot call tools until someone names a new accountable member with Re-attest. An agent is never left running with nobody responsible for it.
API keys, under Settings → API Keys, automate the control plane: deploys, the registry API, CI pipelines that ship servers. The gateway refuses them on tool calls with "API keys cannot call tools".
A key acts as the person who created it, with every grant that person holds. Using one to call tools would bring back exactly the problem Statio removes: one broad credential, shared by whatever holds it, with calls that look like a person's in the log. For automation that calls tools, create an agent.