Teams & access

Roles control what members can do. Runner and pack access limits where they can act. An API key inherits its owner's action access.

The desktop Team page with member filters, Viewer and Operator rows showing runner and pack access, and the security settings alongside the roster. — The member roster shows roles and access, with the account's security settings beside it.

Roles#

Role	Can do
Owner	Everything an admin can do, plus managing other owners and access to every runner and pack. Owner access cannot be narrowed. The last owner cannot be removed or demoted, so an account always has an owner.
Admin	The team, policies, runbooks (deleting them included), runners, pack trust, API keys, runner scopes, and billing (plan, card, invoices), plus everything the roles below can do.
Billing manager	The subscription, payment method, and invoices, plus reading the member list and billing audit events, and nothing else (no runners, policies, runbooks, approvals, or actions). This lets procurement own billing without touching infrastructure.
Operator	Dispatch actions, decide approvals, and mint their own agent keys. Within their runner and pack access they create, edit, publish, and discard runbooks. Deleting one takes an admin. They can view runners, runs, policies, and audit records, and they cannot manage the team, policies, or trust.
Viewer	Read runners, runs, approvals, runbooks, policies, and audit records. They cannot dispatch or decide anything.

Inviting your team#

Open Team → Invite, enter an email, choose a role, runner access, and pack access, and send the invitation. The invited person opens the link, enters their name, and confirms a code sent to the invited address. Confirming the code accepts the invitation and signs them in to this workspace. When the workspace requires SSO, they then sign in at the identity provider, which links that identity to the new member. The workspace's MFA requirement still applies. Only an owner can grant the owner role or manage another owner. Admins can invite and manage members up to admin.

An invitation stays bound to the address it was sent to, and only that mailbox can accept it. Resending replaces its old link. If emisar says the invitation can no longer be resent, remove that pending invitation and send a new one to the address you intend to invite.

The invite form: an email field; the role choices: owner, admin, billing manager, operator (selected), and viewer, each with a one-line description of what it can do; an Access section offering no runners (selected), all runners, or selected runners; and a Send invite button. — Each role carries a one-line description of what it can do, so the choice is made in the form.

Service accounts#

A service account is a member that an app connects as, such as a team bot. Use one when a connection should not belong to a person: it keeps working when people leave, and the audit log attributes its requests to the service account.

Add one from Settings → Service accounts. It has the Operator role and starts with your runner and pack access; narrow it with Actions → Edit access like any member's. It has no email address and cannot sign in, so it is never invited, never enrolls MFA, and never links an SSO identity. Only owners and admins add and manage service accounts. Giving one access, connecting an app as it, or creating its keys also needs runner and pack access that covers the service account's access.

— An app that signs in with OAuth. When the app asks you to authorize it, choose the service account under Connect as, or create a new one named after the app.
— An app that takes an API key. Choose Actions → Create API key in the service account's row. Give the app the key and the server URL that page shows.

emisar records who connected each app or created each key for a service account. When a policy doesn't allow self-approval, that person can't approve the requests the service account makes through that app or key. Another approver can, or an owner or admin can override with a reason the audit log records. Suspending or removing a service account revokes every key and connection that acts as it.

Member profiles#

A member's display name and email address belong to this workspace. They identify the person in the team, activity and audit views, and the address receives workspace notifications and sign-in codes. The address starts as the one the person was invited at or signed up with, or the one your identity provider supplied.

Edit your display name from Profile, or a teammate's from Team if your role allows it. Directory-managed names are read-only here; update them in the identity provider.

A member who signs in with an emailed code can change their own email from Profile. They confirm it's them with their authenticator or a code sent to the current address, then enter a code sent to the new address. The old address gets a notice. An address that came from your identity provider changes when its directory sync sends a new one, and admins can't change another member's email.

Per-member scope: runners and packs#

Runner and pack grants limit action permissions for admins, operators, and viewers. Set access from Actions → Edit access on Team, or map SSO/SCIM directory groups. Owners always have account-wide access; billing managers have no runner or pack access.

— A group scope follows a runner group, such as group: cassandra-prod. New runners in that group enter scope automatically.
— A runner scope grants action access to one specific host. Use it for a contractor who needs exactly one machine.

Each grant also has a pack scope: all packs by default, or an explicit list. This lets a DBA run postgres.* on database hosts without gaining shell access. A runner group alone cannot express that, because restricted packs exist on most hosts. The two scopes combine: a member can act only on runners in their runner scope, using packs in their pack scope.

Members with access to operational pages can see the workspace's runners, packs, runs, output, approvals, and runbooks. Runner and pack scope limits actions, not what they can view. An API key inherits its owner's scope, so narrowing a member to cassandra-* narrows their agent with it, with no per-key settings to update. Every scope change is audited.

An admin scoped to one group cannot act on the rest of the fleet. Owners are exempt from runner and pack scoping, but not from policy, required approvals, pack trust, suspension, or the account boundary. Nobody can edit their own access.

Promoting a member to Owner grants all runners and packs. Their connected agents inherit the wider access without reconnecting. Demoting an Owner requires choosing their new access. For a directory-managed Owner, choose Use directory role: directory sync sets both role and access, with Viewer privileges and no runner or pack access until the sync completes.

MFA#

Require MFA requires each session to prove the member's active factor before it can use the workspace. Members can use an authenticator app or a sign-in through an SSO connection configured to satisfy MFA. The Team page's Authenticator count shows local enrollment, not whether every member satisfies the account's MFA requirement. Factor setup and the SSO exemption are in Enforce account sign-in.

A member's authenticator belongs to that member in this workspace; someone in two workspaces sets up each one separately. An owner or admin can reset a teammate's authenticator from the Team page if their role allows it. They first enter their own authenticator or recovery code, or sign in again through an SSO connection that satisfies MFA. Emisar support can also reset it. A reset ends every session the member has in this workspace.

Sessions & credentials#

Suspend access blocks access to this workspace, ends the member's sessions, and revokes the membership's agent credentials and standing approvals. Restore access restores membership access, but does not restore those credentials or approvals. A manual suspension stays in place across directory sync; a directory-deactivated member must first be reactivated in the identity provider. Sign-in mechanics and session self-service are in Authentication. Key lifecycle and revocation are in Manage agents & keys.

← Previous

Authentication

Single sign-on (SSO)