olOpsLyft Docs

Access keys

Create a key for the OpsLyft API or an MCP client, choose what it can reach, and revoke it.

An access key (also called an API token) lets a script, an integration, or an AI client such as Claude call OpsLyft without signing in. You give each key its own access when you create it, and every key has an end date.

Keys look like this:

olt_1a2b3c4d_kQ9vX2mR7tYp…

The first part, olt_1a2b3c4d, is the key's prefix. OpsLyft shows it in the key list so you can tell keys apart. The full key is shown only once, when you create it.

Who can create keys

You need permission to create tokens. With the built-in roles:

RoleCreate your own keysSee and revoke everyone's keys
OwnerYesYes
AdminYesYes
FinOps managerYesNo
EngineerYesNo
ViewerNoNo

Custom roles can include either permission. See People and workspaces.

Create a key

Open MCP & Access Keys

Select your avatar, then Settings → MCP & Access Keys, and select Create token.

Name it

Use a name that says what the key is for, such as nightly cost export or Claude Desktop – Priya. Names can be up to 60 characters.

Choose when it ends

Pick In 30 days, In 90 days (the default), In 180 days, In 365 days, or On a date…. Every key must end within a year. A preset ends at 23:59 on that day, in your time zone.

Give it access

Add one or more grants. Each grant is a role and a scope:

  • Role sets what the key can do, for example Viewer for read-only access. Any built-in or custom role except Owner.
  • Scope sets which spend the role applies to: All spend, or Only some providers and accounts, where you pick whole providers or specific accounts.

Select Add a grant to combine several, for example Engineer on one AWS account and Viewer on everything else.

Copy the key

Select Create token, then Copy. This is the only time the key is shown, so store it somewhere safe, such as a secrets manager. The same screen shows ready-made MCP client configs with your key already filled in. See MCP.

Shown once

OpsLyft stores only a hash of the key, so nobody, including OpsLyft support, can show it to you again. If you lose it, revoke it and create a new one.

What a key can access

A key has only the grants you gave it. It doesn't follow your role: if your role changes later, your existing keys keep the access they were created with.

A few rules keep keys safe:

  • No more than you hold. You can't give a key access you don't have yourself on that scope. OpsLyft checks this when you create the key.
  • Never Owner. A key can't hold the Owner role.
  • Never administration. Whatever its role, a key can't invite or manage people, teams, roles, owners, SSO, or billing, and it can't create or manage keys.
  • One organisation. A key works only in the organisation it was created in.
  • Only enabled modules. A key can only use modules your organisation has turned on.

Roles at a glance

RoleWhat a key with this role can do
AdminFull access to every module
FinOps managerFull access to every module
EngineerWork with cost data, canvases, Atlas, anomalies, tickets, and datasets; view budgets
ViewerRead-only access to every module

Allocations need Admin

The MCP tools that read and change allocations (Dimension Studio) need a key with Admin on all spend.

Use a key

Send the key in a header on every request.

WhereHeader
OpsLyft APIAuthorization: Bearer olt_…
MCPX-Opslyft-Key: olt_… (or Authorization: Bearer olt_…)

Manage keys

The key list shows each key's Name and prefix, its Access, when it Ends, and when it was Last used. Keys ending within 14 days show a countdown.

Owners and Admins can switch between Your tokens and Everyone's to see every key in the organisation.

Revoke a key

Select Revoke on the key, then Revoke token. Anything using the key stops working straight away, and this can't be undone. You can revoke your own keys; Owners and Admins can revoke anyone's.

Expired and revoked keys move to Expired and revoked at the bottom of the list.

Replace a key

Keys can't be edited, extended, or rotated. To change a key's access or end date, create a new key, switch your script or client to it, then revoke the old one.

When people leave

  • Removed from the organisation: all their keys are revoked.
  • Suspended: their keys stop working while they're suspended.

Good practice

  • Create one key per script or person, so you can revoke one without breaking others.
  • Give the smallest role and scope that does the job. Viewer is enough for reading cost.
  • Choose the shortest end date that works, and put a reminder in your calendar to replace it.
  • Keep keys in a secrets manager or environment variable, never in source code.
  • Check Last used now and then, and revoke keys nobody uses.

On this page