In short
memkith stores the memories your agents write, never your code. Who can read a repository’s memory is decided by the database on every query, against access granted in memkith.
- No source code. Agents send the text of a memory and the paths it concerns. Files are never uploaded, and the GitHub App cannot read repository contents.
- Access enforced in Postgres. Row-level security runs every query as you. A memory you may not read is never returned, not filtered after the fact.
- Short-lived credentials on the wire. The API only accepts signed access tokens that expire within 15 minutes.
- Alpha, and no certifications. memkith holds no SOC 2, ISO 27001 or other certification, and claims none.
What we store
memkith is a memory layer, so the data is the memories. This is the complete inventory.
Stored
- The text of each memory an agent writes: heading, content, kind, reuse rule.
- The repository paths a memory is scoped to.
- Provenance: git author name and email, branch, commit, and the agent and conversation it came from.
- Your account: email, name, avatar, workspace membership and access grants.
- Repository names and who can reach them, as reported by the GitHub App.
- Hashes of your CLI tokens, and when and from where each was last used.
Never stored
- Your source code. No file is uploaded, and the GitHub App never reads repository contents.
- Your agent transcripts. memkith sees only what an agent chooses to save as a memory.
- CLI tokens in readable form. Only a hash is kept.
- Your git credentials. They are stripped from the remote URL before it leaves your machine.
- Telemetry from the CLI. It makes no calls except to sign in and read or write memory.
How access is enforced
Memory access is granted in memkith and nowhere else. GitHub permissions decide nothing: being able to push to a repository gives you no memory access, and being granted memory access gives you nothing on GitHub.
- To read a repository’s memory you must be a member of the workspace that owns it, the repository must be turned on, and you must hold a read or write grant. Workspace owners always have write.
- Removing someone from a workspace deletes their grants in it. If they are added back, they start with none.
- Writing a memory gives you no lasting right to it. Lose access to the repository and you lose access to what you wrote there.
Enforced by the database
These rules are Postgres row-level security policies, not checks in application code. The API connects as a role that cannot bypass them and owns no tables, attaches your verified identity to each transaction, and lets the policies decide. A request with no identity matches no rows. The health check run after every deploy fails if that role ever gains superuser or bypass rights.
A memory or repository you cannot see answers exactly like one that does not exist, so its existence cannot be probed. The policies are tested on every pull request against a throwaway copy of the database.
Separation inside memkith
The website and the memories API are separate services. Workspace administration and GitHub sync run under their own database roles with their own narrower grants, reachable only with a service credential the public API never accepts. No role used at runtime can delete a memory.
Sign-in and tokens
Your account
Accounts sign in with email and password, confirmed by a 6-digit code sent to the address, or with GitHub or Google. Session cookies are HttpOnly, Secure and __Secure- prefixed. Accounts that never confirm their email are deleted after 7 days.
The CLI
memkith login uses the OAuth loopback flow for native apps (RFC 8252) with PKCE, S256 only. The browser returns a one-time code to 127.0.0.1 on your machine; the code is single use, bound to that exact address and challenge, and expires after 60 seconds.
| Credential | Lifetime | How it is protected |
|---|---|---|
| CLI token (mks_) | 30 days | 256 bits of randomness. Kept in your OS keychain, or a 0600 file where there is none. memkith.com stores only its SHA-256 hash and shows its first 8 characters. Never sent to the memories API. |
| Access token | 15 minutes | Minted by exchanging the CLI token. Ed25519-signed; the API checks signature, issuer, audience, expiry and age on every request. |
Settings lists every token with when and from where it was last used, and flags one used from a different network than it was created on. Revoke one there, or run memkith logout on the machine. Revoking stops new access tokens immediately; one already issued runs out within 15 minutes.
Sign-up and every CLI sign-in and token endpoint are rate limited per address, and token endpoints per account too.
Encryption
- In transit: HTTPS to memkith.com and the API. Every database connection requires TLS with full certificate and hostname verification, and the services refuse to connect without it.
- Sealed by memkith: GitHub user tokens and the session material held during CLI sign-in are encrypted with AES-256-GCM using keys that live only in the website. The database holds ciphertext.
- At rest: memory text, account details and everything else are stored in Neon Postgres, whose storage Neon encrypts. memkith adds no field-level encryption on top of that for memory content.
- Hashed, not stored: CLI tokens and invitation links are kept only as SHA-256 hashes. Invitations expire after 7 days.
The GitHub App
The GitHub App tells memkith which repositories exist and who can reach them. It reads repository names, collaborators, organization membership and your verified email addresses. These are every GitHub API call memkith makes:
| Call | Why |
|---|---|
installation repositories | List the repositories you selected when installing the App. |
repository metadata | Name, owner and id, to match a checkout's origin remote. |
collaborators | Suggest who an admin might grant access to. It never grants access by itself. |
user, emails | Link your GitHub identity and check invitations against your verified email. |
installation tokens | Short-lived tokens GitHub issues for the calls above. |
memkith makes no call to repository contents, commits, trees, blobs or archives. Webhooks from GitHub are verified with HMAC-SHA256 in constant time and rejected when the signature does not match. Uninstalling the App or revoking your authorization on GitHub removes the stored link.
Retention and deletion
- Memories are kept until the account that wrote them is removed.
- Turning a repository off keeps its memories and grants, and turning it back on restores them.
- Removing a person from a workspace removes their access, not the memories they wrote.
- Unconfirmed sign-ups are deleted after 7 days.
There is no self-serve way to delete a memory or an account yet. To have either removed, email [email protected].
Not in place yet
memkith is in alpha. These are known gaps, listed so you can weigh them rather than discover them.
- CLI tokens are not scoped. A CLI token carries your full rights. If you are a workspace owner or admin, that includes adding people and granting access, not only reading and writing memory.
- No instant revocation. An access token already issued stays valid for up to 15 minutes after its CLI token is revoked.
- No consent screen on CLI sign-in. If you are already signed in to memkith.com, the browser step of
memkith logincompletes without asking. - No self-serve deletion. Memories and accounts are removed on request, not from the product.
- No audit log. Token use is shown per token, but there is no workspace-wide record of who did what.
- Browser hardening headers. memkith.com does not yet set its own Content-Security-Policy or framing policy.
- No automated dependency scanning. Dependencies are pinned by lockfile and CLI packages ship with npm provenance, but nothing scans them for advisories yet.
- Unsigned native binaries. The CLI binaries are checksummed before release but not code-signed or notarized.
- No certifications. No SOC 2, ISO 27001 or penetration-test report exists yet.
Reporting a vulnerability
Email [email protected]. Include what you did and what you saw; a proof of concept helps but is not required. Reports reach a person rather than a queue, so allow a few days for a first reply.
Please do not test against accounts or data you do not own. Ask, and we will set you up with a workspace you can break freely.
The same contact is published at /.well-known/security.txt.