Credentials live here, not in your agents
Authenticate each service once: OAuth consent, API key, username and password, or something bespoke. Agents get a scoped, revocable VectorHub key and nothing else.
Four ways to authenticate a service
Real estates contain modern OAuth apps, legacy basic-auth boxes and at least one thing that signs requests with HMAC. All four are first-class.
OAuth 2.0
Full authorization-code flow with PKCE, refresh-token rotation and per-user consent. VectorHub handles the callback, the token store and the refresh loop.
API keys & tokens
Static keys, bearer tokens and signed headers, stored encrypted and injected at call time. Rotate from the dashboard without redeploying anything.
Username & password
Basic auth and form-login services, including legacy internal systems that never got a modern auth story.
Custom schemes
HMAC request signing, mTLS client certificates and multi-step token exchanges, described declaratively per connector.
One key, scoped to exactly one job
A support bot gets Zendesk reads and Slack writes. It cannot list Stripe customers, because that tool does not exist as far as its key is concerned.
- Scoping works at tool level, not just connector level.
- New keys start with no access and are granted deliberately.
- Optional expiry dates and IP allowlists per key.
- Rotation is a vault operation: no redeploy, no downtime.
- Revocation is effective on the next request, with no cache to wait out.
# the support bot can read tickets and post to Slack
vectorhub keys create support-bot \
--connectors zendesk,slack \
--tools "zendesk.ticket.read,zendesk.ticket.update,slack.message.post" \
--expires 90d
vh_live_9f2c… # shown once
# the finance agent shares the Stripe connection, not the scope
vectorhub keys create finance-agent \
--connectors stripe,quickbooks \
--tools "stripe.invoice.*,quickbooks.report.read" \
--deny "stripe.refund.*"
# a leak is a one-line problem
vectorhub keys revoke support-bot
✓ revoked · effective immediately across 3 clientsWhy prompt injection stops at the gateway
An agent that reads untrusted input can be steered. The question is what it is able to do once it has been.
Provider key in the agent
The injected instruction succeeds. The key had every permission the key had, the call looks legitimate upstream, and the provider log shows only “API key ending 4f2c”.
Scoped key at the gateway
The call is outside the allowlist, so it is rejected before any credential is touched, and the attempt is logged against a named key, which is how you find out it happened at all.
Auth questions
Does my agent ever see a provider credential?
No. Agents hold a VectorHub key. The gateway decrypts the provider credential in memory, attaches it to the outbound request and discards it. The provider secret never crosses back to the client.
How are secrets encrypted at rest?
Envelope encryption with a per-tenant data key wrapped by a managed KMS root key. Data keys are rotated on a schedule and on demand, and plaintext exists only for the duration of an outbound call.
Who handles OAuth token refresh?
VectorHub does. The full authorization-code flow with PKCE runs at the gateway, refresh tokens are rotated automatically, and an expired token is refreshed transparently mid-call rather than failing the tool.
What does revoking a key actually do?
It takes effect on the next request, everywhere that key was configured. Because agents never held provider credentials, there is nothing to rotate downstream.
Can two agents share a connection but not a scope?
Yes, that is the normal case. One Salesforce connection can back a dozen keys, each with a different tool allowlist.
Get your credentials out of your dotfiles
Connect one service, scope one key, and see what your agent can and cannot reach.
No credit card required · Free tier available · Self-host on request