Security
Uteke Cloud stores what your AI agents remember. This page says how that data is kept apart, protected and backed up, who else may process it, and how to tell us about a problem.
Your workspace is isolated
- Every account has its own workspace. The database enforces row-level security on every request, so a query can only see the rows of the workspace it runs for.
- Deletes are also limited to your workspace in the query itself, on top of row-level security.
- The search index stores a workspace id with every vector and filters on it for every search.
- Operators run the service from a console that shows counts, plans and dates, never memory content.
Keys and sign-in
- You sign in with a CodeCora ID. Agents that sign in (OAuth) never see a password or a key.
- API keys are shown once. We store only a salted, keyed hash, so a copy of the database does not reveal a working key. Revoking a key takes effect at once.
- An agent's sign-in can be revoked from your CodeCora ID account; access is checked again within about 30 seconds.
Secrets are masked
Text that looks like an API key, a token or a private key is masked before a memory is stored. This is on by default. A workspace can choose to reject such writes instead, so nothing is stored and the agent is told why.
No AI reads your memories when they are recalled
Recall is search: full-text and vector results fused together. No model sees your memories when an agent recalls them. Optional features that use a model are off by default, name the provider that runs them, and never run on recall. Search embeddings are computed on servers we operate, so no embedding provider sees your content.
Transport and servers
- All traffic uses TLS, and the site sends HSTS so browsers stay on HTTPS.
- The application containers run read-only, without extra Linux capabilities, and open no ports to the internet except through the TLS proxy.
- The site loads no third-party scripts or fonts. Page-view counting is self-hosted, uses no cookies and never runs on the portal.
Backups
The database is backed up and the backup is verified before every production deploy, and backups are kept separately under our control. The search index is derived from the database and can be rebuilt from it in full, so a lost index never means lost memories.
Where your data lives
Your memories are stored and searched in one region, Singapore, on servers we rent and operate. If that changes, the privacy policy changes first.
Subprocessors
- Server hosting provider: a server we rent and operate. Your memory content is stored and served from it.
- Zhipu AI (Z.ai): only if you turn on extraction, when that feature is available. It then receives the session text you choose to extract from.
The privacy policy is the authoritative list and says what each provider receives.
Your data, your exit
Export every memory and document as NDJSON at any time from the portal or the API, and delete your account yourself: your memories, documents, keys and their search entries are removed at once. See Import and export.
What runs behind it
The parts of the service you do not have to run yourself, beyond what this page covers above:
- Embedding pipeline: 768-dimension EmbeddingGemma on servers we operate. No model server to run, no embedding API bill.
- Vector index: managed and rebuilt from the database whenever needed. Nothing to provision.
- Hybrid recall: full-text and vector search fused per query. You never tune retrieval modes.
- Usage limits: hard limits that fail closed, metered per workspace and rate limited per account.
- Audit trail: an append-only record of changes to your account and data.
Report a vulnerability
Email [email protected] with "Security" in the subject. Tell us what you found, how to reproduce it, and what an attacker could do with it. Please test only against your own account, do not access other people's data, and give us a reasonable time to fix the problem before you publish it. We reply to every report.
If a personal data breach affects you, we notify you as the privacy policy describes.