People & access
People & access is the hub for everything identity-related — who can use the instance, how they're grouped, what they're allowed to do, and which machines can call the API on their behalf. Five sub-pages live under this hub; this page explains how they fit together.
What this page is for
The admin nav used to be a flat list of a dozen pages. It’s now grouped into five hubs — People & access is one of them. Opening /admin/people lands you on a card grid with five entries: Users, Teams, Access Rules, Service Accounts, and License. Each card jumps to a focused dashboard page. This page is the index for the hub and explains when to reach for which area.
The five areas
| Area | What it does | When to use it | Full reference |
|---|---|---|---|
| Users | Create, edit, invite, deactivate, and delete individual user accounts | Onboarding someone new, changing a role, rotating a password | Users & teams |
| Teams | Group users for project and budget scoping | Carving separate working groups inside one instance | Users & teams |
| Access Rules | Path- and URL-based allow/deny policies for agent tool calls | Keeping agents off sensitive file paths or blocking them from specific domains | Dashboard only |
| Service Accounts | Programmatic API tokens for automation | Wiring external systems (CI, webhooks, scripts) to call the Exolvra API | Dashboard only |
| License | Activate a license key and track seat usage | First-time activation, tier upgrades, checking expiry | Licensing |
Users, Teams, and License have dedicated reference pages in this docs section. Access Rules and Service Accounts are configured from the dashboard directly — the paragraphs below are the orientation for each.
Access rules, in one paragraph
Access rules are allowlists and denylists that apply to every agent’s tool calls. Rules are defined at two levels: path rules restrict which directories the file system tool can touch, and URL rules restrict which domains the web fetch and browser tools can reach. Rules are evaluated on every tool call — a blocked path is not negotiable by the agent. Use them when you want a deployment-wide floor below which no agent, even a temporarily privileged one, can dig.
Service accounts, in one paragraph
Service accounts are named API tokens. Unlike personal API keys minted from a user’s Profile page, service account tokens have no user behind them — they’re identities in their own right, with their own role, their own audit trail, and their own rate limits. Create them for anything that calls Exolvra on a schedule: a CI job that posts issues, a webhook receiver that forwards messages, an external cron that triggers workflows. Rotate them regularly; revoke on any hint of compromise.
Common pitfalls
Using personal API keys for automation. Personal keys tie their audit entries to a human and revoke when that human leaves the org. Service accounts are the right choice for anything durable.
Forgetting to set access rules before public exposure. An instance exposed to the internet — even behind auth — benefits from path rules that forbid agents from ever reading the home directory or writing outside project folders. Set them before the first external request hits Exolvra.
Confusing teams with projects. A team is a namespace for users; a project is a workspace for work. A team contains users; a project contains issues, agents, and data. Users belong to teams; projects belong to a team (or none, making them personal). Getting this backwards is a common first-week stumbling block.
Where to go next
- Users & teams — the deep reference on identity
- Licensing — tier features, seat limits, activation
- Security & cloud mode — the capability model that layers on top of access rules
- Admin overview — all six hubs at a glance