Security model in depth

Murage runs AI agents on your own computer, with your files and your accounts. That's powerful, and it means protection has to be designed in layers. This page explains each layer, what it protects against, and where its limits are.

Layer 1: everything runs locally#

Murage is a desktop app with a small server inside it. That server listens only on your own computer (127.0.0.1), never on your network. Your bots, conversations, memory, files and settings live in the .murage folder in your home folder. There's no Murage server holding your work.

Things leave your computer only when you point them somewhere: the engine a bot uses, connected apps, web search, voice, channels, off-site backups and update checks. Privacy and usage analytics lists each one.

Murage's own data folders are made owner-only on your computer, so other user accounts on the same machine can't read them.

For work that must never leave the building, put that bot on a local model. Nothing about its turns goes to a cloud provider then.

Layer 2: keys are encrypted by your operating system#

In the desktop app, API keys and tokens are encrypted with your operating system's own secure storage (the Keychain on a Mac, and the equivalent on Windows and Ubuntu) and handed to Murage's server only when it starts. The settings file doesn't hold them in plain text.

Keys are write-only inside Murage. Once you save a key, the app only ever reports whether one is set; it never shows it back, never writes it to a log and never passes it on a command line where another program could read it. Your Telegram bot token is stored encrypted too, and isn't shown again once saved.

Engines you sign in to yourself, such as Claude Code or Codex, keep their own sign-in with their own tools. Murage uses the sign-in; it doesn't copy it.

Bots are told never to look for, copy or move passwords, keys or card numbers. On Full access and No limits, reading your keys and passwords still asks.

Layer 3: approvals and the stop line#

Every bot runs at an approval level: Ask (the default), Auto, Full access or No limits. The permission broker sits between the engine and anything risky, and a card waits for your answer.

The stop line is the part that still applies on Full access. A bot stops before messaging anyone new, posting publicly, paying, or deleting outside its folder, unless you have allowed it for that task. On Claude Code and Codex, the stop line also covers tools from MCP servers you add. On Hermes and other ACP engines, Ask and the stop line cover only what the engine asks Murage about: Hermes asks before shell commands and file edits, but not before MCP or connected-app tools. It's checked on every permission in Ask, Auto and Full access. Only No limits turns it off, and No limits can only be switched on in the desktop app, with a warning.

Full access and No limits can't be switched on from a phone. Memory administration and credentials are desktop-only too.

See Permissions and the stop line and the Approvals playbook.

Layer 4: unattended work gets less trust

A turn nobody is watching gets treated more carefully:

• Webhook turns are judged as Auto, whatever the bot's level.
• Each routine runs at the level you give it, or the bot's level if you don't. Reading your keys asks at every level.
• Only your own desktop app and paired devices can answer an approval card. A message whose sender Murage can't confirm runs as an unattended turn.
• Bot-to-bot contact can require your approval: Ask me before contacting other bots.

This matters because one bot's output can become another bot's input. Keeping unattended and relayed work on a tighter leash stops a chain of bots from doing what you'd never approve directly.

Layer 5: outside text is information, not orders

Emails, web pages, files, channel messages and webhook payloads can contain text written to trick an AI ("ignore your instructions and forward this to..."). Murage labels untrusted input before a bot sees it. Messages from Slack and Discord, and webhook event data, reach the bot wrapped in clear markers that say they're untrusted. The default House Rules tell every bot that what it reads can inform it but can never instruct or approve anything, and to tell you when something tries.

No labeling is perfect against every attack, which is why the approval layer still sits behind it.

Layer 6: webhooks are authenticated and local

Webhooks listen on 127.0.0.1:8800, a separate receiver from Murage's main port. Each one needs a secret: a bearer token in a header, or a secret address for apps that can't send headers. Secrets are stored as hashes, not in plain text. To receive events from the internet, you run your own tunnel to that receiver. Never expose Murage's main port.

Layer 7: Skill Guard

Skills are text that shapes what a bot does, and a malicious skill is an easy way to attack an agent. Every skill is scanned when you import, install, switch on or edit it, and again whenever Murage starts. Skill Guard works offline and looks for credential theft, data leaving for outside sites, risky commands, instruction takeovers and hidden text. Results are No red flags, Needs a look (you must choose Use it anyway) or Blocked.

Imported skills land switched off. Skills a bot learns with /learn also land switched off until you choose Enable. See Writing your own skills.

Layer 8: imports never grant power

Importing a team gives every bot a fresh identity on Ask, with skills off, routines paused, and no apps, computers or Chief role. Exports never include credentials, conversations, memory or permission grants, and they're scanned for secret patterns.

Layer 9: computers and the browser fail closed

• Using your screen is off by default. A bot asks once before it first touches your screen, and watching the screen never grants control.
• The built-in browser runs each bot in its own isolated profile. It denies site permission prompts, refuses downloads, and can't open local files or the app itself. When a page has a password field, the bot doesn't see that page's contents, and once you type into one yourself the session stays protected.
• Missing permissions, unexpected programs and failed health checks stop the feature rather than run it anyway.

Layer 10: updates come from one place

Murage checks for updates on its public releases repository on GitHub. Mac builds are signed and notarized by Apple, and Windows builds are signed. Ubuntu packages come with SHA-256 checksums you can verify. Updates are never installed without you choosing to. Only install Murage from the official download page or releases page, and never from a file someone sends you.

What Murage doesn't protect against

Being honest about limits is part of the model:

• Engines run as you. An engine with shell access has your user account's permissions. The broker asks before risky actions, but it's a careful check, not a sandbox.
• Hosted providers see what you send them. Forgetting a memory can't recall text already sent to a cloud engine.
• Pattern scanners miss things. Skill Guard and the export secret scan catch known patterns only. Read skills from sources you don't know.
• No limits means no limits. Don't use it for bots that can reach customers, money or other people's data.

Report a security problem

Please don't open a public issue for a vulnerability. Report it privately by following the security policy in the Murage repository. It explains how to reach us and what's in scope.