Security posture.

Platform teams that adopt Essarion need to be able to say, with confidence, "we own this." This page is what that means in practice — the controls in place today, the principles they came from, and the seams where governance plugs in.

§ 01Identity & sessions

Browser identity is carried by a JWT (HS256) signed session inside an HTTP-only, secure cookie. Sessions expire after seven days. The cookie is rotated on sign-in and on sign-out — the previous token is no longer accepted the moment a new one is issued.

That keeps the surface for stolen-cookie reuse small: short windows, secure transport, no JavaScript access to the cookie value, and a clean rotation on every transition.

§ 02API keys

Programmatic credentials use the esk_ prefix and carry sixteen bytes of cryptographic randomness, base64url-encoded. The plaintext key is shown to the user exactly once at creation; the platform stores only a SHA-256 hash, which is what every subsequent lookup hits.

Each key has a status — active, revoked, or inactive — and a last_used_at timestamp updated on every use, so dormant keys are easy to identify and prune. Revoking a key is immediate and irreversible.

§ 03Service-to-service

When the gateway calls the research engine, it presents a service bearer token and signs the originating user into request headers — X-Essarion-User-Id and X-Essarion-Key-Id. The engine accepts user attribution only when paired with a valid service token. Caller-supplied user IDs without that token are refused.

The principle is simple: identity decisions belong to the gateway, the engine trusts attribution only because the transport is mutually authenticated, and there is no path by which an external caller can talk directly to the engine.

§ 04Tenant isolation

Every row that the platform owns — query, file, run, source, document, key, usage — is scoped to a user_id, and where applicable to a project_id. Ownership is checked on every read, not just on every write.

This is the rule that makes shared infrastructure safe. The same database serves every customer, but the application layer never returns a row whose ownership doesn't match the authenticated caller.

§ 05Transport

All public surfaces are served over HTTPS. HSTS is available behind the reverse proxy where deployments require it. There is no plaintext fallback path for credentialed traffic.

§ 06Response headers

The gateway sets a conservative default header policy.

• Content-Security-Policy defaults to 'self' only; it is relaxed only for embedded development previews where running customer code is the point.
• X-Frame-Options is DENY by default — pages cannot be framed unless an allowlist is explicitly configured.
• X-Content-Type-Options is nosniff.
• Permissions-Policy denies camera, microphone, and geolocation by default.

§ 07File upload safety

Uploads go through a layered check. First, an extension allowlist filters obviously unwanted types. Second, a magic-number signature check verifies that the bytes match the declared type — a renamed executable does not get past this stage. Third, the platform generates its own storage filename; the user's original filename is retained as metadata only and is never used as a path.

The combined effect is that the filesystem only ever sees server-controlled names, and the type of every stored byte is what the user said it was.

§ 08Sandbox isolation

Agent terminals run inside per-run PTYs. Sandboxes can be headless (Node, Python) when only execution is needed, or headed (VS Code, Chromium) when the agent needs a real UI. Each run gets its own sandbox; runs do not share filesystem or process state.

The isolation boundary is the run, not the user. A second run in the same project is still a fresh sandbox.

§ 09Audit logs

Security-sensitive actions are recorded in an audit table — authentication, workspace session lifecycle, and file uploads, downloads, and deletes. Each row carries the user_id, the action, the status (success or failure), references to the resource the action touched, the user agent, and a hashed IP address.

The hash is one-way — the platform can correlate activity from the same source without retaining a recoverable IP. That keeps the audit trail useful for investigations without making it a target for theft.

§ 10Cost & rate controls

Rate and cost protection live alongside auth. Each user has a daily cap on web searches, a cap on concurrent fetches, and per-token accounting tied to their plan. The gateway enforces these before proxying upstream, so a runaway script can't burn through quota or upstream credits unnoticed.

§ 11Reporting

If you find something, please tell us. Email security@essarion.com and we will respond. Coordinated disclosure is welcome and credited.