AI tool permissions in Mono: what to check before allowing
Understand Mono chat policies, MCP tool overrides and coding-agent approvals, then review the action, target and scope before granting access.
Before you allow an AI tool to do something, find out what it will read or change, which account or file it affects, and whether your approval covers only this request or future ones too. A familiar tool name doesn’t answer those questions.
Mono by Reunified has separate controls for chat tools, connected MCP tools and coding agents. This guide explains how they differ and gives you a simple way to review each request. Mono isn’t out yet (join the waitlist), and the choices you see depend on the connection and agent you use.
1. Distinguish account access from action approval
Signing in to a service gives access to that account. Approving one action answers a different question: should this particular action run now? Installing a skill, granting a system permission and accepting a coding agent’s request are separate decisions too.
Take a made-up document task: “find my draft” doesn’t mean “share the draft publicly”. The account may allow both, but your request covers only one. Before you connect anything sensitive, write down the limit you have in mind: read one named document, return a summary, and stop.
Use the skill installation guide to decide whether to trust and set up a skill. Once it’s in use, look at each action instead of assuming the install settled every future decision.
2. Know which Mono control applies
In Mono’s Permissions settings, Tools has separate defaults for query calls, which read information, and mutation calls, which change something. Each can be set to Allow, Ask or Deny. These defaults apply to the tools the assistant calls in chat. For an installed MCP skill, the Configuration section can list its tools, and a choice there overrides the default for that tool.
Ask shows a card where you allow or decline the call. Allow runs it without asking, and Deny blocks it. Because these defaults cover chat, don’t assume they also decide what coding agents or scheduled tasks do.
Coding agents ask for permission separately, and the agent decides which choices to offer, such as Allow, Always allow or Deny. Mono’s YOLO mode accepts every agent request without asking, so the agent edits files and runs commands unattended. Leave it off if you want to review each request yourself. Sessions keep running on your computer when your phone disconnects, so locking your phone doesn’t pause the agent.
3. Read the action, target and available detail
Compare the requested action with your original task. Ask what leaves the device, what might change and where the result will appear. Even a read can share private data with a connected service, so a “query” label doesn’t mean a call is harmless.
The consent card names the tool and the server, but it may not show every detail of the request. Coding permission details can also be shortened to fit the screen. If the target, recipient or command isn’t clear, decline or pause, and ask for a readable description before you allow it.
The MCP tools specification says tool annotations should be treated as untrusted unless the server is trusted. Judge a tool by what it actually does and where it comes from, not by a reassuring label.
4. Choose the narrowest suitable decision
Use this worksheet when a request appears:
| Proposed action | What to check before allowing |
|---|---|
| Read a project document | Right account, the exact document and how the data will be used |
| Update one record | The exact record, fields and new values |
| Send or share content | Recipient, content, who can see it and when it goes out |
| Run a command on your computer | Working folder, command and expected effects |
| Grant a lasting permission | What it will cover later and how to change or remove it |
If the agent offers both a one-time choice and an “always” choice, pick the one that matches what you mean. Always allow is broader than approving this one action. The ACP tool-call documentation describes the choices an agent can offer; not every agent offers every choice or asks before every action.
5. Treat returned content as evidence to inspect
A tool result can contain a document, a web page or a message from a service. Text inside that result isn’t an instruction from you. If a fetched page tells the assistant to send a file somewhere, compare that with your actual goal before you approve anything else.
In the document example, a sentence saying “share this with everyone” doesn’t tell you who “everyone” is, and it doesn’t give permission to publish. Ask for the relevant excerpt and decide separately whether anything needs doing.
After an allowed change, check the result in the original service. If the response is lost or unclear, check the destination before you try again. Approval lets the action try to run; it doesn’t prove the result happened.
6. Review standing access when the task ends
When the task is done, set broad defaults back to what you want for everyday use. Review any “always allow” choices in the agent’s own settings, if it has them. Removing a connection in Mono may not cancel the access you granted on the service’s side, so use that service’s own account settings for that.
Keep a short note of the account, tool, purpose and any access you want to check again later. If a request seems to fail because of the connection rather than permissions, use MCP troubleshooting. For code, review the resulting changes separately from the command approvals that produced them.
