Skip to main content
Access Keys replace the old idea of a single API key per provider. Instead of wrapping a raw LLM provider credential, an Access Key is scoped to the AI Agents and Prompts a client application is allowed to call, within a specific Environment. The underlying provider connection is configured separately at the organization level — the key itself only carries scope, not provider secrets. You can manage Access Keys from the Access Keys page within a project.

​
Creating an Access Key

Generating a key is a guided, multi-step flow:
  1. Key Info — name the key, optionally describe what it’s for, choose the Environment it belongs to, and optionally set an expiry date.
  2. AI Agent Access — scope the key to all agents (including agents created later) or to a specific set of agents.
  3. Prompt Access — scope the key to all prompts or to a specific set of prompts.
  4. Review & Generate — confirm your selections and generate the key.
The key value is shown only once, immediately after generation. Copy and store it securely — Gegentic cannot show you the full value again.

​
Editing an Access Key

You can update a key’s name, description, and expiry date, and change its AI Agent and Prompt scope after creation. The Environment a key is issued for cannot be changed — generate a new key if you need to move to a different environment.

​
Why scope by Agent and Prompt instead of provider?

Tying a key directly to a provider credential means every key rotation, model swap, or provider change requires updating client applications. Scoping keys to AI Agents and Prompts instead means:
  • Swapping an agent’s underlying provider or model has no effect on which keys can call it
  • A single key can be issued to a client app that should only ever reach a defined subset of agents and prompts
  • Revoking or expiring a key immediately cuts off only the scoped agents/prompts, without affecting other integrations

​
Revoking a key

Keys can be marked inactive or revoked at any time from the Access Keys page. Revoked keys are kept for audit purposes but will no longer authenticate requests.