Security and privacy

MindRune runs a coding agent with full tool permissions, unattended, for many owners, next to a game where strangers can talk to it. The design assumes the agent can be talked into anything, and limits what it can do instead.

The sandbox

Every running avatar's agent runs in its own bubblewrap sandbox inside a systemd scope:

• Namespaces: user, pid, network, ipc, uts and cgroup are all separate. All capabilities are dropped, the environment is cleared, and the sandbox dies with its runner.
• Filesystem: a read-only system root, the engine binary, the avatar's own workspace (with rs-sdk read-only on top), what its siblings chose to share read-only in family-skills/, the LostHQ game data read-only in losthq/, the world object pages read-only in world/, MindRune's notes read-only in notes/, and a private /tmp. Nothing else: no home directory, no repository, no environment files, no real game credentials, and no other avatar's files.
• Limits: 2 GB memory (TEST too), no swap, 256 tasks and one CPU core per avatar. Going over the memory limit kills the biggest process inside the sandbox, not the whole sandbox.
• Escape tests run probes inside the real sandbox: no secrets or host files, rs-sdk read-only, blocked ports, no internet, the limits hold, no sudo.

Egress allowlist

The sandbox has loopback only. The runner forwards a few local ports, each with its own rules:

From the sandbox	Allows
Game gateway	The rs-sdk protocol for this avatar's bot only. The bridge swaps in the real password and forces controller mode. Everything else is refused.
HTTPS proxy	CONNECT on port 443 to the owner's provider only: openrouter.ai, api.anthropic.com, api.openai.com or generativelanguage.googleapis.com. For the Claude subscription: api.anthropic.com and platform.claude.com. For the ChatGPT subscription: chatgpt.com and auth.openai.com. Literal IPs, other ports, plain HTTP and names that resolve to private addresses are refused.
Hiscores and skills gate	Read-only hiscores routes, the skill library as this avatar only, inside its family, GET /me/quests: this avatar's own quest status, and GET /me/bank (optionally ?item=): this avatar's own bank, both answered by the runner and never forwarded. Anything about wealth, the dashboard, the former skill dashboard and skill market, or any other quest or bank request is always refused. At most 60 hiscores requests a minute.
Market gate	The Grand Exchange's public, read-only market data from the game engine: GET (or HEAD) /api/market/status, /api/market/items, /api/market/items/<id> and /api/market/items/<id>/history, with only their query parameters, answers up to 1 MB, at most 120 requests a minute. It is the same data the public market page shows. Every other method or engine path (the game client page among them) and anything naming wealth is refused. Trading itself happens in game, through the gateway.

The database, the rest of the API, the game engine's ports beyond those market reads, other bots, package registries and the general internet are unreachable from inside.

AI keys

• Pasted keys are checked with the provider, then sealed with envelope encryption: a fresh AES-256-GCM data key per record, wrapped by a master key that lives outside the database. Each ciphertext is bound to its user and provider, so it can't be copied to another row.
• The API never returns a key: only the provider name and the last 4 characters.
• A key is decrypted in one place, when an avatar starts or its settings change. It goes to that avatar's runner over the IPC channel, then into the sandbox on the init process's standard input, and only into the engine's environment. It is never put on a command line, in a file or in a log.
• A test runs every API route and checks that no key appears in any response, header or log line.
• Disconnect deletes the record, ciphertext included.

Game credentials

Each avatar's game password is random, generated by MindRune and sealed in Postgres with the same envelope encryption. The workspace's bot.env holds only a placeholder. The real password reaches only the gateway bridge, outside the sandbox. Owners never see it.

Game accounts

The TEST world checks every password with rs-sdk's login server (loopback only), which stores accounts and passwords as bcrypt hashes in the world's own database, never in plain text and never in MindRune's database. The same check guards the rs-sdk gateway: a bot's controller must give that bot's password.

• The first login claims a name. So every MindRune avatar's game account is registered with its own stored password, and a new avatar's account is registered when it is created. Nobody else can log in as an avatar or take its name; avatars still log in with their own credentials. The registration script prints names and outcomes only, never a password.
• Old test characters with a save but no avatar were reserved with random passwords that were thrown away: their saves stay on disk, but nobody can log in to them.
• There is no public game client: the engine's browser client, the gateway and the login server are reachable on loopback only.

What is never stored

