# API keys and identity binding

Create a scoped runtime credential and manage its binding and revocation.

Updated: 2026-09-22

Canonical: https://docs.kastra.ai/admin/api-keys

## Choose an environment

Open Connections → API keys in the console and select the intended environment. An administrator can create a named key, set available expiry options, and configure a supported identity binding. Record its purpose and owner before giving it to a server application.

Copy the newly issued secret into your server's secret store. Subsequent listing and account-connector output show key metadata, not a recoverable plaintext credential. Do not place the key in browser JavaScript, a repository, or a public example.

## Bind a trusted scope

The backend supports customer, principal, and agent bindings. An agent binding must refer to a valid agent with compatible principal information. Inspect the resulting binding before relying on it for authorization or usage attribution. A display label and an independently authenticated identity are different things.

[Agent inventory](https://docs.kastra.ai/admin/agents) · [Policy attributes](https://docs.kastra.ai/reference/policy-attributes)

## Verify a key

Use a harmless evaluation in the selected environment and confirm the result and recorded scope. Test the intended binding using the actual integration. An API key authenticates runtime access; it is not a human approver.

## Rotate or revoke

To rotate operationally, create a replacement, update the authorized server, verify it, then revoke the retired key. Revocation is an administrator action. Test the expected authentication failure without bypassing policy using a provider key directly.

Customer management routes live under `/api/v1/api-keys`; creation, binding changes, and revocation require administrator authority. Runtime usage follows [authentication](https://docs.kastra.ai/start/authentication).