Teams & access

Who can see what, who can run what, who can approve what — and how to narrow any of it down to specific runners. emisar's access model has two dials: the member's role and optional per-member runner scopes. An API key an LLM connects with carries no scope of its own — it inherits its owner's, so scoping the person scopes their agent.

emisar console · Team

Expand

Roles#

Four ordered roles plus one specialist seat. Authorization is permission-based under the hood, so this table is the contract:

Inviting your team#

Team → Invite: enter an email, pick the role, send. The invite link is a one-time token (hashed at rest like every credential here); accepting it creates the membership at the role you chose. Granting the owner role requires an owner — admins invite up to their own level. Members can be suspended (sessions killed immediately, sign-in blocked) and unsuspended without losing their history.

Per-member runner scopes#

Roles answer what someone can do; runner scopes answer where. The owner who created the account sees every runner; everyone you invite — and everyone provisioned through SSO — starts with no runner access and is granted up. Add scopes on the member's team page and they see the union of what you list:

• — Group scope — group: cassandra-prod. Follows the group: new runners joining it are automatically in scope.
• — Runner scope — one specific host, for the contractor who should touch exactly one box.

Scoping is treated as existence-hiding, not just permission-denying: out-of-scope runners don't appear in lists, their detail pages 404, and their actions vanish from the member's dispatch surface. An API key inherits its owner's scope, so "the DBA's agent only reaches cassandra-*" falls out of scoping the DBA — not a policy convention, and not a per-key setting to keep in sync. Scope changes are audited.

MFA#

TOTP (any standard authenticator app) with one-time recovery codes — codes are shown once, stored hashed, and each works exactly once. Replayed TOTP codes are rejected. Beyond self-service, an owner or admin can flip Require MFA on the account: members without MFA are routed to enrollment before they can touch anything else. On Team or Enterprise, a single sign-on session can satisfy that requirement when your IdP enforces MFA.

Sessions & credentials#

• — Profile shows every active session with device info; sign out any of them — or everywhere except the current one — in a click. Suspension and admin-forced sign-out disconnect live dashboards immediately, not at next page load.
• — Magic-link sign-in uses single-use, expiring, hashed email tokens — a browser-held nonce plus an emailed 6-character code, so an intercepted email can't sign in on its own. Sign-in is rate-limited per IP and per email, and failed attempts land in the audit log on your account, so probing is visible to admins.
• — An API key is identity + attribution — what it may run is your account policy. Keys are revocable from LLM agents; raw secrets are shown once, only hashes are stored.
• — Keys self-rotate near expiry — the client installs a successor and swaps to it with no interruption — and revoking or suspending the member who minted a key revokes it.