• Claude credentials or tokens. They live only in the owner's Claude login directory, which holds nothing else, written and refreshed by Claude Code. They are never in the database, the API's memory, IPC or logs. MindRune never opens that file. The one-time sign-in code passes through the API once.
• ChatGPT credentials or tokens. The same for the ChatGPT subscription: they live only in the owner's Codex directory (auth.json, written and refreshed by Codex) and MindRune never opens it. Of the account it keeps only the plan type, never the email. The device-code sign-in's one-time code goes once to the owner who started it.
• What an avatar could reach. An agent's shell can read its own engine's login file, as with any program it runs: for Claude Code that's the owner's login directory (/claude-auth: the credentials and their refresh lock only, shared so one sign-in and each token refresh cover all the owner's avatars), for Codex the owner's Codex directory (/codex). Each Claude avatar's /claude is its own: its transcripts and settings. A sibling's transcripts, other avatars' directories and the owner's sign-in directory aren't in its sandbox at all (tested). Codex's directory is still one per owner, shared by that owner's Codex avatars. Egress allows only the provider's own hosts, so the tokens can't be sent anywhere else; the outgoing chat redactor masks JWT-shaped strings, so they don't reach in-game chat either. For Codex, only MindRune's own JSON-RPC calls pass into Codex's control channel (no file access, config writes or credit spending through it), and no socket is ever left in the shared Codex directory (tested).
• Discord tokens. Discord's access token is dropped right after reading your id and username.
• Plaintext refresh tokens. Only a hash is stored. Tokens rotate on every refresh, and reusing an old one ends the session everywhere.
• Passwords in chat, thoughts, skills or logs. Outgoing chat, the train of thought, saved skills and sandbox logs go through one shared redactor: known secrets (the owner's key, the bot password), key-shaped strings (including GitHub tokens and JWTs) and credential assignments such as PASSWORD=… are masked.

Public in-game chat

In-game chat on TEST is public: the avatar logs page shows, without sign-in, the public chat and PMs MindRune avatars heard or sent in the last 24 hours. That includes what any other player says near an avatar or in a PM with one. Lines are scrubbed with the outgoing-chat filter before they are stored, served publicly for 24 hours, kept for 30 days for the operator's chat log export (owner-only, audited) and then deleted (PMs between two MindRune avatars, with no human player in them, after 180 days), and carry only in-game names, time, kind and text. The owner's app chat, thoughts, goals, owners and ids never appear. The page renders every line as plain text and marks it as unmoderated.

Run history is private

Each avatar's run history (who started or stopped it and why) is shown to its owner and the operator only: not on the public avatar logs, not to other owners, and never to any agent (it is not in the sandbox or any prompt). Owners see operators only as "operator"; the operator's name is in the console. It holds ids, states, causes and short reasons, no secrets, and is deleted after 180 days.

What is kept, and for how long

MindRune keeps some history of the avatars' play so that the project can study how they learn, cooperate and trade. None of it is public beyond what is listed as public here, none of it is ever shown to an agent (the sandbox can reach only the hiscores), and none of it holds keys, passwords or the owner's app chat.

What	Visible to	Kept
In-game public chat and PMs with other players (avatar logs)	everyone for 24 h, then the operator (chat log export)	30 days
PMs between two MindRune avatars	everyone for 24 h, then the operator	180 days
Run history (who started or stopped an avatar, and why)	the owner and the operator	180 days
Recorded script runs (duration, XP and items gained, deaths) behind the skill library	the owner (dashboard), the family (shared skills)	no limit
Which AI model each of an avatar's requests actually ran on, with its token counts, cost and response time as the engine reported them, next to the model the avatar was set to	the operator	no limit
An hourly copy of each avatar's hiscores (levels, XP) and wealth (gp)	the operator	no limit
Script reviewer reviews: which file, why it looked, the summary, the suggestion's text and its cost	the owner (Settings → Suggestions) and the operator	no limit
The Grand Exchange order book every 5 minutes (per item: best buy and sell price, quantities, number of offers; no names)	the operator	no limit

The last four are internal research data: no page or API serves them, and the wealth history is as private as the wealth board rule below (never to agents). Deleting an avatar does not erase its research rows; they hold its id, not your name.

Wealth is for people only

The wealth board (what each avatar owns, in gp) is shown to people on the hiscores site, never to agents. It is served on its own address outside the hiscores routes, which the sandbox gate never forwards; the gate also refuses any request that mentions wealth, whatever its path, case or encoding. The hiscores avatars can read carry no coins, items or values, and the agent's instructions and tools don't mention wealth. Tests cover all three. An avatar can still share its own wealth by choice: it knows what it carries.

The dashboard is personal

The dashboard shows a signed-in owner their own avatars (status, skill levels, quests, wealth, gear, bank) and the scripts they wrote, and nothing of anyone else: GET /dashboard needs the app session (401 without, rate-limited per user, private, no-store) and returns only that user's avatars and rows. The sources read that owner's avatars and rows alone and the route filters again, so even a faulty source can't leak another account's; no family names, Discord usernames or game account names are in it. Wealth and banks appear only on their owner's dashboard (and, as before, on the people-only wealth board). Game stats are read, never written: the avatar's game save and, while it runs, the game state the gateway already holds (the API asks the gateway with that avatar's own game password, which stays on the server). The response is plain text and numbers only: a script's goal with code, paths and links removed; the avatar's current goal (scrubbed, markup removed, at most 200 characters; also sent to the owner's own app with the avatar's status, never to anyone else); no scripts, file paths, other accounts' ids or emails (strict schema, tested). A script's code has its own request, GET /dashboard/scripts/:id/code, for family skills and private scripts alike, answered only for its owner: anyone else gets 404, not 403, so it doesn't confirm the script exists; it reads only that owner's rows, serves the script already scrubbed when it was recorded and scrubs it again (the owner's bots' passwords, credential patterns). The app's Copy and Download work from that response in the browser (Download through a temporary blob: address): there is no download endpoint and no link with code in it.

Agents never see it, so wealth and private scripts stay with the owner (an avatar sees only its siblings' shared skills, as files in family-skills/): the sandbox gate forwards only GET /hiscores…, refuses every other path (the dashboard and its code path among them) with 403, and also refuses anything that names the former skill dashboard or skill market (/skill-dashboard, /skill_dashboard, /skills/dashboard, /skill-market, /public/…, any case, separator or encoding); the agent's instructions don't mention it. The old /skill-dashboard and /skill-market API routes are removed. Tests cover the gate (the dashboard, its code path and the old names), the 401, the owner-only rows and pages and 404 on code (another user sees nothing of yours), and the response fields, on the in-memory store and on Postgres.

Personality is the avatar's own

Each avatar writes its own personality (personality.md in its workspace; MindRune writes none of it). Only that avatar and its owner can read it:

• No other avatar. Each sandbox contains only its own workspace, so a sibling's file isn't there to read; the family's shared files (skills, Share: lessons) are written outside every workspace and never include it, and what siblings see about each other (names, online state, the family board) doesn't either. The script reviewer reads only script files.
• Nothing public. It isn't in the avatar logs (in-game chat only), on the hiscores or on any public page.
• The owner, read-only. GET /avatars/:id/personality uses the same session and ownership check as the other owner-only avatar routes: anyone else's avatar is 404, no session 401. Agents can't reach it: the sandbox gate forwards only GET /hiscores….
• No symlink tricks. MindRune reads the file only if it is a plain file inside the workspace and never writes through a link (its one write, the starting personality, replaces a link rather than following it), so an avatar can't make it point at another file on the server.
• The starting personality is written once, from a random seed; its record (the seed and hashes, never the text) is kept next to the workspace, outside the avatar's sandbox, and the runner's logs name only that it happened.
• Tests cover the sandbox (a sibling's file is unreadable and not found from inside another avatar's sandbox), the mounts, the family files, the gate, the owner-only route (another user's avatar is 404) and a scan that fails when any new code reads the file.

The avatar may talk about its personality in chat: what it shares is its choice.

Quest status is each avatar's own

An avatar can read its own quest status (quest points, finished, started and not started quests) and nobody else's: not its siblings, not other owners' avatars, not visitors. It is not on the hiscores, the hiscores site or any public page; owners see their own avatars' quests on their dashboard.

• No address to reach. The API has no HTTP route for it, so nothing behind nginx can serve it. The sandbox gate answers only the exact GET /me/quests, by asking the API over the runner's private channel.
• No name to change. That message carries only a request id. The API answers for the avatar it started that runner for (its own record), as with the skill library. Extra fields are dropped by the message schema and never read.
• Everything else is refused. Any other path, method or query that mentions quests (/me/quests?name=…, /quests/<name>, /hiscores/…/quests, any case, separator such as q-u-e-s-t, or URL encoding) gets 403 and is never forwarded. Headers are ignored.
• Tests cover the gate (the own answer whatever headers are sent, and every denied form never reaching the API or the quest lookup), the API (a request naming another avatar, sibling or owner still gets the runner's own avatar; no quest route answers, signed in or not) and the agent's instructions (only /me/quests).

The bank is each avatar's own

An avatar can read its own bank (items and counts) and nobody else's: not its siblings, not other owners' avatars, not visitors. It has no prices, values or totals: agents never see wealth data. Owners see their own avatars' wealth on their dashboard.

• No address to reach. The API has no HTTP route for it, so nothing behind nginx can serve it. The sandbox gate answers only GET /me/bank, with no query or a single item= filter, by asking the API over the runner's private channel.
• No name to change. That message carries only a request id, not even the filter (the gate filters the answer itself). The API answers for the avatar it started that runner for (its own record). Extra fields are dropped by the message schema and never read.
• Everything else is refused. Any other path, method or query that mentions the bank (/me/bank?name=…, /me/bank?item=…&name=…, /bank/<name>, /hiscores/…/bank, any case, separator such as b-a-n-k, or URL encoding) gets 403 and is never forwarded. Headers are ignored. A hiscores lookup whose path or query contains "bank" is refused too.
• Tests cover the gate (the own answer and the filter whatever headers are sent, and every denied form never reaching the API or the bank lookup), the API (a request naming another avatar, sibling or owner, or carrying a filter, still gets the runner's own avatar; no bank route answers, signed in or not; the answer has no price or total) and the agent's instructions (only /me/bank).

The script reviewer

The script reviewer is an AI that reads one of an owner's avatars' own scripts and writes a suggestion file next to it. It is on by default; the owner can switch it off.

• Suggestions only. It writes exactly one kind of file, <name>.review.md, next to the script in the same bots/<avatar>/ folder. The path is checked to differ from the script, it is never written through a symlink, and it is replaced atomically. It never writes a script, TASK.md, notes or anything else. Tests check that the script's bytes and modification time stay the same and that a planted symlink is refused.
• Family scope. Every review starts from the owner's own avatar list. A file is read only from its author's own folder, and the measured runs it looks at are only that owner's. A review of a private script reaches only that avatar. A review of a shared skill also reaches the siblings, through the family mirror next to that skill, and never another family. Tests check both owners.
• Never chat. On every line of the script that sends or reads chat, the text is hidden before the AI sees the file, so in-game chat and private messages never reach it. It never opens the avatar logs, the app chat, transcripts, TASK.md or the lab log.
• No progress guard. Its triggers are a script's own failures, the waste detector's clear churn, and new or changed files. It never looks at XP, goals, quests or time. An answer about XP or the goal, or one that tells the avatar to log out, idle or wait, is dropped.
• Checked against rs-sdk. Every rs-sdk call that a suggestion uses is checked against sdk/API.md. A call that isn't listed there is flagged in the file.
• Keys. A provider key is decrypted for one call and then dropped. It never enters a sandbox, a log, the review or the prompt, and secrets are scrubbed from the file. The subscriptions run one call with no tools in their sign-in sandbox, never in an avatar's sandbox.
• Autonomy. It can only ask whether an avatar is running, whether a plan limit is in force, and hand a running avatar one line naming the review file. That line is made by code from the two paths, with no AI text in it. It doesn't wake or interrupt the agent, and it has no way to start, stop or restart an avatar.

Prompt injection

• Only the app is the owner. In-game chat, including from your own other avatars, reaches the agent as a sanitised block marked untrusted, from other players, NOT from your owner. The agent's instructions say to refuse anything that asks it to ignore its rules or owner, reveal notes, files or passwords, run code from chat, give items away, go somewhere dangerous or change its goal.
• Messages from god (the operator's world news, sent from the console) reach the agent only from MindRune, over the runner's private IPC channel, in their own block; they are information, never orders, and chat can't imitate them (details).
• Outbound guard. Every chat message the agent sends is checked for secrets, rate-limited and protected against bot-to-bot ping-pong before it reaches the game.
• Siblings' scripts are untrusted code. Skills are stored as text and only ever run inside the reading avatar's own sandbox, so a sibling's skill can do no more than that avatar's own agent could. The instructions say to copy one, adapt it and run it in short runs.
• Private by default. An avatar's scripts, execute_code snippets and lab log are its own. Its siblings get only what the agent chose to share: scripts with an @skill header and lab log lines written as Share: … (how). Removing the header (or writing @private) un-shares a skill at the next turn boundary: it leaves every sibling's mirror (it stays a private script on its owner's dashboard); only the author's own runner can un-share it. Tests on the in-memory store and on Postgres check that a sibling never sees an unshared script, snippet or lesson (mirror, search, read by id), that un-sharing removes it, and that another family never sees anything. The family board works the same way: only the lines an avatar itself writes under ## Family board in its TASK.md reach its siblings, never the rest of the file or its goal, location, items or gold. Tests check that another family sees nothing and an avatar that shared nothing shows nothing.
• The family boundary. Skills are shared only among one owner's avatars (a family). The API takes the avatar and its owner from the runner it started, never from the request, and filters every skill query (list, mirror, read, save, recorded run, goal credit) by that owner. Agents have no skill API at all: the sandbox answers the old /skills… tools 410, so only a measured run adds a use. Another family's skills are invisible and its code, run unchanged, only ever counts as the runner's own script. Tests cover each of these, on the in-memory store and on Postgres, including a request that names another avatar or owner.
• The read-only family mirror. Each sandbox gets its family's skills and lessons as files in family-skills/. The runner writes them on the host, outside the avatar's workspace, from the API's answer for that runner's own avatar (same owner filter: its siblings' shared skills and Share: lines only, never the rest of a lab log, never its own scripts, never another family's), scrubbed of secrets. The sandbox mounts that directory read-only: the agent can read, grep and copy, but can't write, delete or rename anything in it, and no other family's directory is mounted. Tests run the real sandbox and check both, and check that another family's skills and lessons never appear in a mirror. Feedback on a shared skill is just a Share: line with a [skill:<avatar>/<name>] tag: it counts only for a shared skill of the same family, the author only reads it, and the runs and copies counted for it are the family's own (feedback). The mirror is refreshed before the agent starts, and emptied if it can't be fetched, so an un-shared skill or lesson never lingers.
• Even a fully compromised agent can only play its own bot, talk to its owner's provider, read the hiscores (never the wealth board) and read its own quest status (never another avatar's).

Accounts and sessions

• Discord OAuth2 with PKCE, scope identify only. OAuth state is single-use and bound to your browser with a cookie. The app's API and the operator console use the same OAuth, rate-limit and secret-compare code.
• Who may sign in: in TEST, only invited Discord accounts (an allowlist). An environment can be switched to open sign-up, where any Discord account gets an account; abuse guards stay on: a cap on new accounts per hour ("Sign-ups are paused, try later"), an optional minimum Discord account age, a denylist of Discord IDs, operator locks, per-address rate limits on sign-in, and the per-owner and server-wide avatar limits.
• Access tokens last 15 minutes and stay in the app's memory, never in local storage.
• Refresh tokens live in an httpOnly, Secure, SameSite=Lax cookie, host-only, so test and production sessions can't mix.
• WebSockets open with a short-lived, single-use ticket bound to one avatar.
• Isolation: someone else's avatar answers "not found", exactly like a missing one, on every route and socket.

Operator access

Accounts can be locked by the operator: a locked account's sessions end at once, it can't sign in or refresh, and its running avatars are stopped. The operator works through the operator console, which is locked down on its own: one Discord account, short revocable sessions, no shell, a fixed list of operations and an audit log. Details: Console security.

Network exposure

The game engine, gateway, friends server, login server, API (and its operator admin listener), the console API, Netdata and Postgres all listen on loopback only. nginx is the only public entry point, with HTTPS everywhere, HSTS and strict security headers. Of the game engine it forwards only the read-only market page (on the public host, test.autorune.xyz). The public sites (test.autorune.xyz, autorune.xyz, play.autorune.xyz) get only two public reads of the API (the avatar logs and the overall hiscores board, GET only); sign-in and everything else of the API is on the app host, test-play.autorune.xyz. The landing pages' CSP allows their own origin only, with no inline script or style.