TigerTrust Secrets Manager (SM) is a Vault-compatible engine that runs inside the platform — there is no separate server binary to deploy. On the host side you install a CLI for humans and an agent for workloads.
Unlike CLM (one agent) or PAM (four binaries), SM’s server side lives in the TigerTrust backend. On the client side you install the tt CLI, the SM agent (for templating), or you point existing Vault-compatible tooling at the compat endpoint.

What ships

ComponentRuns onPurpose
SM engineTigerTrust backendKV, transit, PKI, database dynamic secrets, wrapping
tt secretsAny workstation or CI runnerFirst-class SM CLI
vault (or any Vault-compatible client)AnywhereWorks against /v1/* compat endpoints
tt-secrets-agentAny host / podRenders secrets into files via templates, handles lease renewal

1. Install the tt CLI

brew install tigertrust/tap/tt
tt login
tt secrets --help
Log in and set the workspace:
tt login --api=https://api.tigertrust.io
tt workspace use wsp_xxx

# Common operations
tt secrets read secret/prod/db/password
tt secrets write secret/prod/db/password value=@password.txt
tt secrets list secret/prod
tt secrets rotate database/roles/prod-postgres

2. Use existing Vault-compatible tooling

The backend exposes a Vault-compatible surface at /v1/*. Everything you know (vault kv get, vault write, vault token create, vault agent) works against it — set the address and a workspace-scoped token.
export VAULT_ADDR=https://api.tigertrust.io
export VAULT_TOKEN=$(tt tokens issue --ttl=1h)

vault kv get secret/prod/db/password
vault write database/creds/prod-postgres     # dynamic short-lived creds
vault write pki/issue/web-server common_name=web.example.com
Supported v1 paths cover KV v1/v2, transit, PKI, database, AppRole, wrapping, and the standard sys/* endpoints (sys/mounts, sys/policy, sys/health, sys/wrapping/*).

3. Install the SM agent (tt-secrets-agent)

The SM agent runs alongside a workload and renders secrets to files or environment variables — the workload never needs to know about SM. It handles token/lease renewal, template re-rendering on secret change, and signalling the child process.
curl -sSf https://releases.tigertrust.io/tigertrust-sm/agent | \
  TT_API_URL=https://api.tigertrust.io \
  TT_APPROLE_ROLE_ID=... \
  TT_APPROLE_SECRET_ID=... \
  sh
sudo systemctl enable --now tt-secrets-agent
Example template (/etc/tt/templates/db.env.tpl):
DATABASE_URL=postgres://{{ with secret "database/creds/prod-postgres" }}{{ .Data.username }}:{{ .Data.password }}{{ end }}@db.internal:5432/app
The agent renews the lease before it expires and re-renders the template when the secret changes.

4. Auth methods on the client side

Which auth method you use depends on where the client runs:
WhereRecommended authCLI flag / env
Developer laptopBrowser OIDC logintt login
CI runner (GitHub Actions, GitLab CI)JWT / OIDC federationtt login --method=jwt --jwt-token=$TOKEN
Kubernetes podServiceAccount JWTtt login --method=kubernetes --role=my-role
Generic Linux hostAppRoleVAULT_ROLE_ID, VAULT_SECRET_ID
Cloud VMCloud IAM (AWS/Azure/GCP)tt login --method=aws
Configure the auth method under Settings → Secrets Manager → Auth Methods.

SM overview

Engines, secrets, leases, and the compat surface.

Rotation policies

Scheduled rotation for KV values and database roles.

Policies

Vault-syntax HCL policies scoped to the workspace.

Access methods

OIDC, JWT, AppRole, Kubernetes, cloud IAM.