An Enterprise Edition (EE) instance is one organization's Seed, on one machine, reachable only through one hostname, usable only by people the organization invited. The privacy claim is:

Content stays on the box. Documents, comments, files and the index never leave the machine except in a backup the operator takes, or in an email the organization's own services send.

Nobody reads without a member session. Every page, API call and file by CID is refused at the edge unless the request carries a session that the instance itself issued to a member.

Nobody joins without an invitation. Accounts exist only in the on-box vault, which refuses to create one without a single-use code an operator minted.

Keys stay with people. Member keys live in the vault as ciphertext the server cannot read. The organization's root key is held by the daemon on the box and exported once to whoever installs the instance.

Everything below is the mechanism behind those four sentences, and then the places where the mechanism is weaker than the sentence.

There are four parties with different powers:

That third row is the most important thing on this page: in the current setup "the organization's private Seed" is private from the public and from other organizations, not from the Seed team. That is the normal hosted-service trust relationship, and it should be stated to customers as such until the hardening below changes it.

Inbound. The cloud firewall and the host firewall allow 22 (SSH), 80 (only to redirect to HTTPS and answer ACME), 443 TCP and UDP. Nothing else is reachable. The daemon's libp2p port is not published by Docker and the listener is bound to 127.0.0.1 inside its container. The daemon's gRPC and HTTP ports exist only on the Docker network; Caddy forwards only /ipfs/* to them, and only after the session check.

No peer-to-peer. The daemon runs with -p2p.isolated: a connection gater denies every inbound and outbound libp2p connection, no bootstrap peers are dialed, the peer-exchange tick does not run, relays, AutoNAT, hole punching and the NAT service are off, the site-domain poller and the on-demand /hm/api/config fetches are off, and -lndhub.disabled skips the startup wallet check that would otherwise send every local account id to Seed's lightning server. Discovery and the sync scheduler are disabled on top. Verified with a two-host test (an isolated node neither dials nor accepts) and by the NodeIsolated and LndhubDisabled log lines at boot.

Outbound, by design. These leave the box and should be understood as the privacy cost of operating it:

There is no telemetry: SENTRY_DSN is empty, the daemon has no update check, and the web app's statistics are off.

An operator mints an invitation (invite <email>): a 32-byte random code stored in the vault, bound to that email, single-use. The link is https://<host>/vault?invite=<code>.

The person creates an account in the vault: email, the 4-digit code the vault emails (through the relay), then a passkey or a password. The vault stores only ciphertext of their key material; the account's public key is generated in the browser. The invitation is consumed in the same database transaction that creates the user, so a code cannot be reused.

The person signs in to the site. The web app makes a throwaway session key in the browser, the vault signs a capability delegating the account to that key, and the browser uses it from then on. The vault never leaves its origin for this; WEB_IDENTITY_ORIGIN is the instance itself.

/hm/api/auth: the browser proves possession of the session key to the daemon, which mints a 30-day bearer token. Then, and only in this profile, the web app resolves the session key back to its account (through the capability) and asks the vault, over the Docker network with the admin secret, whether that account belongs to a vault user. Only then does it set the HM-Session cookie: base64url({account, exp}) + "." + HMAC-SHA256(secret), HttpOnly, Secure, SameSite=Lax, same 30-day expiry.

Every later request is checked by Caddy with forward_auth against /hm/api/session, which verifies the HMAC and expiry with no network call and answers 204, 302 (to the sign-in page, for HTML) or 401.

Why the extra cookie exists: the daemon's own token is minted for any key that has a single blob in the database, and the sign-in flow has to publish such blobs before any cookie can exist, so "has a daemon token" does not mean "is a member". Membership is the vault's user table.

The vault learns one thing it did not know on hyper.media: which public account ids belong to which email, because the browser reports them (each claim signed by the account key, so nobody can register a key they do not hold). That mapping is the whole membership list and is readable by the operator. It is a deliberate step away from the hosted vault's zero-knowledge posture, limited to this profile.

Phase 1 has exactly two classes: member and not a member. A member can read every document, comment and file the instance holds, including other members' personal spaces, because the daemon runs in public-only mode over content that is all public within the box, and the gate is binary. Writing is governed by the protocol's capabilities: the organization's space accepts writes from its owner key and from accounts holding a WRITER (path-scoped) or AGENT capability the owner signed. A member who was not granted anything can still create spaces of their own on the instance (/hm/create-site), and those are readable by all members.

What this means: EE today is a private intranet, not a system of compartments. Per-team confidentiality inside one instance needs phase 2 (private documents re-enabled behind a flag, a READER role, the two read-predicate gaps on the Privacy page fixed).

Everything the edge lets through without a session, with the reason and the risk:

All under /opt/seed on the block-storage volume, owned by root, readable by root and by the containers that mount them. The volume is not encrypted by the installer; use DigitalOcean's encrypted volumes or LUKS if the hosting contract needs encryption at rest.

Backups (seed-deploy backup) contain all of the above except owner-key/, which is deliberately left out so an archive is not also the root key. A backup archive is therefore as sensitive as the instance; it is unencrypted until the operator encrypts it.

The mnemonic of the owner key is never written anywhere: the bootstrap derives the seed in memory, checks that the daemon derived the same account, writes the .hmkey.json, and forgets it. The key file supports a password; the current tooling writes it without one, so the file is the key.

Stating the gaps plainly, because the first section is only as strong as this one:

"Nobody reads without a member session" is enforced at the edge and in the app, but a member reads everything; there is no finer boundary yet.

"Content stays on the box" is true for documents, but email text leaves through the relay and the hostname leaves through TLS.

"Keys stay with people" holds for members; the organization's root key also lives in the daemon keystore on the box.

Rate limiting at the edge is not configured (stock Caddy has no rate-limit module).

Nothing audits what operators do.

The deployment pipeline (hosting repo, Docker Hub, GitHub raw) is trusted on reputation, not on signatures.