The moment an agent acts on a belief, someone is accountable for it. OMEM is built so you can reconstruct agent state at decision time. It is early software, it is free while in beta, and the second list on this page is as important as the first.
Two modes, and the server picks neither for you. Local mode has no login and refuses to bind anything but loopback. Password mode (OMEM_AUTH=password) stores PBKDF2-SHA256 password hashes, and signup will not issue a session for an address that already has one.
TOTP (RFC 6238), enforced at session creation and on claiming an account. Sessions expire after 30 days and can be revoked; expired and revoked tokens stop working immediately.
Set OMEM_TLS_CERT and OMEM_TLS_KEY and the server speaks HTTPS directly, TLS 1.2 floor. A terminating proxy is still the better answer at scale (it renews and resumes better than this does) but OMEM no longer requires one to avoid plaintext.
OMEM_ENCRYPT_AT_REST encrypts memory content with AES-GCM: the operations log the engine is rebuilt from, ingested source payloads, and the quoted evidence behind each memory. Stored OAuth tokens are encrypted regardless. Lose the master key and you lose the data. There is no recovery path, by design.
Role-based, enforced per organization and per project. API keys are scoped to one project, carry their own role, can be bound to a single agent, and are revocable. Key secrets are shown once and stored hashed.
Every audit row commits to the one before it, per organization. Editing or deleting a row breaks every hash after it, and GET /v1/audit/verify says which row and why. Anchor the head hash somewhere OMEM does not control and the log becomes evidence rather than assertion.
GDPR/CCPA export and erasure are endpoints, not a process: /v1/export/memories exports a project, and tenant erasure removes every project-scoped row. Backups taken before an erasure still contain the data until they age out.
Per-IP limits on the auth endpoints and per-tenant limits on data endpoints, keyed by project and credential so one key cannot starve another tenant.
The engine is authoritative in memory, so a second process against the same database would answer the same question differently. The second process refuses to start and says so, rather than diverging quietly.
Self-hosted, on SQLite or PostgreSQL. MIT licensed, so the engine that decides what your agents believe is one you can read, fork, and keep.
The audit chain detects edits; it cannot prevent them. Anyone with write access can rewrite the chain from the edit forward. Detecting that requires keeping the head hash somewhere else, export it.
No OIDC, SAML or SCIM. Accounts are email and password.
There is one master key and no re-encryption tooling. Rotating it today means decrypting and re-encrypting by hand.
No region pinning. Your data is wherever you run it.
No SOC 2, ISO 27001 or HIPAA BAA. None are in progress.
One writer per database, enforced. That makes divergence impossible, not uptime possible: there is no second replica, no rolling deploy, and a restart replays the operations log before serving.
If your deployment needs something on this list, OMEM is not ready for it yet. Saying so here is cheaper for both of us than saying so after an audit.
OMEM is a standard first, with a public conformance suite. "Correct" is decidable: every deployment passes the identical 29-vector CTS. An agent built against one OMEM behaves the same against another. Your memory's meaning never leaves with a vendor.