Skip to main content

Issue a project-scoped API key

Enterprise Tier

An API key is the credential an application presents when it calls a gateway. Keys are created in the context of a project, so a key belongs to one project and works only against that project's gateway. This guide creates a project-scoped key and explains the isolation it carries.

Because keys are project-scoped, they are part of what keeps projects isolated from one another: a key issued for one project is refused on any other project's gateway, and it can reach only the models that project has been granted. Creating a key is done from the project context, so the project must be selected first.

Persona: Platform operator or project administrator working in the Admin Dashboard.

Estimated time: 5 minutes per key.

Outcomes​

By the end of this guide:

  • An API key exists that is scoped to a single project.
  • The key's scope is understood: it authenticates only against that project's gateway.
  • The one-time nature of the key value is understood, so it is captured securely at creation.

Prerequisites​

  • Membership of the project, with permission to create keys.
  • The project already has a gateway provisioned, so the key has an endpoint to authenticate against. See Provision a gateway for a project.

Step 1: Select the project​

  1. Use the project switcher at the top of the application to select the project the key is for, for example bedrock-team.
  2. Confirm the application has re-scoped to that project before creating the key.

Everything done in the application, including key creation, applies to the currently selected project. Selecting the wrong project produces a key that will not work against the intended gateway.

Step 2: Create the API key​

  1. Open API Keys and select Add API Key.
  2. Name the key so its purpose is recognisable later, then create it.
  3. Copy the key value immediately. It is shown once, so it must be captured at this point and stored securely.

Step 3: Understand the key's scope​

The key is bound to the project it was created in.

  • It authenticates only against that project's gateway hostname. Presented to another project's gateway, it is refused with 403.
  • It can call only the models granted to the project. A request for a model the project does not have returns 404.

This scoping is automatic and needs no extra configuration. The same isolation applies to MCP: a profile reached with a key from another project, or on another project's gateway, is refused. Organisation-wide key practices, including rotation and revocation, are covered in Onboard developers and issue keys.

What to do next​

Where to go next

Grant MCP servers and profiles to a project

Expose tools through the project, reached with this project key.

Onboard developers and issue keys

The organisation-wide view of users, roles, and key lifecycle.