Use case · Credential Vault
The agent calls the tool. The secret never leaves the vault.
Credentials are injected server-side at call time — nothing to leak, paste, or commit.
The problem
An agent that holds a credential holds all of its power — and today, agents hold credentials everywhere.
01
Raw keys in .env files, prompts, and configs
02
A prompt-injected agent is a leaked key
03
Every laptop is a place the password lives
04
Nobody can find them all to rotate them
How a secret stays put
Store
Secrets go in the vault
OAuth tokens and API keys live in one encrypted place — not in .env files.
Call
The agent makes a bare call
No credential in the prompt, the code, or the config.
Inject
Fabriq attaches the secret
Server-side, at call time — the agent sees results, never tokens.
Cut
Disconnect kills the grant
Removing a connection deletes its token; nothing runs on a stale grant.
See it
ap-bot-01
holds: nothing
⬡ Agentic Fabriqvault · tokens & secrets
NetSuite
sees: a signed call
THE CREDENTIAL IS INJECTED SERVER-SIDE AT CALL TIME — THE AGENT NEVER HOLDS IT
Capabilities
What you get
01
Call-time injection, server-side.
The credential attaches on Fabriq’s side; the agent sees results, never secrets.
02
Auto-refresh before expiry.
Tokens renew themselves, so workflows never stall on auth.
03
Disconnect cuts access at the vault.
Removing a connection deletes its token — nothing runs on a stale grant.
04
Last-used tracking.
Stale credentials are visible, so they get retired instead of forgotten.
05
Nothing to paste or commit.
No key in the prompt, the code, or the repo — the agent never had one.
06
Every use is on the record.
Each call a credential powers lands in the audit trail with both identities attached.
The payoff
A compromised agent stops being a compromised credential.
Questions
Common questions
Related solutions