Security

Erkle holds your team's decisions, conventions, and architecture notes, so it's fair to ask how it's run. This page answers the questions a security review usually starts with. If yours asks something it doesn't cover, email hello@erkle.ai.

Who runs Erkle

Erkle is built and operated by Justin Albrecht. It's a young product, and we'd rather tell you exactly where it stands than overstate it.

Hosting and network

• Erkle runs on two DigitalOcean servers in San Francisco, USA: one for the app and the database, and one for the embedding service that powers search.
• Only HTTPS (and HTTP, which redirects to HTTPS) is open to the internet, and only on the app server. The database, the API process, and the embedding service have no public ports, and both a cloud firewall and a host firewall stand in front of each server.
• Traffic between Erkle's servers travels over an encrypted WireGuard tunnel inside a private network, never over the public internet. Every request to the embedding service must also carry a secret token.
• Administrative SSH access is limited to a short list of operator IP addresses.

Encryption

• All traffic to Erkle, from browsers and agents alike, uses TLS.
• The database is stored on DigitalOcean block storage, which DigitalOcean encrypts at rest (LUKS). That includes everything Postgres writes, and the database won't start if the encrypted storage isn't mounted.
• Swap on both servers is encrypted with a key that is generated fresh at every boot and never written down.
• Nightly database backups are prepared on the encrypted storage and kept in DigitalOcean Spaces, which encrypts them at rest.
• The embedding server keeps no data. It holds memory text in memory only while computing a search embedding, and its logs never contain it.

What this doesn't cover: the encryption at rest is managed by DigitalOcean, so it protects against a lost, stolen, or discarded disk. It doesn't protect against DigitalOcean's own platform operators, or against anyone who gains root access to our running servers, because those servers have to read the data to serve it.

Access control

• Every memory belongs to one scope: the team, a project, or a repository. Every query is filtered to your team, and the team comes from your signed-in session or your agent's token, never from anything in the request.
• Access is checked on every request in one place in the code. A memory you can't read doesn't appear at all: not in search, not in lists, and not as "access denied".
• Team roles (owner, admin, member) and project roles (maintainer, contributor) decide who can read, write, and approve. Contributors' writes wait for a maintainer's review.
• Removing a member or revoking an agent takes effect on the next request.
• Every edit is a new, immutable version, so you can see who changed what and when.

Signing in, for people and agents

• People sign in with email and password (stored only as a hash), or with Google or GitHub.
• Agents connect with OAuth: you approve each one in the browser and choose its team. There are no API keys to copy, paste, or leak.
• Agents get access tokens that expire after an hour. Every connected agent is listed in the dashboard, and you can revoke any of them.

Secrets and logs

• Writes that contain private keys or AWS, GitHub, Slack, OpenAI, Anthropic, or Stripe tokens are rejected. It's a safety net, so please don't rely on it: keep secrets out of memories.
• Server logs record IDs and timings. They never contain memory bodies, tokens, or email contents.

Who else sees your data

Your memories never leave Erkle's infrastructure. Search embeddings are computed by Erkle's own embedding service, on our own server, so no AI provider receives your memories. Nothing in a memory goes to any third party, and we never sell or share your data.

The privacy policy lists every provider and what each one gets. They handle account data, such as email delivery, payments, and sign-in, and never memory content.

Your team's own agents receive the memories they search for, within your team's permissions. From there, a memory is part of that agent's context, and goes wherever the agent sends its context, such as the model provider you chose for it.

Backups and deletion

• The database is backed up every night. Backups expire after 14 days.
• Deleting a team permanently deletes its memories, projects, and agent connections right away, and they're gone from backups within two weeks.

Certifications

Erkle doesn't have SOC 2 or ISO 27001 certification yet. If your review needs a security questionnaire filled in, email hello@erkle.ai and we'll answer it. If you need Erkle inside your own infrastructure, ask about self-hosting.

Reporting a vulnerability

Email hello@erkle.ai with what you found and how to reproduce it. Please give us a chance to fix it before you share it publicly. Don't access, change, or delete other people's data while testing, and don't run tests that degrade the service for others. Issues in the @erkle/cli package can also be reported through a GitHub security advisory. Our security.txt has the same details.