> ## Documentation Index
> Fetch the complete documentation index at: https://docs.elding.app/llms.txt
> Use this file to discover all available pages before exploring further.

# The cloud vault

> Where your keys are stored, encrypted, and organized.

## Data model

<CardGroup cols={3}>
  <Card title="Workspace" icon="building">
    Your organization, with its own encryption key, members, and security settings.
  </Card>

  <Card title="Set" icon="layers">
    A group of keys for a project or environment such as `dev`, `staging`, or `prod`.
  </Card>

  <Card title="Key" icon="key">
    An API key with a name, encrypted value, authorized domain, and optional expiration.
  </Card>
</CardGroup>

## Envelope encryption

Elding uses two levels of keys:

* **KEK** (`MASTER_ENCRYPTION_KEY`): the server-side master key.
* **DEK**: a unique AES-256 key for **each workspace**, stored encrypted by the KEK.

An API key is encrypted with **AES-256-GCM** using its workspace DEK. A random IV is created
for every encryption operation, and the GCM authentication tag protects integrity.

<Note>
  If the KEK leaks, each DEK is still required to decrypt workspace data. If a DEK leaks,
  only one workspace is affected. Keys can also be rotated without re-encrypting everything.
</Note>

## Status and circuit breaker

A set can be **disabled** by marking it `INACTIVE`. Its API keys are immediately unavailable
through the CLI and the web reveal interface. This is an instant, reversible circuit breaker.

## The golden rule

<Warning>
  A key value is **never** logged, either in plaintext or in proxy logs. Only key names
  may appear.
</Warning>