Use case / credential safety
Use API keys without putting them in chat, code, or .env
Trusty Squire stores generated credentials, injects them into provider requests server-side, and can give deployed apps scoped access you can revoke.
Ask for the outcome
“Sign me up for Resend and save the API key.”
“Let my deployed app call OpenAI without giving it the OpenAI key.”
“That app token leaked. Revoke its access now.”
How it works
- 01
Capture the generated credential
When a website shows an API key or client secret, Trusty Squire stores it directly or holds it in a sealed slot for the current setup flow.
- 02
Keep raw values out of credential tools
The agent can list and use saved credentials, but those tool results do not return the stored plaintext value.
- 03
Inject the key only for the provider call
Trusty Squire places the credential into the outbound request on the server side. The provider receives its key; the caller does not.
- 04
Give apps revocable access
A deployed app can hold a scoped Trusty Squire grant with limits and audit history instead of holding the provider credential itself.
What to know
The precise safety boundary
A provider credential does need to reach its provider. The accurate claim is that the raw value does not need to appear in chat, source code, an .env file, credential-tool output, or the consuming app. Trusty Squire injects it into the provider request on the server side.
Write-only by design
Saving a credential is separate from reading it. Agent tools can refer to a stored credential and use it for an allowed call without receiving the plaintext back. If you personally need the value, you can reveal it in the web vault.
Scoped access limits the blast radius
Give a deployed application a scoped, rate-limited grant rather than the provider key. You can audit or revoke that grant independently. The last-mile article explains why this matters once an agent handles more of the build.