Security & data residency
Where the memory lives, and how to erase it
EU-hosted, TLS in transit, scoped per end user, and erasable with one call. Here’s exactly what touches your agents’ data.
EU data residency
Your agents’ memory is stored on our own infrastructure in the EU, not replicated to the US. EU data residency applies on every tier.
Encryption and access
TLS for everything in transit. The database runs on our server in Helsinki and is not reachable from the public internet: only the Korely backend talks to it. API keys are never stored in plaintext, we keep only a SHA-256 hash, show the key once at creation, and verify in constant time. A leaked key can be revoked instantly.
One-call erasure (GDPR Art. 17)
Delete every memory and fact for one end user in a project with a single call: DELETE /v1/users/{end_user}/memories. The rows are physically deleted, superseded facts included, not flagged. An audit record keeps the counts, never the content, so you can prove the erasure happened. Your deletion endpoint wires straight to ours.
Your data is yours
We do not train any model on your stored memories or facts. The language model of your project’s region (Gemini, or gpt-oss-120b on Scaleway in the Europe region) reads your text for extraction and contradiction checks: inference, not training. Embeddings are computed on our own server. You can delete your account and its data at any time.
Scoped isolation
Every memory is scoped by your account and an end-user namespace. Cross-tenant reads are impossible by construction, the scope is enforced server-side on every query, not by prompt discipline. One customer’s memories can never surface in another’s results.
Keys scoped to a project
A key reads and writes only the memories and facts of its own project, so a staging key never touches production data. A key carries memories:read, memories:write or both: create a read-only key for an agent that only reads, and a write from it answers 403. The kor_live_ prefix makes keys recognizable to secret scanners. Revoke is instant, and the masked key and its last-used time are visible in the dashboard.
Sub-processors
The third parties that process Agents memory data, and exactly what each one sees.
| Sub-processor | Purpose | Location | Data |
|---|---|---|---|
| Hetzner Online | Hosting, database & embeddings | European Union (Helsinki, Finland) | All memories, facts, embeddings, and account data at rest. The embedding model (EmbeddingGemma) runs on the same server: memories, facts and search queries become vectors there. |
| Google (Gemini API) | Fact extraction and contradiction checks on writes, Global region (the default) | United States (EU SCC) | The text of a memory at write time, to extract typed facts; the earlier facts a new one is compared with, for the contradiction check; and a new relation phrase, the first time a project uses it. Searches and context queries do not reach Google. Not used to train Google’s models. |
| Scaleway (Generative APIs) | Fact extraction and contradiction checks on writes, Europe region | European Union (Paris, France) | In projects of the Europe region, the same text Google reads in the Global region, read by gpt-oss-120b instead. Prompts and outputs are not stored, except a request that causes an abnormal error (kept up to two weeks to investigate it). Not used to train any model. |
| Cloudflare | CDN & dashboard hosting | Global edge (no memory content stored) | Static dashboard assets and TLS termination. No memory content. |
| Firebase Authentication (Google) | Developer sign-in | United States (EU SCC) | Developer account email and auth tokens. Not your end users. |
Need a DPA or sub-processor list for procurement?
Email us with your company and use case. We’ll send the data processing agreement and answer security-review questions directly.
[email protected]See also the changelog and the API reference.