Onboard developers and issue keys

Once models and providers are provisioned, the next operator task is to make the platform reachable to the people who will actually consume it. In small deployments this is a manageable thing to do one user at a time; in larger ones, it becomes the recurring background work of running the platform: new joiners, leavers, role changes, and the occasional emergency revocation. The Admin Dashboard makes both ends of that spectrum tractable through two surfaces: Users, a platform-wide view of registered accounts and their roles, and API Keys, a platform-wide view of every API key regardless of which user issued it. This guide covers the typical onboarding flow, the role model that governs what each user can do, the developer-side counterpart of API key issuance, and the recurring operational work of identifying stale keys and revoking compromised ones.

---

Persona: Platform operator working in the Admin Dashboard, with occasional excursions into the Console.

Estimated time: 10--20 minutes for a single onboarding pass; ongoing thereafter.

When this guide applies

This guide is the right place to start in any of these situations:

Situation	What it covers
A new developer or team needs platform access	User registration confirmation, role assignment, and an initial API key
A developer has changed role and now needs admin access (or has lost it)	Role assignment through the Users surface
An API key has been leaked or is suspected to be compromised	Immediate platform-wide revocation through the Admin API Keys surface
Periodic security hygiene, identifying keys that have not been used in months	The Last Used filter and platform-wide sort on the API Keys surface
A leaver needs to have every credential they hold removed	The combination of user-level audit and per-user API key filter

For self-service key creation by individual developers, the most common day-to-day onboarding pattern once an account exists, the Console's own API Keys page is the right surface, and developers manage it themselves. This guide covers the administrative side of the same activity.

Outcomes

By the end of this guide:

• The Users surface has been opened, exercised, and at least one user's role has been reviewed or changed.
• The platform-wide API Keys view has been used to locate keys by owner and status.
• The mechanics of revocation are understood, including what changes from the developer's perspective when their key stops authenticating.
• The relationship between SSO-driven role mapping and manual role edits is clear, so the two are not used in conflict.

Prerequisites

• Administrator access to the Admin Dashboard, typically the super_admin or user_admin role.
• For SSO-managed deployments, the SSO and role-mapping configuration is already in place. See Configure Single Sign-On and the SSO role mapping guide for the foundational setup.
• For non-SSO deployments, an out-of-band registration channel exists so that new users can land in the platform's user table in the first place.

Step 1: confirm the user is registered

The Users surface is the operator-side ledger of who exists in the platform. Every account that has ever signed in through SSO, or been provisioned through whichever mechanism the deployment uses, appears here.

1. Sign in to the Admin Dashboard.

2. Open Users from the sidebar.

   

3. Review the columns surfaced for each user:

   Column	What it captures
   Name	The user's display name
   Email	The user's email address
   Role	The user's currently assigned Agent Router role
   Organization Unit	The organisational group, when configured
   Last Sign-In	The timestamp of the user's most recent authentication
   Status	Active or Inactive

4. Use the search box to find the new user by name or email. The role and status filters narrow the list when the user base has grown large. Results update in real time as the query is typed or a filter is selected.

5. If the user is missing entirely, the cause is upstream: either the user has not yet signed in for the first time (no Agent Router record exists until first sign-in), or the SSO configuration is not yet exposing them to the platform. The fix is at the identity-provider level rather than in the Admin Dashboard.

The user's first sign-in is what creates the record. Once present, the row is editable.

Clicking a user's row opens the detail view, which carries more than the list columns expose. The full profile adds the registration date alongside the name, email, role, organisation unit, and last sign-in timestamp. An activity summary on the same view reports recent API key usage and request counts. A dedicated Activity tab lists the user's recent actions (API key creation, model usage, and request history), which is the most direct way to understand an individual user's consumption patterns before a role change or an offboarding.

Step 2: assign or verify the role

The role determines what the user can see and do across the platform. The role model is intentionally small, so the assignment decision rarely takes long.

Role	Permissions
super_admin	Full platform administration: everything in the Admin Dashboard
model_admin	Manage model routes and backends
provider_admin	Manage upstream AI providers
mcp_admin	Manage MCP profiles and the MCP server catalogue
user_admin	Manage users and organisation membership
billing_admin	View and manage billing and usage
user	Console access only; standard developer permissions

To assign or change a role:

1. Click the user's row to open the detail view.
2. Click Edit Role or the role dropdown.
3. Select the new role.
4. Click Save.

The change takes effect on the user's next sign-in or next API request, depending on which surface they reach first.

important

For deployments that use SSO-driven role mapping, the role assigned by claim mapping wins on every login. Manual role edits to a user whose role is also managed by SSO mapping are not durable; the next login will overwrite the manual change to whatever the IdP claim resolves to. Manage those users' roles through the identity provider, not through the Admin Dashboard. Manual edits are appropriate only for users who are not covered by the mapping. The precedence rules are documented in the SSO role mapping guide.

