Public security overview · reviewed July 29, 2026
Security at hippocampOS starts with a product promise: you choose what enters a brain, the system keeps recall inside the scope you selected, and deletion removes the machinery behind that memory—not merely its screen.
01
Nothing is connected silently. You authorize each connector, select its brain, and decide when a source should sync.
02
A normal search is constrained to your account and selected brain. Cross-brain recall happens only when you choose Master Brain.
03
Connector credentials stay on the backend, protected from browser access, and OAuth handoffs are bound to the signed-in user.
04
Brain deletion clears its full scope; an audited connector rebuild removes only that connector’s contribution and preserves evidence still supported elsewhere.
The most important security decisions appear as normal product choices: which provider to connect, which brain receives it, whether a sync runs, which brain is invoked, and when data should be removed.
Source identity and brain ownership are carried from collection into processing, recall, and deletion. Independent evidence identities also prevent a retry from being counted as a new source. These are not labels added after the system has already mixed everything together.
Step 1
You see the provider, requested capability, and destination brain before authorization begins.
Step 2
The service fetches only what the connector permission permits and records source identity for provenance and cleanup.
Step 3
Jobs carry tenant, user, brain, and connector context. Inputs are validated and user-facing rich text is sanitized.
Step 4
Search and MCP tools apply ownership and brain scope before private context can be returned.
Step 5
Brain deletion clears associated records and queued work; an admin connector rebuild removes only the selected source contribution before fetching or reprocessing it again.
Connecting an AI client gives it a deliberately small memory surface. It does not expose the admin console, billing, connector credentials, worker controls, or arbitrary database access.
MCP exposes only brains:read and search:read.
Clients can list brains, search, fetch a result, and invoke a brain—nothing administrative.
Authorization is linked to the signed-in tenant and user, with PKCE support and expiring credentials.
Authorization and invocation activity is recorded with client, owner, scope, and outcome context.
Public traffic uses HTTPS. The production database is not publicly reachable, and the browser communicates with data services through authenticated backend routes rather than direct database or queue connections.
Content Security Policy, clickjacking protection, MIME sniffing protection, a restrictive referrer policy, and browser permissions policy reduce common web attack paths.
Allowed frontend origins are restricted at the API boundary. Private responses use private or no-store cache rules where sensitive state must not be shared.
Request identifiers, MCP audit records, job outcomes, and health checks make failures and suspicious access diagnosable without exposing secret values in the interface.
This is an implementation overview, not a certification badge. We will update it as the product, infrastructure, and independent assurance program evolve.
Report a security concern or ask how a specific feature handles your data. Please do not include passwords, access tokens, or sensitive source content in the first message.