Tool Credentials
The encrypted upstream-credential vault Interven uses when forwarding inbound-route traffic — rotate and revoke per-route.
When you set up an inbound route for a SaaS agent, the upstream credential (the real Bearer token, API key, or signed-request secret that calls your real backend) lives in Interven's encrypted tool credential vault.
The SaaS agent never sees the credential — Interven injects it on the way out.
This page covers managing those credentials independently from the routes that use them. If you only manage them inline when creating a route, you may never need to visit this page directly.
The list view
/tool-credentials
| Column | Notes |
|---|---|
| Name | Human-readable label |
| Type | bearer · header_set · oauth_static · aws_sigv4 |
| Used by | Number of inbound routes attached |
| Last rotated | Days since the value was last updated |
| Created by | Operator + timestamp |
| Actions | View metadata · Rotate · Revoke |
Filter by type, by which routes reference them, or by rotation staleness.
Credential types
| Type | What it stores |
|---|---|
bearer | A single Authorization: Bearer <token> value |
header_set | An arbitrary map of headers — e.g. X-API-Key, plus X-Internal-Auth |
oauth_static | An OAuth client_id + client_secret pair for client-credentials flow |
aws_sigv4 | An AWS access key + secret used to SigV4-sign the outbound request |
Only the metadata is shown in the UI after save. The value can be rotated but never read back.
At-rest encryption
- Each credential is encrypted with AES-256-GCM.
- Encryption key is
INTERVEN_CREDENTIAL_ENCRYPTION_KEY— a per-tenant 32-byte secret. - On hosted Interven, that key lives in our infrastructure secrets manager and rotates independently of customer action.
- On self-hosted, you generate and store the key (
openssl rand -hex 32). Back it up separately from the database; losing it means losing all stored credentials.
Rotation
/tool-credentials/<id> → Rotate
Enter the new value. Save. The old value is purged from active config immediately and the next outbound forward uses the new one. All existing inbound routes that reference this credential pick up the new value with zero downtime — no route edits needed.
Revocation
/tool-credentials/<id> → Revoke
Removes the credential entirely. Any inbound routes that reference it stop forwarding (HTTP 502 from the route) until you attach a replacement.
For graceful cutover, create the replacement credential first, point routes at it, then revoke the old one.
Audit
Every credential operation writes an audit row visible in Settings → Audit Log:
- Created (by whom, when, for which routes)
- Rotated (without revealing old or new value)
- Revoked (by whom, when, affected routes)
- Used (aggregate — count of outbound forwards per route per day)
API access
GET /v1/tool-credentials— list (metadata only, no secret values)POST /v1/tool-credentials— create (value supplied once, never returned)POST /v1/tool-credentials/{id}/rotate— rotate the valueDELETE /v1/tool-credentials/{id}— revoke
Security best practices
- One credential per upstream / environment. Don't share a "production Slack" credential across dev + prod inbound routes — separate them so a dev key leak doesn't compromise prod.
- Rotate quarterly minimum — and immediately on personnel change, on any suspected credential exposure, or on any incident-resolution requiring rotation.
- Use route-level allowed-path patterns (Inbound Routes) to constrain what an attached credential can be used for.