Analysis AI for Security & Compliance
Who presses yes: where AI agent tools really ask before they act
By ReviewRamble editors ·
Almost every agent tool says it will check with you before it does something it cannot take back. The question worth asking is where that check lives. It can sit in the agent's instructions, in the client that runs the agent, in a gateway between the agent and the thing it controls, or nowhere at all. Only one of those can stop an agent that has decided not to ask, and even that one has a back door.
This post reads the reviews we published this week for one question: who presses yes. It does not cover screening models and prompt-injection filters, which our guide to guardrails for AI apps and agents deals with, or sandboxes for coding agents, which are in our five-layer guide. Every fact below comes from the reviews and the project documents they cite; we have not run these tools ourselves.
Four places a yes can live
- In the prompt. A line in a skill or a system prompt telling the model to ask first. The model reads it as advice.
- In the client. Claude Code, Codex, Cursor and the rest show an approval prompt before a tool runs. It holds until someone switches it off, and most clients let you.
- In a gateway. A program in the path between the agent and the phone, account or house it acts on, which holds the action until a person answers. This is the only kind the model cannot talk its way past.
- Nowhere. The tool does what it is told, and the only check is whatever the client happens to have switched on.
The prompt: a request, not a lock
Agent Autoloop (3.8) is unusually honest about this. It runs Claude Code or Codex unattended from cron jobs and webhooks, and each rule can carry askFirst, an instruction to check with you before risky steps. The project's own security notes say askFirst is only a request written into the prompt: the agent can ignore it and the hub cannot stop it. What actually limits a run is the access level, which maps to the client's own permission modes, and the full level maps to bypassPermissions in Claude Code and danger-full-access in Codex, meaning no approval for anything.
Google Agent Skills (4.2) shows the same gap from the other side. Its gcloud skill says IAM changes, enabling APIs and deletes need your explicit approval, and in the same file tells the agent to add --quiet to every command so gcloud never stops at its own confirmation prompt. The cloud-run-basics skill enables APIs, grants an IAM role and deploys a public service with --allow-unauthenticated, each with --quiet. The one prompt that a program enforced has been removed, and the one that remains is a sentence the model may or may not follow.
The client: the prompt you can switch off
For most MCP servers, the client's tool-approval prompt is the whole of the safety story. X MCP (3.8), X's official server, has nothing on X's side that asks before a post goes out; without its read-only switch, the only check is your client's prompt, which most clients let you turn off. A post costs $0.015 and a post with a link $0.200, so an agent left to it spends money as well as reputation.
Several tools reviewed this week sit one setting away from that prompt disappearing. Autoloop's full access level is one. llama-modchip (3.6) can start Claude Code against its local model, and its script adds --dangerously-skip-permissions only when MODCHIP_CLAUDE_SKIP_PERMS=1 is set, which is the right default and an easy one to change. The client prompt is a real control, but it belongs to whoever edits the config, and an unattended setup is usually built by switching it off.
A client prompt also does not prove who answered. Call Me (3.6) rings your phone when an agent stops on a question and returns your spoken reply as a transcript. A "yes, ship it" arrives as plain text with nothing to show it was you, the hosted endpoint has no authentication beyond your 10-digit number, and the review is clear that a second confirmation has to come from the agent's own permission settings.
The gateway: the one that holds
Pinky (3.6) is the clearest gateway we have read about. Every tap an agent makes on your phone passes through it. A tap on Pay or Send comes back to the agent as approval_pending, nothing happens on the phone until you click Allow, and no answer within 60 seconds counts as no. Banking and password-manager apps are hidden from agents, and one-time codes reach them as dots. Two limits matter. Out of the box only payments, trades and transfers wait for you, and sends, deletions, calls and installs must be switched on in Settings. And risky buttons are found by their labels in 10 languages, so an odd label can slip through, which is why it offers an ask-before-every-step mode.
Codex Security (4.1) puts the boundary in a sandbox rather than a person. Validation runs read-only with network off; patching, the step that writes, checks its sandbox starts and refuses with SANDBOX_UNAVAILABLE if it does not. The flag --external-sandbox switches that enforcement off and leaves isolation to your container, and Deep-scan workers are read-only but, in OpenAI's words, not an isolated, offline environment.
Stroq (3.8) sits in the agent's hooks and asks you about commands that repeat text the agent has just read from a page, issue or file, and denies curl | sh outright. Its own README calls it a filter, not a sandbox: matching is on text, so a command the model writes from scratch does not trace back to a source, and on Codex and Windsurf the hook can refuse but cannot ask.
Nowhere: tools that just act
HomeMCPBridge (2.8) connects an agent to Apple's HomeKit. Its control_device tool takes a device name and an action, and the actions include releasing a door lock and opening a garage door. In our reading of the source there is no confirmation step, no allow-list and no way to make locks read-only. iPhone MCP (3.2) drives a real iPhone through Apple's mirroring app with no confirmation step, no app allow-list and no read-only mode; its own disclaimer lists unintended messages, deleted data and purchases.
The strongest design in this group is a tool that is not there. WhatsApp MCP (finereli) (3.8) has no send tool, on purpose, so the worst failure of a messaging agent cannot happen. X MCP's read_only=true does the same at the server: tools that post, send messages or change anything are dropped from the list, and the server refuses such calls even if the token has write scopes. A missing tool needs nobody to press anything.
Every gateway has a back door
A gateway only holds if it is the only way in. Pinky's FAQ says it plainly: an agent that can run commands as you can reach an Android phone through adb and skip every rule. Its advice is to sandbox such agents away from the phone, or to plug the phone into another computer and connect to Pinky there over HTTP. That describes Claude Code and Codex in their normal setup, so for most readers the gateway protects the phone only after that extra step.
The same logic runs the other way. A proxy in the path sees everything that passes. billion-context (3.4) sits between a coding agent and its model API to fold old context, which means every prompt and API key passes through it, with no authentication, and it checks npm for a newer version of itself every 3 minutes by default. Before you trust a gateway to hold actions, ask what it can read and who can change its code.
Where the yes lives, tool by tool
| Tool | What it can do that sticks | Where the confirmation lives | How to tighten it |
|---|---|---|---|
| Pinky | Pay, send, delete on your phone | Gateway; payments only by default | Turn on sends and deletions; keep shell agents away from adb |
| Agent Autoloop | Anything the agent CLI can do | Client permission mode; askFirst is a prompt | Stay on edit; give full only where unattended is acceptable |
| Codex Security | Writes patches | Sandbox, unless --external-sandbox | Keep the built-in sandbox; read every patch |
| Google Agent Skills | Deploy, grant IAM roles, enable APIs | Prompt only; --quiet removes gcloud's | Limited project roles, a billing budget, client approvals on |
| X MCP | Publish posts and Articles | Client only, or read_only=true | Start read-only; set a spending cap |
| HomeMCPBridge | Open locks and garage doors | Nowhere | Keep it off agents that run alone |
| Call Me | Carries your spoken approvals | Agent's permission settings | Treat a voice yes as unverified |
| Stroq | Asks about or denies commands | Agent hooks, text matching | Pair with a container or separate account |
Rules you can apply this week
- Find the yes for each irreversible action. For every payment, send, delete, deploy or physical action, write down which program holds it. If the answer is "the prompt says to ask", count it as no confirmation.
- Prefer a missing tool to a confirmed one. A read-only switch or a server with no write tools beats any prompt. Start X MCP with read_only=true, and choose servers that leave out send and delete when the job is reading.
- Turn on what the gateway leaves off. Defaults are narrow. Pinky asks before payments only until you add sends, deletions, calls and installs.
- Close the back door before you trust the front one. An agent with a shell can reach whatever your user account can, adb included. Run it in a sandbox or as a separate user that cannot see the device or credentials the gateway guards.
- Search your configs for the switches. bypassPermissions, danger-full-access, --dangerously-skip-permissions, --quiet and --external-sandbox each remove a prompt. Know where each one is set and why.
- Back the prompt with limits a model cannot argue with. Narrow cloud roles, a billing budget and a spending cap on paid APIs keep working when the agent skips a step.
- Treat a remote yes as unverified. A phone call or chat reply carries no proof of who answered. Keep deploys and payments behind an approval tied to your own sign-in.
The catch: the gateways that hold best are the youngest. Pinky is a week old, Autoloop ten days, Stroq about ten weeks, and their safety notes come from the maintainers rather than outside review. The mature controls, client approval prompts and cloud permissions, are the ones people switch off to make an agent run unattended. There is no tool here that makes an agent safe to leave alone with your money or your front door.
Our take: ask of every agent setup the question you would ask of a new employee with a company card: who signs off, and can they sign off without you? If the honest answer is the employee themselves, there is no sign-off. Put the yes in a program the agent cannot edit, take away the tools the job does not need, and save your attention for the few clicks that matter.