Vault

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.

Access model

Manage secrets from the console (Secrets > Vault in the Authdog console) or from the public Vault API.

Public API

The Vault API is environment-scoped and authenticated with an environment API secret (adenv_…), the same credential family used by the AuthZEN and FGA APIs. The environment is resolved from the token, so no tenant or environment id appears in the path.

# Store a secret
curl -X PUT https://api.authdog.com/vault/v1/secrets/STRIPE_KEY \
  -H "Authorization: Bearer $AUTHDOG_ENV_API_SECRET" \
  -H "Content-Type: application/json" \
  -d '{ "value": "sk_live_…", "description": "billing" }'

# Read it back (records a READ access-log entry)
curl https://api.authdog.com/vault/v1/secrets/STRIPE_KEY \
  -H "Authorization: Bearer $AUTHDOG_ENV_API_SECRET"
# → { "name": "STRIPE_KEY", "value": "sk_live_…", ... }

List responses redact value; only a single-secret read returns it, and every read is recorded in the secret access log.

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. "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 raw key is shown once on creation for offline backup; the platform keeps a wrapped copy for server-side use.
• RSA-OAEP-4096 keypairs can be generated. The private key is wrapped at rest with the platform master secret and never leaves Authdog; the PEM-encoded public key is returned on creation so encryptors can use it. Encrypt a short payload against the public key with kmsEncrypt and recover it server-side with kmsDecrypt.
• The KMS UI designates a default for new encrypted material and records a key's rotation state.
• Disabling a key still in use can make existing ciphertext unavailable.

The Vault write path uses service-managed encryption configuration; it does not bind an individual entry to a selected KMS key, and changing the KMS default does not re-encrypt existing entries.

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 after create, update, or delete operations.

Related

• API
• Deployments
• Security
• Audit logs