Who acts here

Two kinds of actor, governed by the same organization. People first, because an agent's authority is a slice of somebody's.

Part one: the people

Three roles. The difference between them is what they may change, not what they may see.

Getting an account

Two routes in, and which ones are available depends on how your instance is configured.

1. 1

   Provisioned by an admin

   An admin adds your email under Members and chooses your role. You then sign in as yourself and land in that organization.

   The role comes from this record and nothing else. A claim in a Google or OIDC token never grants a role by itself.

2. 2

   Self sign-up

   Where enabled, an unknown Google or GitHub identity gets a new organization of its own, never membership of an existing one. A stranger with a verified address still cannot walk into somebody else's.

Sign-in

Google, and only Google. There is no password login here, by design.

Two consequences worth knowing before you roll it out:

• An unverified Google email is rejected outright, because an unverified address may belong to somebody else.
• A refused sign-in says only that it was refused. It does not say whether the account exists, so the screen cannot be used to enumerate your members.

Where sign-in has not been configured at all, the console says so rather than offering a form that cannot work.

The session

The session lives in a cookie the browser cannot read and never appears in a URL, so a redirect cannot leak it through browser history or a Referer header. Signing out ends it on the server, not only in the tab.

That is the whole of what an administrator needs from it. Everything else about how the console holds a session is an implementation detail of the control plane, and is deliberately not something you configure.

Members, grants and status

Grants scope a user to specific workspaces, the mechanism for a contractor who should see one workspace and not the rest of them. A grant names a workspace and the role held inside it, and the memories that workspace holds follow from it; there is no grant on a memory of its own.

Teams are how those grants are usually written. A team is a named group of people inside one workspace, and putting somebody on it grants them that workspace at the role you pick. Taking them off again does not take the grant back, because they may also hold it through another team or from an administrator directly, so access is removed on the member rather than on the team.

Status suspends without deleting, and suspending is the default for somebody who has left. It closes the door in one request, it is undone in one request, and the roster still names them beside what they approved.

Removing erases the account and gives the seat back. It also takes them off every workspace they were on. What they decided and approved stays in the record under their name, but there is no longer a member for that name to resolve to, and inviting them back makes a new account rather than this one. Keep it for an account that was a mistake, or a seat you need now. The last administrator of an organization cannot be removed, and nobody removes their own account from here; that is done from their own account page, which ends the session with it.

Invites

A workspace-scoped invite creates an account that only reaches it. Use it by default; org-wide access is the exception, not the starting point.

Single sign-on

Any OIDC provider works, wired once for the deployment from one issuer and one audience. There is no SCIM and no SAML: what decides who exists here is the account somebody provisioned, and a provider proves who is signing in rather than who they are allowed to be.

That is the property to understand before switching it on, because it is the opposite of how most products do this:

Offboarding is therefore an act here rather than one your IdP performs for you. Removing somebody from the directory stops them proving who they are; disabling them under Members is what ends the access.

Keep roles small and boring, and the fact that they are assigned here rather than mapped from a directory is what makes that easy. Two failure modes to avoid, and both are decisions somebody makes on this page: giving everybody reviewer, which makes approval meaningless, since approval is only worth something when the approver was chosen; and giving everybody admin, which is the same as having no roles at all, with extra steps.

SSO is a feature of the hosted control plane. The runtime itself never needed an account of any kind.

Part two: the agents

An API key says an agent exists. It does not say who answers for it, what it is for, how much it may commit the team to, or how to stop it. Those are the things a team needs before it lets software act in its name, and they are what a grant carries.

An identity here is three fields rather than one. The kind is the product it is, Claude Code or Cursor or a vendor's assistant. The role is the job it holds, release engineer or support triage. The principal is the person it acts for. Policy is written about the role, because a rule about a product is wrong the moment the team adopts a second one, and a rule about the release role survives the tool being swapped underneath it. An agent with a kind and no role and no principal is not enrolled, and it is the unmanaged category the census counts.

Everything here is the Authority gate on the workspace's control plane, which opens onto the grants themselves.

Enrolling

1. 1

   Say what it is for

   A role, and the actions it handles as namespaced verbs, such as db.migrate or deploy.release. This is what answers "which agent should handle this" when another agent finds work outside its own remit.

   Leaving it blank means the agent is never proposed for work. It does not mean it may do everything: silence about what an agent is for is not a claim about what it may do.

2. 2

   Name who answers for it

   The owner is the person accountable when it misbehaves. Deliberately three different people in the general case: its principal is who it acts for, createdBy is whoever ran the mint, and the owner is who you call.

   You need that distinction the first time an agent surprises you at 3am and the person who set it up left.

3. 3

   Set what it may commit alone

   A spend limit is enforced, unlike the written restrictions below it. Anything larger comes back needing a person even where no rule forbids it.

   An action that will not say how big it is does not pass a ceiling: an agent with a limit could otherwise clear any amount by omitting it.

4. 4

   Decide how much it is told

   The clearance, and the audiences it reaches. Separate from everything above, because what an agent may do and what it may know are two decisions. Restricted material never reaches a machine whatever you set.

An agent may not out-read the person it acts for

A grant naming a principal is narrowed to them: the lower ceiling, and only the audiences they are both in. An admin who grants an agent reach into Legal while its principal sits in Finance has granted nothing.

This is what makes delegated authority mean something. Alice approving fifty thousand does not make Alice's assistant able to.

Temporary authority

"Let this agent read the financial report for the next two hours" is a different grant from a standing one, and the difference has to be enforced rather than remembered. Set an expiry and the authority lapses on its own.

Stopping one

Two different acts, and the console offers both because they are different decisions.

Two more reach past one credential to every machine the agent runs on. Both are in the console, on an incident under Contain it, and in the team's chat, where they are slash commands rather than anything the CLI runs:

Halting keeps the credential and everything the agent has asked. That is deliberate: the investigation into what it did needs to know which agent asked what, and destroying that to stop it would trade the evidence for the containment. A halt requires a reason, and the reason is shown to whoever lifts it.

Knowing what you are running

The agent list says why each one is silent rather than leaving you to work it out from three fields:

A halted or lapsed agent stays in the list. An agent that has quietly stopped doing its work while looking healthy is the failure this view exists to prevent.

Every agent has somebody who answers for it. Until an admin names owners on the agent's page, the owner is whoever owns the machine it enrolled from, and the page says the name was taken from there. An owner has to be an active member of the team, because an owner nobody can reach is the same as no owner. Who changed it and when stays in the record.

Which agents can reach production is asked of the API by tag rather than by resource, with no screen for it: GET :ws/reach?tag=production lists every agent that can effectively touch anything carrying a confirmed tag, with the path by which it can and the machines it runs on. The same question can be asked of one exact resource (?resource=) or of a class of reach (?class=). An agent's own page still lists what it reaches.

Spend per agent is counted on its own and read from GET :ws/spend/agents, with no screen to watch. Memnox prices nothing: the cost is only what an agent reported spending on its own actions, so an agent that reports nothing is shown as unknown rather than as free, and a total is only as complete as the agents that report.

Retiring

Revoking takes effect on the agent's next question. What it has already been told is not recalled, since nothing can un-tell it, but it asks nothing further, and it stops being offered as somewhere to route work.

The ledger survives. "Which agent did this, on whose behalf, and what was it told" has to stay answerable after the agent is gone, which is the whole point of keeping the record separate from the credential.