Retrieval keys

A retrieval key grants read access to saved configuration for one prompt. It does not edit drafts, start evaluations, manage the organization, or authorize model-provider calls.

Create and store a key

An administrator opens the prompt's key controls, gives the key a name describing its consumer, and creates it. Copy the secret when shown and place it in the application's server-side secret store. Listing keys later provides metadata, not the original secret.

Use distinct keys for consumers that need independent rotation or revocation. A prompt-scoped key is not bound to one label; choose the desired selector in the retrieval request.

Creating a key through MCP returns a dashboard handoff. Open that trusted PromptLens URL to create and copy the secret in the browser. The assistant does not receive the secret in a tool response.

Rotate without interrupting a consumer

Create a replacement key, update the application's secret, and confirm it can retrieve the intended prompt and selector. Then revoke the old key. Revocation blocks subsequent requests, including cache revalidation requests that would otherwise return 304.

Do not put retrieval keys in client-side JavaScript, public repositories, screenshots, or assistant transcripts. The key belongs in the server environment alongside the retrieval URL and prompt ID.

Recover a lost creation response

Management key creation shows the secret only on the initial response. Replaying an uncertain request with the same idempotency key can return 409 secret_unavailable and nonsecret metadata for the already-created key. No duplicate key is created by that replay.

If the original secret was lost, explicitly revoke the identified key and create another with a new idempotency key. Repeatedly creating keys without tracking the existing one leaves unnecessary credentials active.

Archiving a prompt preserves retrieval access. Revoke its keys separately when you intend to stop application reads. See archive and restore.