The primary claim I make in Why Authorization is the Hard Problem in Agentic AI is that static authorization models are insufficient for systems that plan, act, and replan over time. In agentic systems, authorization cannot be a one-time gate checked before execution begins. It must be evaluated as part of the agent's control loop. Why Authorization is the Hard Problem in Agentic AI In this post, I'll walk through a concrete demo that shows what this looks like in practice. Using OpenClaw and Cedar, we modify the agent loop so that every tool invocation is authorized by policy at runtime. Denial does not terminate execution. It becomes feedback that guides what the agent does next. The full demo is available on GitHub. The repo includes a Jupyter notebook that walks through some standalone tests and runs through an OpenClaw demo as well. The goal of this post is to explain what is happening and why it matters. full demo is available on GitHub The Problem: Static Authorization in a Dynamic Loop As discussed in the post I link to above, agent frameworks like OpenClaw make the agent loop explicit. A single goal can unfold into multiple tool invocations, interleaved with observation, reasoning, and replanning, rather than a single, discrete request. This iterative structure is fundamentally different from a traditional request–response system, and it is what makes continuous authorization necessary. Many authorization mechanisms, like role-based access control, assume a static shape: Permissions are assigned ahead of time
Authority is attached to an identity in the form of a role
A decision is made once and assumed to hold Permissions are assigned ahead of time Authority is attached to an identity in the form of a role A decision is made once and assumed to hold That model breaks down as soon as an agent starts adapting its behavior. The same agent, with the same identity, may attempt different actions for different reasons as context changes. Authorization must track why an action is being attempted, not just who is attempting it. Authorization Inside the Agent Loop To address this mismatch, authorization has to move inside the agent loop itself. In a system like OpenClaw, every proposed tool invocation becomes a decision point where authority is evaluated in context. The following diagram shows what this looks like when authorization is made explicit inside the agent loop. The diagram illustrates a policy-aware agent loop adapted from OpenClaw's architecture. The loop begins with a goal that defines the delegation: purpose, scope, duration, and conditions. This delegation does not grant standing permissions. Instead, it constrains the space in which the agent is allowed to plan and act. From that goal, the agent produces a plan with the help of an LLM. The plan represents a tentative sequence of steps rather than a commitment to act. As the agent moves into plan execution, each step is treated as a proposed action. Before any action is executed, it is intercepted by a policy enforcement point (PEP). The PEP constructs an authorization request and consults a policy evaluation service, implemented here using Cedar. The policy evaluation uses both static policy and dynamic context to determine whether the proposed action is permitted under the current delegation of authority. If the action is permitted, execution proceeds and the tool or function is invoked. The result of that execution updates the agent's context and feeds into the next iteration of the loop. If the action is denied, the loop does not terminate. The denial is returned to the agent as a structured result, including the reason for the denial and, where appropriate, hints about what might be allowed. That denial becomes a productive signal. It feeds back into planning, narrowing the agent's options, triggering replanning, or prompting the agent to seek approval or adjust its approach. This is the key modification to the agent loop: Authorization becomes a feedback signal inside the loop, shaping what actions the agent can consider and attempt next. By inserting authorization explicitly into the cycle, policy becomes part of the control structure that governs agent behavior. As plans evolve and conditions change, delegation is continuously enforced, ensuring the agent remains within the bounds of the authority it was given. The Cedar authorization demo described below implements this loop directly. It inserts a PEP into the OpenClaw execution path and uses Cedar as the policy evaluation point for every tool invocation, demonstrating how static authorization models give way to dynamic, policy-based control in agentic systems. The Cedar Authorization Demo With the policy-aware agent loop in mind, we can now look at how this model is implemented in practice using Cedar. The Cedar Authorization Demo for OpenClaw Github repository contains a working demonstration of how Cedar can be used with OpenClaw. Cedar Authorization Demo for OpenClaw Github repository The demo modifies OpenClaw by inserting a policy enforcement point (PEP) immediately before tool execution and routing authorization decisions to an external policy decision point (PDP) backed by Cedar. The agent itself contains no authorization logic. It simply incorporates each policy decision into its normal execution flow. Rather than walk through the code line by line here, the demo repository includes a detailed README that explains exactly how the system is wired together. The README documents: demo repository includes a detailed README How the PEP is inserted into the OpenClaw execution path
The shape of the authorization requests sent to the Cedar PDP
The Cedar schema, policies, and entities used in the demo
The specific files that were modified or added
Step-by-step instructions for running the demo locally How the PEP is inserted into the OpenClaw execution path The shape of the authorization requests sent to the Cedar PDP The Cedar schema, policies, and entities used in the demo The specific files that were modified or added Step-by-step instructions for running the demo locally If you want to run the demo yourself, start with the README in the demo directory of the repository. It is designed to be followed end to end, and includes instructions on installing and running Cedar, building OpenClaw in the repo with the changes, and how to configure it to use the authorization service. demo For readers who prefer to see the system in action before running it, I've recorded a short walkthrough video. The video shows a number of requests, some denied and some permitted. Watching the video makes it easier to see how authorization decisions feed back into the agent loop without terminating execution. short walkthrough video When Cedar denies a proposed action, the tool is not executed. But the agent run does not fail. Instead, the denial is returned to the agent as a structured result that includes the reason for the decision and, where appropriate, hints about what conditions might allow the action to proceed. From the agent's perspective, this denial is simply another observation to incorporate into its reasoning. The demo shows how replanning works as well. This behavior mirrors the loop shown in the diagram. A denial feeds back into planning, narrowing the set of viable next actions. The agent may choose a safer alternative, request clarification, seek approval, or abandon the goal entirely. demo shows how replanning works as well Together, the README and the video serve as the concrete companion to the earlier diagram. The diagram explains where authorization lives in the agent loop and why it must be evaluated continuously. The demo shows that this model can be implemented cleanly today using an existing agent framework and a deterministic policy engine. What the Policies Enforce The policies used in the demo are intentionally simple. They are not meant to be exhaustive or production-ready. Instead, they illustrate how policy evaluation fits naturally into the agent loop shown earlier. policies used in the demo Examples include: Permitting safe read-only actions
Denying actions that would modify protected resources
Denying actions that exceed the scope or conditions of a delegation
Permitting previously denied actions once additional conditions are satisfied Permitting safe read-only actions Denying actions that would modify protected resources Denying actions that exceed the scope or conditions of a delegation Permitting previously denied actions once additional conditions are satisfied What matters is not the specific rules, but the timing of their evaluation. Each policy is evaluated at the moment an action is proposed, using the current context available to the system. Because policies are evaluated repeatedly, the same agent may receive different decisions for different actions within the same run. This is precisely what static authorization models cannot control. Zero Trust for Agents Nothing in this demo relies on long-lived roles, scopes, or static permissions. The agent's identity remains the same throughout the run. What changes is the sequence of proposed actions, the intent behind them, and the context in which they occur. Seen through this lens, continuous authorization inside the agent loop is not a new idea at all. It is Zero Trust applied to autonomous systems. Traditional Zero Trust architectures reject implicit trust based on network location or prior authentication. Instead, they evaluate access continuously, using current context, and assume that any privilege may need to be constrained or revoked. Agentic systems demand the same posture, but applied to behavior rather than connectivity. Zero Trust principle

