Approvals and permissions

Automate

Before an agent runs a tool, MaShop returns one of three verdicts: forbidden, your signature is required, or allowed.

How the verdict is reached

The full order is set out in Tool permissions. Three of its consequences matter on this screen.

• A tool the agent's own sheet forbids is refused first. Nothing else is consulted.
• A tool set to Allow runs even for an agent that normally prepares and waits. Allow comes before autonomy.
• Verbs with no effect run on their own: reading, listing, computing, comparing, drafting, checking, preparing.

That last line works from a list of permitted prefixes, not a list of dangerous ones. A verb nobody planned for is not assumed safe. It asks you.

Permissions are set tool by tool, in a connector's sheet, reached from the connected apps in your account settings. Untouched, a read tool sits on Allow and everything else sits on Ask. Only the owner changes a permission, attaches a connector or removes one.

What the queue shows

Approvals lists what your agents prepared and could not finish alone. One card per request: what the agent proposes, a preview when there is one, who prepared it and when.

Every card carries the same box, stating what your signature triggers and that MaShop cannot undo it. The box appears even when the request cannot be read. It then says the request cannot be signed as it stands, which is the correct answer to an unreadable instruction.

What signing actually runs

Sign executes the call the queue was holding, with the arguments you read, at the moment you click. The run then goes back in the queue and carries on from there. No route reverses that call.

One case behaves differently, and it is the most common one today. An email draft is not held back. The tool files the card itself and finishes on the spot, so no call waits behind it.

Signing that card therefore changes nothing. The screen answers that no action was held by this signature, which is exactly what happened.

MaShop does not send email

There is no sender. No tool in MaShop puts a message in anybody's inbox, and no button on this screen does either.

The draft is the finished product. Copy it from the card, then send it from your own mailbox. That is the last step, and it is yours.

The card keeps the recipient, the subject and the first 400 characters of the body. A longer message is cut there, so keep drafted messages short enough to read on the card.

Sign, Always, Refuse

Action	What it does
Sign	Runs the held call, then puts its run back in the queue. Nothing reverses it.
Always	Signs now and stops asking for this action. It is absent on anything touching money, where a standing approval is refused by the database.
Refuse	The card leaves the queue. No reason field is shown here, and the message points you back to the agent.
Select, then sign the batch	Processes your selection one by one and stops at the first refusal from the server, so a queue is never left half signed.

Checkboxes only appear on cards you are allowed to decide. Decisions are limited to 30 per minute.

Who signs what

The verb decides, not the amount. A verb that moves money requires the owner's signature, whether it is one euro or ten thousand. The owner can open that right to editors, and it is the only line that can be opened.

A request MaShop cannot read is treated as the most expensive case, and needs the same signature.

When a button is off, the screen says why: only the owner signs for money, or your role does not allow signing.

Correcting a request

There is no correct button, and nothing amends a pending request. Refuse it, then tell the agent in the chat what has to change. It files a new request.

This is deliberate. The right to sign is derived from the verb, so letting the screen rewrite the verb would let someone turn a refund into an email and sign it themselves.

What fills this queue today

MaShop runs two tools of its own. One reads rows from your own database, read only, and needs Supabase connected on the project. The other prepares an email, records it here, and sends nothing.

A connected MCP server adds its own tools to that. They are relayed to the service and run there, under the same permission guard, with 20 seconds per call and 4 000 characters of the answer kept. One of those set to Ask does hold a real call, and signing it does run it.

When a tool sits on Ask, the request is written before anything runs. If that write fails, the action is refused and nothing is attempted.

Where to see what is waiting

No counter badge sits on the tabs. The Briefing screen shows how many actions await your signature, and its sign button takes you to the queue. Check one of the two screens rather than waiting for a notification.