An outside test found AgentGuard's executor would run whatever callable the caller supplied

The two initial findings are more useful than the framing around them. The first was authorization being associated with something other than the exact execution inputs ^[4]. The second was an execution path that allowed a caller to supply an arbitrary callable ^[5]. The second is the one I would check first in someone else's stack. A decision that approves the name `refund_customer` and a pair of arguments still leaves the caller choosing which code runs. That path tends to survive code review, because it looks like dependency injection.

The test was meant to be framework-neutral: the author looked at what happens where a consequential action reaches the executor ^[12]. He listed eight things he treats as materially defining an action: tool or capability, arguments, target or resource, agent identity, runtime identity or context, authorization state, authorization expiry, and execution capability ^[3]. The rule he wants from that list is one sentence. "If something materially changes between authorization and execution, the execution should be rejected," he wrote ^[2].

The worked example is a refund. Authorized: `refund_customer(customer_id="123", amount=100)`. Executed: `refund_customer(customer_id="123", amount=1000)` ^[1]. Nothing carried the policy decision on the first call forward to the second.

On the fix, the author wrote that he "redesigned the execution model around that idea, using an immutable execution snapshot and capability-bound execution rather than reconstructing execution from caller-controlled inputs" ^[6]. Read literally, that means the callable is fixed when the decision is made, and the executor does not resolve it again from whatever the caller hands over at call time.

Then the numbers. The retest was independent and adversarial, covering argument changes, target changes, agent identity, runtime identity, capability substitution, replay, expiry, stale policy state and legitimate execution, and it passed 39 of 39 tests ^[7]. Nine named categories over 39 tests is about four tests per category, and fewer if the list is partial ^[15]. The author's own caveat is the right one to quote: "It isn't a security certification and it doesn't prove that this is a universal problem," he wrote ^[9]. The post does not identify any framework he tested for the property ^[16].

That last point is what keeps this from being a general indictment of agent security work. The open question in the post is whether existing agent infrastructure already keeps authorization attached to the exact action that reaches execution, and whether the gap hurts enough for developers to fix it ^[13]. He names the answer that would sink his own project: "In fact, if they already guarantee this properly, that's useful information. It would mean there may be little reason for another runtime authorization layer to exist," he wrote ^[10].

Adopting the rule has a price. Authorization expiry is one of the eight bound properties ^[3], so a human approval that sits in a queue past its expiry has to go back for a new decision. Any retry that re-serializes arguments, normalizes a currency amount or attaches an idempotency key changes the inputs the snapshot was taken over, which under the stated rule is a rejection ^[2]. For the class of actions the author is interested in, including refunds and payments, database writes, infrastructure changes and privileged API calls ^[14], failing closed on a mutated retry is the behaviour you want. It is also the behaviour that will page you at 3am the first week.

The finding came from outside. According to the post, this was not originally a security research project, and OpenWorkProof's testing requirement forced the closer look at whether authorization was bound to execution or merely associated with an action ^[11].