Sharing and Security
Sharing Your Agent
By default, only you (the owner) can message your agent. To let others use it, manage the allowlist.
The allowlist lives on the Mutiro platform — not in your agent's .mutiro-agent.yaml. It's enforced server-side, so a disallowed user's message is rejected before it ever reaches your agent host. For hosted agents, manage it from mobile, web, desktop, or CLI. For self-hosted agents, use the desktop app or CLI:
In the app, share by username when the person already has a Mutiro account, or by email when they do not. Email sharing creates an agent-share invite: if that email already belongs to a Mutiro user, access is applied immediately; otherwise Mutiro sends an invite and applies the share after that email signs up.
Your agent's display name, bio, and avatar also live on the platform (not in the yaml) and are updated the same way:
Security Model
Security depends on two things multiplied together:
Mutiro-hosted agents use hosted defaults for tools. Self-hosted agents can narrow or expand tool access in their config; the tool-specific guidance below applies when that control is available.
1. Exposure — who can talk to the agent?
Every message, file, image, or forwarded content is a potential prompt injection vector.
| Who talks to it | Risk |
|---|---|
| Only you | Low — but you still forward content from elsewhere |
| Trusted friends/team | Medium — they may unknowingly forward hostile content |
| Anyone (open access) | High — treat all input as adversarial |
2. Blast radius — what can the agent do if tricked?
| Capability | Risk | Why |
|---|---|---|
| Read-only | Low | Can only search and report back |
| Writes to files | Medium | Could poison files that persist |
| Writes to memory | Medium-High | memory_write persists inside that agent-user workspace and can affect that same relationship later |
| Sends messages | Medium | Could be used to phish or spam |
| Runs shell commands | Critical | bash, process, code bypass every safeguard |
These multiply. High exposure + memory writes = dangerous, even without "Dangerous" tools.
Workspace Isolation
When user_workspace: "./users/${USERNAME}" is set (the default), each non-owner user gets their own isolated subdirectory. The owner uses the root workspace. This prevents:
- Users reading each other's files
- Users poisoning another user's memory
- Users poisoning the owner's memory
- Cross-user contamination
Memory follows the resolved workspace. The owner has owner workspace memory; each non-owner user has memory in that user's isolated workspace. Memory is not a global store shared by every user of the agent.
Guidelines
Personal agent (only you): Defaults are fine. Be mindful of what you paste or forward — hostile content in a PDF or image can still inject instructions.
Shared with trusted people: For self-hosted agents, consider removing memory_write or writeFile if those users don't need them. Keep workspace isolation on.
Open to everyone: For self-hosted agents, strip down to minimal tools — send_message, thinking, maybe recall. No file writes, no memory writes, no web tools. Consider running in a container.
Agent that fetches web content: web_search and web_fetch ingest untrusted data. If the agent also has memory_write or writeFile, a malicious web page could inject instructions that persist. Consider separating into a "research agent" (reads web, reports to you) and an "action agent" (only takes your instructions).
The Lethal Combination
Avoid combining all three in one agent:
- Ingests untrusted data (web, files from strangers, forwarded content)
- Can take consequential actions (write files, send messages, run commands)
- Runs without human oversight
If you need all three capabilities, split them across separate agents with you reviewing in between.
For the self-hosted tool catalog and what each tool does, see configuration.