Skip to main content
Vault binding is the Ultraviolet-tier credential brokering path. Once configured, every approved intent token causes Vault to mint a short-lived database credential whose TTL is bounded by the intent token’s TTL — so the credential expires when the work is done, not when an operator remembers to rotate it.
Vault binding requires the Ultraviolet tier and the HashiCorp Vault Database secrets engine. See Tier comparison for what each tier unlocks.

Why it matters

Without Vault binding, your application holds a long-lived database password. Every leaked password = forever-valid access. With Vault binding, the password’s lifetime is the intent token’s lifetime — typically 5 minutes — and is scoped to the columns the purpose declared.

1. Enable the database engine in Vault

vault secrets enable -path=database database

vault write database/config/inviolet-postgres \
  plugin_name=postgresql-database-plugin \
  allowed_roles="inviolet-*" \
  connection_url="postgresql://{{username}}:{{password}}@db.example.com:5432/postgres" \
  username="vault_admin" \
  password="${VAULT_DB_ADMIN_PASSWORD}"

2. Create a role per purpose

Each purpose Inviolet manages gets a Vault role. The role’s SQL grants match the purpose’s elements allowlist.
vault write database/roles/inviolet-customer-support-lookup \
  db_name=inviolet-postgres \
  creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; \
    GRANT SELECT (id, name, email) ON customers TO \"{{name}}\";" \
  default_ttl="5m" \
  max_ttl="15m"

3. Wire Inviolet → Vault

App dashboard → Settings → Credential Brokers → Add Vault. Provide:
  • Vault address (e.g., https://vault.example.com:8200)
  • AppRole role_id + secret_id
  • Path prefix (database/creds/inviolet-*)
Inviolet performs a test mint and confirms the credential is revocable.

4. Bind to a purpose

For each purpose, Settings → Purposes → pick → Credentials → Bind to Vault role. Pick the matching Vault role.

5. Verify

Trigger a tool call that matches the purpose. The decision-feed entry will now include a credential.vault_lease_id field. Run vault read database/creds/... to confirm it’s a fresh short-lived credential, not the long-lived one your app used to hold.