A gateway holding every credential has to earn it
Centralising secrets removes a sprawl problem and creates a concentration problem. This page is how we handle the second one, and what you should verify before trusting us with the first.
How the platform is built
Six controls that are structural rather than configurable, because the ones you can turn off are the ones that end up off.
Encrypted credential vault
Secrets are encrypted with envelope encryption, per-tenant data keys and a managed KMS root. Plaintext exists only in memory for the duration of an outbound call.
Scoped, revocable keys
Every key is bound to a connector and tool allowlist with an optional expiry. Revocation takes effect on the next request, with no cache to wait out.
Isolated execution
Connector calls run in per-tenant sandboxes with egress allowlists, so one tenant's traffic cannot reach another tenant's resources.
Complete audit trail
Who called what, with which arguments, from which key, at what time. Exportable to your SIEM with configurable retention.
Least-privilege by default
New keys start with no access. Scopes are added deliberately rather than trimmed back from a permissive default.
Regional data handling
Choose where credentials and logs are stored. EU and US regions are available, with custom residency for enterprise deployments.
Where a secret lives, and for how long
The honest version: a provider credential exists in plaintext for the duration of one outbound HTTP request, inside one process, and nowhere else.
- At rest: encrypted with a per-tenant data key, itself wrapped by a KMS root key.
- In transit to us: TLS 1.3 only, with HSTS and certificate pinning on the CLI.
- At call time: decrypted in memory, attached to the request, discarded.
- In logs: never. Credential material is excluded at the serialiser, not filtered afterwards.
- On rotation: old material is destroyed, not archived.
agent ──► gateway
│
├─ 1. authenticate the VectorHub key
├─ 2. resolve tenant + allowlist
├─ 3. authorise the requested tool
│ └─ denied? stop here. no credential touched.
├─ 4. fetch wrapped data key from KMS
├─ 5. decrypt provider credential ──┐
├─ 6. call upstream with credential │ in memory
├─ 7. zero the credential ──────────┘
├─ 8. shape + truncate the response
└─ 9. write audit record (no secrets)
│
upstream APIWhat this defends against, and what it does not
A security page that only lists strengths is a marketing page. Here is the boundary.
Bounded by design
- Leaked agent key: scoped and revocable in one operation
- Prompt injection: out-of-scope calls rejected and logged
- Credential sprawl: one vault, no copies on laptops or in CI
- Silent access growth: every grant is an auditable event
- Cross-tenant reach: per-tenant keys and sandboxed egress
Still your responsibility
- Scoping keys tightly: we default to nothing, but you choose the grants
- Deciding which destructive tools an agent may reach
- What your agent does with data it is legitimately allowed to read
- Securing the environment where your VectorHub key is stored
- Reviewing the audit log: we produce it; someone has to read it
Reporting a vulnerability
Email [email protected] with enough detail to reproduce. We acknowledge within one business day and aim to have a fix or a mitigation plan within five. We do not pursue legal action against good-faith research that respects user data and avoids degrading the service for others.
Security questions
Does an agent ever receive a provider credential?
No. Agents hold a VectorHub key. The provider credential is decrypted in memory at the gateway, attached to the outbound request and discarded. It is never returned to a client.
What stops one tenant reaching another tenant's data?
Credential stores are keyed per tenant with distinct data keys, and connector execution runs in per-tenant sandboxes with egress allowlists. There is no shared credential cache.
How does this help with prompt injection?
It does not prevent an agent from being steered: nothing does reliably. It bounds what a steered agent can do. A call outside the key's allowlist is rejected before any credential is touched, and the attempt is logged against a named key.
Do you have SOC 2?
We are in the observation window and expect a Type II report. Ask us for the current status, the architecture documentation and our penetration test summaries: we share them under NDA during evaluation.
How do we report a vulnerability?
Email [email protected] with details. We acknowledge within one business day, and we do not pursue legal action against good-faith research that respects user data and avoids service degradation.
Start the review
Architecture documentation, completed security questionnaire and pentest summaries, shared under NDA during evaluation.
No credit card required · Free tier available · Self-host on request