Skip to content

My AI Keys

The page where you request a key for the tool you actually use. Tool-first, not key-first — pick a provider from the catalogue, declare a purpose, the platform issues the key (or sends the request to an admin if production approval is needed).

This page lives at /me/ai-keys. Visible to every authenticated user.

Two sections

The page splits into two sections.

Your keys — every key the user holds. Tool, created date, last used date, status pill, and a revoke button. Status is one of ACTIVE, PENDING, REJECTED, REVOKED.

Available tools — every tool in the org's provider catalogue the user does not already have an active key for. Each row shows the tool's display name, slug, and a Requires approval badge if the org has flagged it.

The request flow

Click Request on an available tool to open the request drawer.

Three fields:

FieldWhat it controls
Environmentdevelopment, staging, or production
PurposeOne-line declaration of why you need the key — required, lands on the audit trail
(Approval banner)Renders when requiresApproval is on for the tool AND environment is production

The submit button changes label to match the path:

  • Issue key — when the request can be auto-issued. Key is created, the page renders a one-time reveal modal showing the raw value and prefix.
  • Submit request — when admin approval is needed. Key is created in PENDING state; an admin reviews at the /admin/ai/pending-keys surface.

The reveal modal is the only time the raw key value is shown. Copy it immediately and keep it in your secrets manager. If you lose it, revoke and re-issue.

Why production needs approval

Production keys are bound to long-lived infrastructure — a deploy script, a customer-facing inference job, a CI runner. They should be reviewed because:

  • The traffic they generate authenticates as the user's principal but acts on behalf of a system.
  • Their lifecycle is much longer than a developer's quick experimentation key.
  • Their abuse blast radius is correspondingly larger.

If your org's catalogue marks a tool as requiresApproval: true, production keys for that tool can only be requested through this page — they can't be auto-issued. Development and staging keys for the same tool can still be auto-issued (the lower-blast-radius path).

The approve / reject flow (admin side)

Admins reviewing pending requests see them in Settings → AI → Pending key requests. They approve or reject; the requester sees the status pill flip on this page and (if approved) is offered the one-time key reveal.

Rejection includes a reason which lands on the requester's row.

Revoking your own keys

The trash icon on any active key revokes it immediately. There's no grace window for self-revocation — if you accidentally revoke a key in production, you have to re-issue and update wherever it was deployed. Be precise.

A revoked key shows the status pill REVOKED and the trash icon disappears. The row stays in the table for audit but stops working at the wire.

What this isn't

This page is not for service-account keys. Service accounts are admin-managed at Service accounts — they're production workloads with their own identity, separate from any human user.

It's also not for provider billing credentials. Those live at Usage providers and are admin-only.

Flowstate Documentation