What we hold, and what we refuse to hold
Cornelius stores text: the Markdown memory files your agent writes, the event log beneath them, every earlier version of every file, and your account email. That is the whole treasure.
Just as important is what never enters the building. Your Gmail and Calendar are authorised inside your AI platform, so we hold no connector credentials. There are no provider API keys to paste, so we hold none. The beta is free, so we hold no payment details. And we never send your data to an AI model: all interpretation happens inside your Claude, ChatGPT or Codex app. We store and serve text; we do not read it.
One brain per person, enforced in the database
Tenant segregation is not a habit of our application code, it is a property of the database itself:
- Row-level security on every table. Every table that holds user data (memories, versions, links, events, commits, reports, cycles, the audit trail) has Postgres row-level security switched on and forced, so even the application's own database role cannot bypass it. Each row is stamped with its owner, and the policy admits only rows whose owner matches the identity of the current request.
- Identity is set per transaction. Each tool call runs in its own database transaction, and your verified identity is bound to that transaction alone. There is no ambient "current user" that a bug elsewhere could leak across requests.
- No unscoped path exists in the code. The raw database handle is private to one module; every query in the product goes through a client that requires a tenant first. A handler that forgets scoping does not compile.
- Even your account row is fenced. A signed-in tenant can see exactly one row of the users table: their own.
The only door is OAuth
Every call to the brain, from your agent or from your dashboard, carries an OAuth token that is verified on that call. The server is stateless: your identity is re-derived from the token on every single request, never remembered from a previous one. There are no API keys, no shared secrets to leak, and authorization tokens are never written to our logs. The dashboard goes through the same authenticated door as the agent; there is no privileged side entrance.
The write path: scanned, tagged, versioned
Your agent's tool surface is deliberately small: seven tools, of which exactly one can write and none can delete. Every write then passes through the same pipeline:
- Injection scan. Content is checked for prompt-injection patterns. Suspicious spans are stored but flagged, never silently absorbed: they are redacted when memory is read back, and flagged events are excluded from search entirely, so poisoned text cannot ride back into your agent's context.
- Provenance. Every event carries a source tag (chat, daily cycle, email summary, calendar summary, your own note) and a trust tag (you, your platform, or external), preserved end to end.
- Versioning. Memory files are never edited in place. Each change creates a new version and the old one stays readable, so every change is reversible and inspectable.
Nothing rewrites history
The event log and the audit trail are append-only, and that is enforced twice inside the database: the application's role is simply not granted update or delete on those tables, and a trigger raises an error on any update or delete regardless of role. Whatever happens above, the raw record of what was written, when, and from where cannot be quietly altered.
Deleting is yours alone
Your agent has no delete tool; if you say "forget this" in chat, it will point you to the dashboard. Deletion is a dashboard-only flow: you request it, we email you a confirmation link that expires in one hour, and nothing is removed until you confirm on that page.
The enforcement matches the promise: the role the running service uses cannot delete rows at all. Hard deletion runs through a separate maintenance credential used only by the confirmed-delete path. A compromised or misbehaving server process could not destroy your memory, because destroying is not among its database permissions.
Before you delete, the same dashboard hands you everything as a zip: every memory file, every earlier version, and the raw event log. Your data is yours to take anywhere, any time.
Sharing is explicit and revocable
Nothing you store is publicly reachable. The one sharing feature that exists, living reports, is off until you press share, and works through a random token with its own narrow read-only database policy: a share link can read that report and nothing else. Revoke it from the dashboard and the link dies.
Under the floorboards
- Encryption. Data is encrypted in transit (TLS everywhere) and at rest.
- Least privilege. The runtime connects with a minimal database role; schema changes and administration run through separate credentials that the live service never holds.
- Secrets hygiene. Credentials live in the deployment environment, never in code or repositories, and never in logs.
- Hosting. Managed infrastructure at Render, in the United States.
What this does not solve
Two honest limits. First, your agent summarises external content, so memory poisoning is reduced, not eliminated: the scan, the trust tags, and the append-only raw layer mean bad content is flagged, quarantined from retrieval, and always traceable, but no scanner catches everything. Second, once memory is served to your AI platform, what happens inside that app is governed by the platform's own security and privacy terms, not ours.
Reporting a problem
If you find a security problem, tell us at general@cornelius.bot and we will take it seriously and get back to you. Please do not test against other people's data; every account gets its own brain, and yours is the right place to poke.
Beta notice: this page describes the private beta as built. It complements the Privacy Policy, which covers what we collect and why.