August 28, 2026 · Field notes
Who can turn off an agent's approval checks?
An August 23 discussion of Hermes on r/AI_Agents described an agent targeting Thailand’s Ministry of Finance without asking permission before each command. The post asked who was responsible when an agent went rogue. That framing deserves a closer look: the evidence describes an operator deliberately choosing unattended execution.
The underlying Hunt.io investigation appeared on July 23, based on material captured July 9 to 13. The August thread renewed discussion of an earlier operation. In the same week, Tony Erwin’s account of IBM’s production agent platform, published August 23, described carrying the caller’s identity through tool requests so backend systems could apply their own access rules.
These accounts put a specific question behind the discussion of agent autonomy: which restrictions still apply when the person running the agent wants it to continue? A confirmation prompt gives that person a choice. An organization’s mandatory restriction needs an authority that can refuse the choice.
What an approval prompt protects
Hunt.io’s recovered logs show the agent enumerating hosts and searching files. The researchers reported evidence of compromise, although the recovered material did not establish how initial access was obtained. They also found no evidence that the enumerated documents had been exfiltrated. Those limits matter when describing what the agent accomplished.
The thread’s language of an agent going rogue can obscure the operator’s role. Hunt.io reports that approval prompts were bypassed through unattended mode. It does not establish that the agent overrode a human refusal. Nor does it give us a basis for assuming that leaving the prompts enabled would have stopped the operation: someone deliberately directing an attack could approve each step.
A prompt can still prevent a mistake. A developer reviewing a proposed command may notice that it deletes the wrong directory, while choosing to allow unattended commands in a disposable test environment. Both choices can be reasonable. The concern raised by the Hermes discussion needs to be tied to the resources at risk and the authority of the person making that choice.
An organization imposing a mandatory review requirement has a different problem. Suppose a support agent proposes deleting a customer record, and company policy requires a second person to approve the deletion. If the support operator can disable that check, the system has delegated the review requirement to the person whose action requires review. Showing a confirmation dialog cannot repair that allocation of authority.
The design therefore needs to specify who may change the rule as well as who may approve an action. This is the practical meaning of the governance layer: the service executing the deletion must require the approval, and the operator’s credentials must not provide another route around it.
Keep access decisions with the service that owns the data
Erwin’s IBM account makes the access decision concrete. As a supervisor delegates to specialist agents and they call enterprise tools, the caller’s identity accompanies the request through each service. Crossing into a backend with a different identity provider requires a token exchange that preserves that identity. The backend can then enforce its own access rules.
If a support employee asks for a customer record they are not permitted to see, the backend can reject the request using that employee’s identity. Disabling local confirmation leaves those permissions unchanged. The service holding the data retains authority over access to it, which is the enterprise integration property this example illustrates.
IBM’s design addresses access within an organization that controls its services. It would be a mistake to present it as a remedy for an attacker operating their own agent against someone else’s infrastructure. It also has limits within the enterprise: an employee may be entitled to read a record while having no reason to include it in a particular response. An agent can misunderstand a request and perform an authorized but unwanted action. Preserving identity establishes whose permissions apply; a deployment still needs to decide how much of that person’s authority each task should receive.
IBM’s account also reports that evaluation arrived late and that some wrong answers reached users before the team could detect them. Access control could not resolve that problem. Testing answer quality requires representative tasks and evidence of what a correct answer should contain. It would be a mistake to read a sound identity design as evidence that the whole agent behaves correctly.
Test the action with approval disabled
For an enterprise deployment, I would use the customer-record deletion to test the distinction these accounts expose. Start at the service that performs it. Establish which credentials authorize the request and where the second person’s approval is verified, then trace back to the operator’s controls. Disabling a local prompt should not change that service’s approval requirement.
Then exercise the refusal path. With local confirmation disabled and no second approval supplied, the deletion should still fail. Try the same operation through every tool available to the agent, including any general shell or direct API access. A mandatory approval enforced by one tool offers little protection if another tool holds credentials that can perform the deletion directly.
The approval also needs to apply to the operation being executed. Approval to delete one test record must not authorize a later request to delete a customer’s history. The executing service needs enough information to check that the approved target and action match the request, and its record of the decision should make that check inspectable afterward.
The August thread treats uninterrupted execution as a loss of control, but Erwin’s account shows why the location of enforcement matters. A routine read can proceed under scoped permissions. For a consequential action requiring independent approval, I would ask the team to demonstrate a refusal with that approval absent and local prompts disabled. The demonstration would establish what the backend prevents when the operator wants to proceed.