Security model

Orlok lets virtual colleagues read your wiki and run commands on your systems. This page explains what stands between a colleague and a mistake, and what it does not cover.

Principles

• A colleague never has more rights than its person. It works with that person's profile, offices and credentials, and nothing else. See Roles and permissions.
• Credentials belong to people. Each person stores their own, one per host. A colleague acts on a server as the person it works for, so the server's own permissions and logs still apply.
• People decide. In ask mode, anything that is not plainly read-only waits for the person's approval.
• Everything is written down. Every change and every job goes to an append-only log, without secrets.

Accounts and sessions

• Passwords are hashed with Argon2.
• Sign-in is slowed down after 10 failed attempts on one account or 50 from one address in 15 minutes.
• A session is a random token in an HttpOnly, SameSite=Lax cookie. Only its SHA-256 hash is stored. The cookie is marked Secure when ORLOK_PUBLIC_URL uses https.
• A session lasts 12 hours, or 30 days with Remember me on this device, and is renewed while used. Each person sees their signed-in devices in Account and can sign them out.
• Disabling a person ends their sessions at once and deletes their credentials. The app returns to the sign-in page, which says why.
• Uploads and form posts must come from Orlok's own address (CSRF check), and the session cookie is not sent with requests that other sites start in the background.
• Invitation links hold a random token, stored only as a hash, and expire after 7 days.

Secrets at rest

• Model providers' API keys and people's credentials are encrypted with AES-256-GCM, using ORLOK_SECRET_KEY. The key is never stored in the database.
• A credential is decrypted only to hand it to the runner for a single job. The API never returns it, not even to its owner or to an administrator.

Back up the key separately. A database backup without ORLOK_SECRET_KEY cannot decrypt anything, and the key without the database is useless. Keep them apart, and keep both. See Backup.

Secrets in the wiki and in outputs

The office wiki is read by everyone in the office and sent to model providers, so Orlok tries to keep secrets out of it:

• a colleague's page write that looks like it contains a password, a private key or an API token is refused;
• commands and their output are masked where they look like secrets before they are stored, so the conversation, the log and the model see the masked text.

Pattern matching is a net, not a wall. It catches private keys, common token formats and "password: value" lines. A secret written in an unusual way can still get through. Do not paste passwords into the wiki or into a conversation: store them in Account → Credentials.

The runner

Colleagues never run commands inside the app. They ask the runner, a separate container:

• it publishes no ports, only the app reaches it, and it shares a token with the app;
• it is not on the database network and holds no Orlok data;
• it drops all Linux capabilities except the three it needs: switching each job to its own user, and raw ICMP for ping;
• each job runs as a dedicated user, in a fresh working directory, with limits on memory, CPU time, file size, open files and processes (see Environment variables);
• its filesystem is read-only, apart from a temporary folder.

The app container also runs with a read-only filesystem, no Linux capabilities and no way to gain new privileges. Postgres is reachable only from the app. See Security hardening.

Hosts

• The SSH host key is trusted on the first connection that gets in, then enforced: if the machine presents a different key, the connection is refused, whichever credential is used.
• Changing a host's address forgets its key, and an administrator can reset it on purpose.

The first connection trusts whatever answers. Make the first connection to a new host from a network you trust, or check the stored key against the machine's own.

Commands

How a colleague runs commands depends on the mode of its profile (see Modes):

Mode	Read-only commands	Other commands	Catastrophic commands
deny	—	—	—
ask	run	wait for approval, unless the person allowed that command type "always"	refused
full	run	run	refused
yolo	run	run	run

• Read-only commands are recognised from a list of diagnostics that inspect state without changing it or revealing secrets.
• Catastrophic commands are a short list that is always refused outside yolo, such as wiping disks or filesystems, removing the root folder, deleting shadow copies, clearing event logs, removing an AD domain or forest, or changing the owner or permissions of the whole filesystem.
• Only the person a command runs for can approve it.
• An "always allowed" command type belongs to one person: it covers that person's colleagues, and nobody else's. An administrator can turn it off.
• A command that cannot be read to the end, such as a script or a line built from variables, can only be approved once, never "always".

Approving is reading. An approval lets through exactly the command shown. Read it before approving, especially a long script: Orlok cannot tell you what an opaque script will do.

What Orlok does not protect against

• What the model provider sees. Conversations, the wiki pages a colleague reads and the output of its commands are sent to the profile's model provider. For data that must not leave your network, use a model you host yourself (Ollama or an OpenAI-compatible server).
• A credential with too many rights. A colleague can do on a server whatever its person's account can do there. Give people accounts with the least rights that do the job.
• Instructions hidden in content. Text in a document, a wiki page, a web page, a command's output or an MCP server's answer can try to steer a colleague. In ask mode, approvals are the brake. In full and yolo nothing stops a command that the rules let through.
• The Docker host. Whoever controls the server, the volumes or .env.production controls Orlok and everything in it.
• Plain HTTP. Without HTTPS, cookies and everything else travel in clear text on the network. See HTTPS.