Step 3: understand how developers issue their own keys

Most API keys on the platform are created by developers themselves, in the Console, against their own user record. The operator-side surface watches and governs the resulting key set rather than driving its creation.

The developer-side flow, for context:

1. The developer signs in to the Console.
2. They navigate to Settings → API Keys.
3. They click Create API Key and supply a descriptive name.
4. The full key value is displayed once. The developer copies it into a secrets manager or environment variable.
5. The key is presented at the gateway as a bearer token thereafter.

The naming convention developers adopt at this step matters operationally. A platform whose keys are named after their purpose (checkout-service-prod, rag-experiment-staging, cursor-local-john) is much easier to audit than a platform whose keys are named key1, key2, and test. Encouraging the convention through documentation and onboarding materials is more effective than enforcing it after the fact.

For the deeper developer-side reference, see Route Requests Across Providers.

Step 4: audit and revoke keys platform-wide

The Admin Dashboard's API Keys page is the platform-wide view that the Console's per-user view does not provide. Every key on the platform appears here, regardless of which user issued it.

1. Open API Keys from the sidebar.

   

2. Review the columns surfaced for each key:

   Column	What it captures
   Key Name	The descriptive name the developer chose
   Owner	The user who created the key
   Key Prefix	The first characters of the key (such as sk-...abc) for identification
   Created	The creation date
   Last Used	The timestamp of the most recent request authenticated by the key
   Status	Active or Revoked

3. Use the search box to find keys by name, owner, or key prefix, and the status and owner filters to narrow the list. Results update in real time as the query is typed or a filter is selected.

Clicking a key's row opens its detail view, which exposes the full metadata: name, owner, creation date, last used timestamp, status, and the routing configuration associated with the key. The same view carries the key's usage history, which is the quickest way to confirm recent activity before deciding whether to revoke.

The distinction between the Admin and Console views is worth keeping clear:

Feature	Admin API Keys	Console API Keys
Scope	All keys across all users	Only the signed-in user's keys
Ownership	Owner column visible	All keys belong to the current user
Actions	View and revoke any key	Create, configure, and revoke own keys
Audience	Platform administrators	Individual developers

To revoke a key:

1. Click the key's row to open its detail view.
2. Click Revoke.
3. Confirm.

The key stops authenticating immediately. Any request, in-flight or future, that presents the revoked key receives an authentication error. The revocation event is logged in the audit log; the cause and the operator who performed the revocation are visible there. See Audit Platform Activity for the audit surface.

Revocation is permanent from the key's perspective. There is no un-revoke; if the developer needs a replacement, they create a new key in the Console. This is deliberate: a revoked credential cannot be silently re-enabled.

Finding stale keys

The Last Used column makes it easy to find keys that have not been touched in a long time. A common periodic-hygiene workflow:

1. Sort the key list by Last Used in ascending order. Keys with no recent activity surface at the top.
2. Review the entries against expectations. A test key from six months ago, the credential of a leaver who has not been offboarded, or a CI key for a job that has since moved to another platform: all of these are candidates for revocation.
3. Revoke the keys that no longer have a legitimate consumer.

Stale credentials are one of the most common sources of long-term security exposure on AI platforms. The cost of revoking a key that turns out to still be needed is small; the developer creates a new one in a minute. The cost of leaving an unused key alive indefinitely is whatever the worst-case use of that credential would be.

Step 5: handle leavers

When a developer leaves the organisation, both the user record and any credentials they hold need to be deactivated. The two are independent and have to be handled separately.

1. In Users, locate the leaver's account.
2. Confirm or update their status. In an SSO-managed deployment, deactivation in the identity provider propagates on next sign-in attempt; in non-SSO deployments, the status is set directly here.
3. Switch to API Keys and filter by the leaver's email as owner.
4. Revoke each remaining key.

The order matters: revoking keys first ensures that any automated process still presenting one of those credentials is cut off, even if the user record itself is not yet fully deactivated. Doing it in the reverse order leaves a brief window in which the user is gone but their credentials are not.

What to do next

• Govern MCP server access. The parallel onboarding flow for the MCP catalogue. See Govern MCP Server Access.
• Audit platform activity. Review the events generated by the onboarding and revocation work performed in this guide. See Audit Platform Activity.
• Working with budgets. Attach spending limits to the keys issued through this flow. See Working with Budgets.

The user records and API keys handled in this guide remain in place for subsequent guides.

---

Where to go next

Govern MCP server access

The parallel onboarding flow for the MCP server catalogue.

Working with budgets

Attach spending limits to the keys issued through this flow.