{"slug": "i-wanted-to-find-out-if-agent-authorization-actually-follows-the-action-to", "title": "I wanted to find out if agent authorization actually follows the action to execution", "summary": "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.", "body_md": "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.\n\nThere's a lot of discussion around securing AI agents: permissions, prompt injection, sandboxing, identity, human approval, and so on.\n\nAll of that matters.\n\nBut I kept coming back to a much simpler question:\n\n**When an agent is authorized to perform an action, what actually guarantees that the same action is what eventually gets executed?**\n\nThat became the thing I wanted to test.\n\nTake a simple example.\n\nAn agent wants to refund a customer:\n\n```\nrefund_customer(\n    customer_id=\"123\",\n    amount=100\n)\n```\n\nThe authorization layer evaluates the request and approves it.\n\nBut what exactly did we authorize?\n\nThe tool?\n\nThe arguments?\n\nThe target?\n\nThe agent identity?\n\nThe runtime context?\n\nThe policy state?\n\nOr the actual executable capability?\n\nNow imagine that something changes between the authorization decision and execution:\n\n```\nAuthorized:\nrefund_customer(customer_id=\"123\", amount=100)\n\nExecuted:\nrefund_customer(customer_id=\"123\", amount=1000)\n```\n\nThe original authorization decision wasn't necessarily wrong.\n\nThe problem is that the thing being executed isn't the thing that was authorized.\n\nThat's the boundary I wanted to investigate.\n\nI wanted the test to be framework-neutral.\n\nRather 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.\n\nI focused on the things that materially define an action:\n\nThe basic property is pretty straightforward:\n\nIf something materially changes between authorization and execution, the execution should be rejected.\n\nI'm not saying existing agent frameworks don't do this.\n\nIn 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.\n\nThat's one of the things I'm trying to find out.\n\nThis wasn't originally supposed to be a security research project.\n\nI 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.\n\nThe initial testing found two high-severity issues in my implementation.\n\nOne involved authorization potentially being associated with something other than the exact execution inputs.\n\nThe other involved the execution path allowing a caller to supply an arbitrary callable.\n\nThose findings were useful because they exposed a distinction I hadn't been thinking about deeply enough.\n\nIt's relatively easy to build something that says:\n\n```\npolicy → allow\n```\n\nIt's harder to guarantee:\n\n```\npolicy\n  ↓\nauthorized action\n  ↓\nexact execution capability\n  ↓\nactual callable\n```\n\nand that nothing important can change along the way.\n\nI redesigned the execution model around that idea, using an immutable execution snapshot and capability-bound execution rather than reconstructing execution from caller-controlled inputs.\n\nThe 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.\n\nIt passed 39/39 tests.\n\nThat'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.\n\nIt just means the implementation survived the tests that were run against it.\n\nThe question I'm interested in now isn't:\n\n**\"Do AI agents need security?\"**\n\nObviously they do.\n\nIt's:\n\n**Does existing agent infrastructure already guarantee that authorization remains attached to the exact action that reaches execution?**\n\nAnd if it doesn't:\n\n**Is that gap actually painful enough that developers care about fixing it?**\n\nThose are very different questions.\n\nI'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.\n\nI'm less interested in what the architecture is supposed to do than what actually happens when it runs.\n\nWhere is authorization decided?\n\nWhat exactly is being authorized?\n\nWhat happens if the arguments change?\n\nWhat happens if the target changes?\n\nWhat happens if the identity or runtime context changes?\n\nIs the final callable itself protected, or are you relying on the layers above it to preserve the authorization decision?\n\nAnd has any of this actually caused a problem in your system?\n\nThat's the part I'd really like to hear about.\n\nI've put a framework-neutral version of the experiment in the AgentGuard repository.\n\nThe idea is simple.\n\nPick a consequential tool in your existing agent system.\n\nFind where authorization happens.\n\nWrite down exactly what was authorized.\n\nThen change something material between authorization and execution and see what happens.\n\nTry the arguments. Try the target. Try identity. Try the execution capability. Try replay or expiry.\n\nIf the system rejects the modified action, great.\n\nIf it doesn't, that's interesting too.\n\nI'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.\n\nAgentGuard is my implementation experiment around this particular boundary.\n\nIt'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.\n\nThe basic idea looks like this:\n\n```\nAgent\n  ↓\nTool request\n  ↓\nAuthorization\n  ↓\nExecution-bound capability\n  ↓\nActual callable\n```\n\nThe 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.\n\nBut I'm deliberately keeping the conclusion open.\n\nIf existing frameworks, gateways, IAM systems, middleware, or application-level controls already provide the same guarantee, then AgentGuard may not add much value.\n\nThat's exactly what I want this experiment to determine.\n\nI've put the experiment here:\n\n**AgentGuard:**\n\n[https://github.com/Brodin2001/Agentguard](https://github.com/Brodin2001/Agentguard)\n\nThe execution-boundary test is in:\n\n`docs/execution-boundary-challenge.md`\n\nThe first developers who tested the idea pointed out that action binding is only one part of the execution-boundary problem.\n\nOne 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.\n\nThat suggests the experiment needs to distinguish at least three properties:\n\nAction integrity — the action executed is the action authorized.\n\nBoundary exclusivity — consequential execution cannot bypass the authorization boundary.\n\nAuthority freshness — authority is still valid when the consequence commits.\n\nThat'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.\n\nIf you try it, I'd be interested in seeing what happened rather than getting a generic opinion.\n\nSomething as simple as:\n\n```\nFramework:\nAuthorization approach:\nAction tested:\nWhat changed:\nResult:\n```\n\nwould be useful.\n\nIf your architecture passes, tell me.\n\nIf it fails, tell me.\n\nIf you have some awkward workaround that technically works but you don't like, that's probably even more interesting.\n\nI'm trying to figure out whether there's a real problem here before spending more time building around it.\n\nIf the answer is that existing systems already handle this properly, I'll learn something.\n\nIf the answer is that they don't, and developers actually care, then I'll have a much better idea of what to build next.\n\n— Brodin\n\nThe 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.", "url": "https://wpnews.pro/news/i-wanted-to-find-out-if-agent-authorization-actually-follows-the-action-to", "canonical_source": "https://dev.to/brodin2001/i-wanted-to-find-out-if-agent-authorization-actually-follows-the-action-to-execution-1kmh", "published_at": "2026-09-15 02:01:59+00:00", "updated_at": "2026-09-15 02:31:15.177226+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "ai-infrastructure", "developer-tools"], "entities": ["AgentGuard", "OpenWorkProof"], "alternates": {"html": "https://wpnews.pro/news/i-wanted-to-find-out-if-agent-authorization-actually-follows-the-action-to", "markdown": "https://wpnews.pro/news/i-wanted-to-find-out-if-agent-authorization-actually-follows-the-action-to.md", "text": "https://wpnews.pro/news/i-wanted-to-find-out-if-agent-authorization-actually-follows-the-action-to.txt", "jsonld": "https://wpnews.pro/news/i-wanted-to-find-out-if-agent-authorization-actually-follows-the-action-to.jsonld"}}