Agentic authorization analogue



No implicit trust

No standing authority for agents



Continuous verification

Authorization evaluated at every step



Context-aware decisions

Policy evaluated with runtime context



Least privilege

Delegation scoped by purpose and duration



Assume breach

Denial is expected and informative Zero Trust principle

Agentic authorization analogue



No implicit trust

No standing authority for agents



Continuous verification

Authorization evaluated at every step



Context-aware decisions

Policy evaluated with runtime context



Least privilege

Delegation scoped by purpose and duration



Assume breach

Denial is expected and informative Zero Trust principle

Agentic authorization analogue Zero Trust principle Zero Trust principle Agentic authorization analogue Agentic authorization analogue No implicit trust

No standing authority for agents No implicit trust No implicit trust No standing authority for agents No standing authority for agents Continuous verification

Authorization evaluated at every step Continuous verification Continuous verification Authorization evaluated at every step Authorization evaluated at every step Context-aware decisions

Policy evaluated with runtime context Context-aware decisions Context-aware decisions Policy evaluated with runtime context Policy evaluated with runtime context Least privilege

Delegation scoped by purpose and duration Least privilege Least privilege Delegation scoped by purpose and duration Delegation scoped by purpose and duration Assume breach

Denial is expected and informative Assume breach Assume breach Denial is expected and informative Denial is expected and informative In a Zero Trust model, access is never assumed to persist simply because it was previously granted. In an agentic system, authority cannot be assumed to persist simply because earlier actions were permitted. Each proposed action must be evaluated in context, at the moment it is attempted. The policy-aware agent loop makes this requirement visible. Authorization moves from a one-time gate at the edge of execution to a continuous feedback signal inside the loop. Policy does not just block unsafe actions. It shapes behavior by constraining what the agent can consider next. From Demo to Delegation This demo focuses on authorizing individual actions inside an agent loop, but its implications are broader. Once authorization is evaluated continuously and fed back into planning, it becomes clear that authority is no longer just about which actions are allowed. It is about why an agent is acting and under what conditions that authority applies. That shift leads naturally to delegation. Delegation ties authority to purpose, scope, duration, and conditions, and it requires policy to enforce those bounds at runtime. The same mechanism used here to authorize tool execution can be extended to govern delegated authority across longer-running tasks and, eventually, across multiple agents. The policy-aware agent loop makes this progression explicit. Authorization decisions are no longer one-time gates. They are feedback signals that shape behavior, constrain autonomy, and guide replanning as context changes. Static authorization models cannot support this kind of control. Dynamic, policy-based authorization can, and it is what makes delegation enforceable without embedding brittle logic into agents or tools. In the next post, I'll focus directly on delegation: what it means in agentic systems, how it differs from roles and impersonation, and why delegation must be expressed and enforced through policy rather than identity. That discussion sets the stage for capability-based authorization and multi-agent chains.

Authorization Belongs Inside the Agent Loop (Not at the Edge)

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Life-Like Anonymity

2023 Demonstrated How Critical Robust Authorization Really is

161 Stories To Learn About Authentication

A Deep Dive Into the JavaScript Some() Method

A Quick Guide to JSON Web Token [JWT]

The Rise of DID Authorization Mechanism in Client-Server Model

Life-Like Anonymity

2023 Demonstrated How Critical Robust Authorization Really is

161 Stories To Learn About Authentication

A Deep Dive Into the JavaScript Some() Method

A Quick Guide to JSON Web Token [JWT]

The Rise of DID Authorization Mechanism in Client-Server Model

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps