Stays in your workspace
Sources, buckets, agents, and answers live in your workspace. Nothing is shared with other customers.
Calypso Context · Privacy
Yours, isolated.
Your knowledge stays in your workspace, is never shared with other customers, and is never used to train shared models. Export or delete it any time. API keys carry explicit capabilities, and when one is missing the API says which.
Never trains shared models
Your knowledge is retrieved for your answers. It is not used to train models that serve anyone else.
Export or delete any time
Sources delete one at a time or up to 100 in one call. A bucket deletes with its members. A named agent deletes with its id.
Out of bounds stays out
On WhatsApp, contacts on the Hidden board are never read, never answered, and never used as knowledge.
The example
Least privilege, and a clear no.
A restricted key carries an explicit list of capabilities. Ask it to do something outside that list and the 403 names the exact grant it lacks.
CALYPSO_API_KEY
# A restricted sync key can upload and poll files, nothing else.
# Ask it to crawl a page and the API names the missing grant:
{
"error": {
"code": "forbidden_project_key",
"message": "This API key lacks the required capability.",
"retryable": false,
"details": { "required_capability": "knowledge:website:create" }
},
"request_id": "req_abc123"
}Key scopes
What a key is allowed to do.
Full-access keys carry every capability. Restricted keys carry an explicit list. Provisioning and destructive grants must be given deliberately.
| Capability | Grants | How it is assigned |
|---|---|---|
| knowledge:file:read | Read sources, buckets, tasks, batches | Automatic on any key with the knowledge file API enabled |
| knowledge:file:create | Upload files, sessions, batches, import by URL | Automatic on any key with the knowledge file API enabled |
| knowledge:file:delete | Remove individual sources and detach bucket members | Explicit |
| knowledge:website:create | Ingest web pages | Explicit only, by design: crawling runs third-party analysis per call |
| knowledge:bucket:create | Provision buckets | Explicit |
| knowledge:bucket:delete | Delete a bucket and its member files in one cascade | Explicit |
| rag:agent:create | Provision named agents | Explicit |
| rag:agent:delete · rag:agent:update | Delete or update a named agent | Explicit |
The ask and search surfaces authenticate with the key itself and are governed by your plan’s answer entitlements, not by per-capability grants. Grants take effect on the key’s next request.
How it works
Scope, separate, rotate.
- 01
Scope each key to its job
A sync job gets file create and read, nothing else. It can upload and poll without a single checklist grant.
- 02
Separate provisioning from ingestion
A provisioning script gets bucket create, and agent create if it creates agents, and runs apart from steady-state sync.
- 03
Rotate over-privileged keys
Any key with more capability than its integration uses gets replaced by one that has exactly what it needs.
Out of bounds
Exclusion is enforced at retrieval, not by promise.
On a business WhatsApp number, some conversations must never be processed. The Hidden board is not a lower priority; it is exclusion, and it is forward-looking from the moment a contact is placed there.
- The agent never reads the conversation.
- The agent never answers it.
- Nothing in it is used as knowledge.
- The Hidden board in the WhatsApp docs
From the docs
The commitments in one table.
| Isolation | Knowledge is kept within your workspace and is not shared with other customers |
|---|---|
| Training | Your knowledge is never used to train shared models |
| Export and deletion | Export any time; delete a source, up to 100 sources in one call, a bucket with its members, or a named agent |
| Keys | Full-access keys carry every capability; restricted keys carry an explicit list; destructive and provisioning grants are deliberate |
| On a missing grant | 403 forbidden_project_key · details.required_capability |
| Source visibility | An agent policy: retrieval still happens, and grounded_sources_state reports hidden when titles are suppressed |
| Opening a source | Citations carry a signed access_url when one is available; the original is not served publicly |
| Hidden board | Never read, never answered, never used as knowledge |
Questions and answers
Before you trust it with your knowledge.
Keep reading
Sources
PDFs, images, pages, and data. What it reads and how it gets in.
Buckets
Scoped, durable source memory. Provision by slug, bind to agents.
Agents
One default, any number of named agents with their own scope and policy.
Citations
A source on every answer: annotations by offset, a structured source list, native mode.
Search
Retrieval without generation: the passages an answer would cite, ranked.
Key scopes in the docs
The reference this page is written from, with every endpoint and field.
Start today
Your knowledge. Your rules.
Create a scoped project API key, load a bucket, and see exactly what each key can and cannot do.