I wanted to find out if agent authorization actually follows the action to execution

A developer building AgentGuard, a runtime authorization layer for AI agents, had the implementation independently tested by OpenWorkProof and found two high-severity issues: authorization could be associated with inputs other than the exact execution inputs, and the execution path allowed callers to supply an arbitrary callable. After redesigning the execution model around an immutable execution snapshot and capability-bound execution, the implementation passed 39/39 adversarial retest cases covering argument changes, target changes, capability substitution, replay, expiry, and stale policy state.

I've been building AgentGuard for a while now, and recently I started questioning whether I was looking at the problem from the right angle. There's a lot of discussion around securing AI agents: permissions, prompt injection, sandboxing, identity, human approval, and so on. All of that matters. But I kept coming back to a much simpler question: When an agent is authorized to perform an action, what actually guarantees that the same action is what eventually gets executed? That became the thing I wanted to test. Take a simple example. An agent wants to refund a customer: refund customer customer id="123", amount=100 The authorization layer evaluates the request and approves it. But what exactly did we authorize? The tool? The arguments? The target? The agent identity? The runtime context? The policy state? Or the actual executable capability? Now imagine that something changes between the authorization decision and execution: Authorized: refund customer customer id="123", amount=100 Executed: refund customer customer id="123", amount=1000 The original authorization decision wasn't necessarily wrong. The problem is that the thing being executed isn't the thing that was authorized. That's the boundary I wanted to investigate. I wanted the test to be framework-neutral. Rather than asking whether a particular framework has a "permission system", I wanted to look at what happens at the point where a consequential action actually reaches the executor. I focused on the things that materially define an action: The basic property is pretty straightforward: If something materially changes between authorization and execution, the execution should be rejected. I'm not saying existing agent frameworks don't do this. 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. That's one of the things I'm trying to find out. This wasn't originally supposed to be a security research project. I was building AgentGuard and had the implementation independently tested by OpenWorkProof. Their testing requirement forced me to look much more closely at whether authorization was actually bound to execution or whether I was just associating an authorization decision with an action and assuming the relationship would hold. The initial testing found two high-severity issues in my implementation. One involved authorization potentially being associated with something other than the exact execution inputs. The other involved the execution path allowing a caller to supply an arbitrary callable. Those findings were useful because they exposed a distinction I hadn't been thinking about deeply enough. It's relatively easy to build something that says: policy → allow It's harder to guarantee: policy ↓ authorized action ↓ exact execution capability ↓ actual callable and that nothing important can change along the way. I redesigned the execution model around that idea, using an immutable execution snapshot and capability-bound execution rather than reconstructing execution from caller-controlled inputs. The subsequent independent adversarial retest covered things such as argument changes, target changes, agent identity, runtime identity, capability substitution, replay, expiry, stale policy state, and legitimate execution. It passed 39/39 tests. That's useful evidence for this implementation, but I don't want to overstate it. It isn't a security certification and it doesn't prove that this is a universal problem. It just means the implementation survived the tests that were run against it. The question I'm interested in now isn't: "Do AI agents need security?" Obviously they do. It's: Does existing agent infrastructure already guarantee that authorization remains attached to the exact action that reaches execution? And if it doesn't: Is that gap actually painful enough that developers care about fixing it? Those are very different questions. I'm particularly interested in people running agents that can do things with real consequences — modifying databases, sending emails, changing infrastructure, writing to production systems, issuing refunds or payments, modifying Git repositories, calling privileged APIs, executing code, or operating across multiple agents and tools. I'm less interested in what the architecture is supposed to do than what actually happens when it runs. Where is authorization decided? What exactly is being authorized? What happens if the arguments change? What happens if the target changes? What happens if the identity or runtime context changes? Is the final callable itself protected, or are you relying on the layers above it to preserve the authorization decision? And has any of this actually caused a problem in your system? That's the part I'd really like to hear about. I've put a framework-neutral version of the experiment in the AgentGuard repository. The idea is simple. Pick a consequential tool in your existing agent system. Find where authorization happens. Write down exactly what was authorized. Then change something material between authorization and execution and see what happens. Try the arguments. Try the target. Try identity. Try the execution capability. Try replay or expiry. If the system rejects the modified action, great. If it doesn't, that's interesting too. I'm not trying to prove that AgentGuard is necessary. I'd actually prefer someone to show me that their existing architecture already solves this cleanly. AgentGuard is my implementation experiment around this particular boundary. It's a small Python runtime layer designed to sit immediately before consequential tool or function execution and enforce authorization against the action that is actually being executed. The basic idea looks like this: Agent ↓ Tool request ↓ Authorization ↓ Execution-bound capability ↓ Actual callable The important part is that authorization isn't treated as something that happened earlier in the agent's reasoning and is therefore assumed to remain valid. But I'm deliberately keeping the conclusion open. If existing frameworks, gateways, IAM systems, middleware, or application-level controls already provide the same guarantee, then AgentGuard may not add much value. That's exactly what I want this experiment to determine. I've put the experiment here: AgentGuard: https://github.com/Brodin2001/Agentguard https://github.com/Brodin2001/Agentguard The execution-boundary test is in: docs/execution-boundary-challenge.md The first developers who tested the idea pointed out that action binding is only one part of the execution-boundary problem. One implementation already revalidates the security-relevant execution context at dispatch. Another pointed out that record-based conformance testing cannot independently establish that a refused action did not execute. A further response identified a separate property: authority freshness when policy changes after authorization but before the external effect. That suggests the experiment needs to distinguish at least three properties: Action integrity — the action executed is the action authorized. Boundary exclusivity — consequential execution cannot bypass the authorization boundary. Authority freshness — authority is still valid when the consequence commits. That's exactly the kind of feedback I'm looking for. If existing architectures already guarantee these properties, that's evidence against the need for another layer. If they don't, the interesting question becomes whether the gap is operationally painful enough to warrant one. If you try it, I'd be interested in seeing what happened rather than getting a generic opinion. Something as simple as: Framework: Authorization approach: Action tested: What changed: Result: would be useful. If your architecture passes, tell me. If it fails, tell me. If you have some awkward workaround that technically works but you don't like, that's probably even more interesting. I'm trying to figure out whether there's a real problem here before spending more time building around it. If the answer is that existing systems already handle this properly, I'll learn something. If the answer is that they don't, and developers actually care, then I'll have a much better idea of what to build next. — Brodin The independent security testing by OpenWorkProof was an important part of this work. Their testing requirement is what pushed me to examine the execution boundary more closely, and the findings materially changed the implementation.