Authdog Vault stores environment-scoped configuration values and secret material. Use it for credentials consumed by Authdog-managed workflows or workloads explicitly integrated with your Authdog environment.

## Current access model

Vault management is **console-only** today. Select the project and environment, then open **Secrets > Vault** in the [Authdog console](https://console.authdog.com). The console uses internal management GraphQL operations; they are not a supported public secret-management API. Do not automate against those operations.

Vault is separate from **API access** secrets:

- **Vault entries** hold your values, such as provider credentials, JSON, YAML, PEM, or opaque files.
- **Environment API secrets** authenticate backend calls and carry scopes such as `environment:read` or `environment:update`.

Do not paste an environment API secret into Vault as a substitute for proper workload secret storage.

## Create a secret

1. Select the correct project and environment.
2. Choose **Add new**.
3. Enter a unique name. Use `/` separators, such as `production/database/password`, for console folder organization.
4. Enter text or select a file.
5. Add an optional description and expiration date.
6. Keep **Encrypt variable** enabled for sensitive values.
7. Save and verify the intended entry appears in the selected environment.

Text mode preserves multi-line UTF-8. File mode Base64-encodes bytes before storage; consumers must Base64-decode the value to recover the original file. Names must be unique within an environment.

## Encryption behavior

Encrypted entries use AES-256-GCM authenticated encryption. The service refuses encrypted writes when the required server encryption key is missing; it does not fall back to a built-in default key. Ciphertext uses a versioned storage format so the implementation can evolve.

Authorized console reads currently decrypt and return the secret value for editing. Therefore, “encrypted” means protected at rest, not write-only. Anyone with sufficient Authdog console access to read Vault can receive plaintext. Apply least privilege to console membership and protect administrator sessions with MFA.

The console also exposes environment KMS controls:

- AES-256-GCM keys can be generated and selected as the default.
- The KMS UI designates a default for new encrypted material.
- Marking a key as rotating records its rotation state.
- Disabling a key still in use can make existing ciphertext unavailable.

The current Vault write path does not expose a public control that binds a Vault entry to a selected KMS key; it uses service-managed encryption configuration. Do not assume changing the KMS default automatically re-encrypts existing Vault entries. RSA-OAEP-4096 appears as an option, but the current console states keypair generation is not yet wired up. Treat Vault/KMS re-wrap automation and RSA KMS support as incomplete.

## Rotate a secret

A Vault update replaces the value while retaining the entry's identity and metadata. Safe rotation:

1. Create the replacement credential at the upstream provider.
2. Update the Vault value.
3. Verify the dependent workflow.
4. Revoke the old credential upstream.
5. Review audit activity.

There is no documented public API for atomic multi-secret rotation or version rollback. Coordinate changes that span several entries, and keep external recovery material where required.

## Expiration and deletion

Expiration is metadata shown by the console. Do not assume Authdog automatically rotates the value, revokes the upstream credential, or deletes an expired entry unless your integration explicitly implements that behavior.

Deletion is irreversible in the console. Confirm the environment, dependencies, and recovery plan before deleting.

## Operational guidance

- Use separate entries in every environment; never reuse production credentials in development.
- Prefer narrow credentials with provider-side scopes and expiration.
- Keep encryption enabled unless plaintext storage is an explicit, reviewed requirement.
- Never store user passwords, TOTP codes, session tokens, or private data without a defined need and retention policy.
- Record the owner and purpose in the description.
- Rotate after staff or vendor access changes.
- Review [Audit logs](/docs/audit-logs) after create, update, or delete operations.

## Related

- [API](/docs/api)
- [Deployments](/docs/deployments)
- [Security](/docs/security)
- [Audit logs](/docs/audit-logs)