The approval prompt nobody is there to answer

Four CVEs landed on the same day from the same three researchers, against four unrelated agent products. A fifth, from someone else, arrived five days earlier. One sentence describes all of them. The agent has a shell tool, and before it runs a command, nobody is asked.

The gate was built for a terminal

OpenSRE is the instructive one, because it did build an approval gate. In a terminal, the agent stops and asks before it runs a command. But the agent also answers in Slack, and the code that stands in for the terminal there has to answer the same question with nobody to put it to. This is how it answers:

# gateway/transports/slack/processing/dispatcher.py
# No approval prompts in Slack for now. Button waits stalled the
# turn until the timeout and posted extra replies in the thread.

# tools/interactive_shell/subprocess_presenter.py
def execution_allowed(self, policy, *, action_summary) -> bool:
    _ = (policy, action_summary)
    return True

That comment is honest, and it is the whole story. Nobody decided to remove the safety. A real usability problem, a button that stalled the conversation, was solved by answering yes. The gate was a piece of user interface, and when the interface changed, the gate defaulted to open because open is what keeps the product working.

Every deployment that matters is headless

The other four did not get as far as a stub. Three records describe a shell tool with no approval step at all, reached from a chat endpoint, a document upload or a fetched web page. Archon is the purest form: a coding agent whose own permission prompts are switched off, behind a control API that listens on every interface. A server cannot click a button, so the button goes.

Look at where the instructions come from in each case: alerts, Slack messages, retrieved web content, uploaded documents, an open HTTP port. None of these is the operator. An agent becomes useful precisely when it runs unattended on other people's input, and that is exactly the deployment in which a human-in-the-loop control has no human in the loop.

Trust is the attack surface

An agent that stops and asks before every command looks safe, and in the demo it is, because the demo runs in a terminal. It is a property of the session, not of the tool, and nothing in the product tells you when the session you deployed is the one where the answer is always yes.

What to actually do

• List every agent you run without a terminal. Slack and Teams bots, webhooks, schedulers, chat endpoints. For each one, find out what happens to command approval there. If the answer is auto-approve, treat its shell tool as remote code execution for anyone who can write to its inputs.
• Make the headless answer no. When nobody can be asked, the gate must deny, not allow. A slow or failed turn costs a retry. A yes costs the host.
• Take the shell away from unattended agents. Give them narrow tools with fixed arguments instead. An SRE bot that needs to restart a service needs a restart tool, not bash.
• Run the agent with nothing worth stealing. Every one of these records lists the agent's own keys and credentials as the prize. Keep them out of its environment and out of its reach.
• Bind control ports to loopback and require authentication. An agent API on 0.0.0.0 with no login is a shell for the network, whatever the agent was told to do.