Credentials, sealed
API credentials live apart from source content, encrypted at rest, and are never returned in plaintext — not to the UI, not to a model.
Security & trust
Built to keep secrets
Encrypted credentials, redaction before every model call, and strict tenant isolation on every workspace-owned record and query.
encrypted at restredacted before modelstenant-isolated
The problem
A support tool sees everything. That's the risk.
To answer well, a support platform needs your keys, your context, and your customers' conversations. That concentration of sensitive data is exactly why the wrong architecture is dangerous: a leaked credential, a cross-tenant query, or a secret echoed into a model prompt turns your support tool into your biggest exposure.
Why it works
Support touches your most sensitive material — API keys, customer conversations, and internal context.
Redacted before models
Secrets are stripped before any model call. The agent can act on a credential without the credential ever entering a prompt.
Tenant isolation by default
Every workspace-owned record and query preserves tenant boundaries, enforced down to the database with row-level security.
The guarantees
What we promise, in plain light
The most sensitive material — keys, conversations, context — is handled so it can't leak. These aren't marketing promises; they're the architecture.
- Credentials kept separate from source content
- Encrypted at rest, never returned in plaintext
- Redacted before every model call
- Row-level security on every workspace query
AES at restRLS enforced0 secrets in prompts
Secrets
Credentials that content can't touch
API credentials are stored separately from the docs, schemas, and conversations they relate to. They're encrypted at rest and redacted before they reach a model, so an ingested doc or a customer message can never surface a key. The agent uses credentials it is never shown.
- Credentials kept separate from source content
- Encrypted at rest, never returned in plaintext
- Redacted before every model call
credentials · kept apart
Isolation
Your workspace is your workspace
Tenant isolation isn't an afterthought — it's enforced on every workspace-owned record and query, with row-level security and parent/child relationships checked at the database. One tenant's context, conversations, and credentials are never reachable from another.
- Row-level security on workspace-owned tables
- Parent/child tenant relationships verified
- No cross-tenant reads, writes, or retrieval
tenant isolation · RLS
Public surface
The widget is scoped, not a skeleton key
Public widget access uses a workspace public key plus route-level controls. It lets visitors chat and read what you've published — it does not grant general table access. Operator-only diagnostics stay operator-only, and customer-private data stays private.
- Public key + route-level controls for widget access
- No general table access from the public surface
- Operator-only diagnostics kept off the customer side
public widget · scoped
How it works
Three steps, no heavy lift.
01step
Store secrets sealed
Credentials are encrypted at rest and kept apart from the content they relate to.
sk_live_•••• · sealed
02step
Redact before models
Any secret is stripped before a prompt is ever built, so it can't leak through the agent.
prompt → redacted
03step
Isolate every query
Row-level security scopes each read and write to the owning workspace.
workspace_id = current_tenant
AES
encrypted at rest
0
secrets in prompts
RLS
on every query
FAQ
Security & trust questions
Where do my API credentials live?
Separately from source content, encrypted at rest. They're redacted before any model call and never returned in plaintext to the UI or the agent.
Can one workspace ever see another's data?
No. Tenant isolation is enforced on every workspace-owned record and query, including row-level security and verified parent/child relationships at the database.
Does the public widget expose my tables?
No. The widget uses a workspace public key with route-level controls that permit chat and published content only. It never grants general table access.
Could a secret leak into an AI prompt?
Secrets are redacted before prompts are built, and ingested content plus user input are treated as untrusted, so credentials don't enter model calls in the first place.
Support without the exposure
Keep credentials sealed, secrets out of prompts, and every workspace strictly isolated.