Sharing and Security

By default, only you (the owner) can message your agent. To let others use it, manage its access list.

The access list lives on the Mutiro platform and is enforced there: a disallowed user's message is rejected before it ever reaches your agent. Manage it the same way for every agent, from the sharing screen in any app or from the CLI's allowlist commands:

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.

# See who has access mutiro agents allowlist get <agent-username> # Allow a specific user mutiro agents allow <agent-username> <your-username> # Deny a specific user mutiro agents deny <agent-username> <your-username> # Allow multiple users at once mutiro agents allowlist set <agent-username> alice bob charlie # Open to everyone (use with caution) mutiro agents allowlist set <agent-username> "*" # Clear ordinary user access (developer grants are managed separately) mutiro agents allowlist set <agent-username> # Add or remove from the current list mutiro agents allowlist add <agent-username> <your-username> mutiro agents allowlist remove <agent-username> <your-username>

Your agent's display name, bio, and avatar also live on the platform (not in the yaml) and are updated the same way:

mutiro agents update-profile <agent-username> --display-name "New Name" mutiro agents update-profile <agent-username> --bio "Short description" mutiro agents update-profile <agent-username> --avatar-url "https://..."

Granting Developer Access

Sharing lets someone use your agent. Granting developer access lets them help build and supervise it, with owner-level access to this agent's conversations and user workspaces. This includes access to users' messages and files, and the owner workspace's shared context and durable memory.

Use Agent Developers in the agent overview to manage these grants. Only the owner can grant or revoke developers, and developer actions remain attributed to their own accounts. Changes take effect in the running agent when it restarts. Developer grants are separate from the ordinary user access list; clearing that list does not revoke developers.

For the distinction between a chat, an engine session, and stored files, read Agents, Conversations, and Workspaces.

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

With user_workspace: "./users/${USERNAME}" (the default), each ordinary user gets a separate workspace. Owner and developer conversations use the owner workspace. Conversation histories are kept in separate engine contexts; durable memory follows the workspace, so the owner and developers share its memory despite having separate chats.

User workspaces are separated from each other through the normal workspace view. They remain accessible to the owner and granted developers for supervision. Actual agent access also depends on available tools and allowed, denied, and read-only paths.

The shared/ folder deliberately makes common files readable across users; under hosted defaults only owner/developer sessions can write there.

See workspace layout and sharing for the scope of each directory. Separate contexts and separate workspace roots do not make explicitly shared resources private.

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 full tool table and what each tool does, see configuration.