The Shape of Context in Agentic Authorization
Summary: In agentic systems, the principal, action, and resource are often unknown until the moment an agent acts, and the context that governs the decision arrives as a flood of signals from many sources. This post looks at how that context takes shape, where each signal is actually consumed, and why a non-directed world of agents still needs decisions that humans can inspect and predict.
This post is part of a series on using dynamic authorization to control and coordinate AI agents. See the series recap to find other posts in this series.
Agentic AI is still early, and the architectures, protocols, trust models, and operational patterns for agent-based systems will almost certainly change as organizations gain experience with them. The details of MCP, tool invocation, delegation, agent-to-agent interaction, and runtime governance are still being worked out. But the broad authorization problem is already visible: agents need a way to decide what they are allowed to do, what context matters, whose authority they are exercising, and when a requested action must be refused. Most of the difficulty in answering those questions lives in one word from the PARC model: context. A reviewer of a draft of my upcoming book on authorization pushed on exactly that point, arguing that I had underplayed how complicated context becomes once agents are talking to agents, and he was right; this post is my attempt to think through that complication.
Agentic systems change the shape of authorization context. In a conventional application, the policy decision often begins with a familiar question: can this employee, application, or service perform this action on this resource? The principal, action, and resource are usually known to the system in advance, and the relevant context can be collected from a small number of well-understood sources. The decision is nearly self-contained, and an engineer can reason about it by reading a small number of policies.
The signals multiply
Agentic systems are different. An agent may act on behalf of a person, another agent, an organization, or some combination of delegated authorities. It may call tools, consult other agents, transform data, and produce intermediate results before it ever touches the resource that ultimately matters. The principal, action, and resource are no longer fixed at the start; they emerge as the agent plans, and the context that governs each step arrives as a flood of signals rather than a tidy record.
Those signals come in many kinds, and they come from many places. A single decision might have to weigh the initiating principal’s intent, the scope of delegation, consent constraints, personal preferences, organizational policy, data sensitivity, tool capabilities, resource state, risk signals, provenance, and the guardrails imposed by the agent platform or the enterprise. Some of these are stable and institutional, such as a company’s data-handling rules. Others are ephemeral and task-specific, such as the fact that this particular request is two hops removed from a human who only asked for a summary.
It helps to sort these signals by what they actually constrain. Some describe who is really asking and under what authority, such as delegation scope, initiating principal, and consent. Some describe what is at stake, such as data sensitivity, resource state, and tenant boundaries. Some describe how much to trust the request itself, such as provenance, risk scores, and the guardrails the platform is already enforcing. Naming the categories does not make the decision simple, but it keeps the flood from looking like undifferentiated noise.
Signals move through a mesh
Listing the signals is the easy part. The harder question is where each one is consumed, because a request rarely travels in a straight line from a person to a resource. It passes through a mesh of agents, each of which may plan, delegate, and call the next agent in turn. A signal that is decisive at one hop may be irrelevant at the next, and a signal that no intermediate agent cares about may be exactly what the resource needs to see.
Consider a person who asks a coordinating agent to reconcile an invoice, which calls a data-gathering agent, which in turn calls a tool that reads from the finance system. The person’s intent to “reconcile, not pay” has to shape what the coordinating agent is even willing to plan, but it cannot stop there; it has to travel all the way to the last hop so the finance system itself refuses a payment even if some agent in the chain proposes one. The delegation scope has to make the same journey, arriving intact so the finance system can confirm the request stays inside it. A freshly computed risk score on the intermediate data, by contrast, may matter only to the agent that produced it, and never needs to leave that hop at all.
So signals have distinct audiences. Some are steering signals that constrain the behavior of the next agent in the chain, and they need to be carried forward, narrowed, and re-evaluated at each hop. Others are enforcement signals that matter only at the point where authority finally lands on a resource, and they need to survive the whole journey without being flattened or forged along the way. And some are both: the intent in the example steers the coordinating agent’s early planning and still has to be enforced at the finance system, so it must be narrowed as it travels and honored when it arrives. Treating every signal as if it belonged everywhere produces both over-sharing and under-enforcement. Deciding, per signal, who consumes it and where is a large part of designing an agentic authorization system.
There is also a limit to how much of this the calling mesh gets to decide. The system behind an API or MCP server almost always has its own authorization, and it may be governed by a different organization entirely. The MCP server is a way to reach that system, not the place where authority finally lands; the finance system, the database, or the file server enforces its own policy no matter what the agents upstream concluded. Authorization here is layered rather than singular, and no single decision point speaks for all of them.
This is where policy constraints that can be queried along the way earn their keep. If a downstream resource can advertise what it will and will not permit, or answer a “would this be allowed?” question before an agent commits to a plan, the agents upstream can shape their behavior to fit instead of discovering the boundary only when an action is refused. It also raises the bar for the signals a request carries, because the delegation and context have to stay legible to a policy engine the initiating organization does not control.
A non-directed world
There is a deeper shift underneath all of this. Traditional access control is directed and largely static: the system knows that Alice has access to the finance application, the finance application knows Alice, and the relationship is established before either of them does any work. The set of principals is small and enumerable, and the resource can hold a model of who is allowed to knock on its door.
Agentic systems are non-directed. A resource backend has no reliable way to know, in advance, which agent will arrive in the next minute or on whose behalf it will be acting. The requester may be an agent that did not exist 5 minutes ago, spun up to handle one task and then discarded. In that world, identity established ahead of time cannot carry the weight it used to, and the resource has to decide what to allow based on the authority and context presented at the moment of the request.
This is exactly where dynamic authorization earns its place. When the resource cannot pre-enroll every principal, the decision has to move to request time and rest on portable evidence: who initiated this, what were they trying to do, what delegation connects them to the agent now asking, and what constraints ride along with it. The point of the signals is to reconstruct, at the moment of the request, the accountability that a directed system used to establish in advance.
Complexity doesn’t change who decides
Faced with dozens or hundreds of signals in a single request, it is tempting to conclude that the decision itself has outgrown human-authored policy, and that we should let a model weigh the signals and decide. I think that conclusion mistakes a hard engineering problem for a change in who should be in charge. The volume of context is real, but it is an argument about how we gather, normalize, and route signals, not an argument for moving the judgment about what is allowed into a system whose reasoning we cannot inspect or reproduce.
The work that genuinely is hard belongs on the input side of the decision. Assembling the signals, resolving them into a consistent shape, summarizing evidence, and scoring risk are all tasks where models and other tooling can help enormously, and where an agent’s flexibility is an asset rather than a hazard. What should stay deterministic is the final question: given this principal, action, resource, and assembled context, is the action permitted? A policy that answers that question can be read, tested, and explained after the fact, which is precisely what the people whose data and money are at stake are entitled to.
Keeping that line clear does not make the policies simple. Deciding which signals a policy consults, and trusting that they were gathered honestly, is a substantial design problem, and it will pull more structure and more tooling into the space around the decision. But the decision stays somewhere a human can point to and understand. Complexity in the context is a reason to build better machinery for handling signals; it is not a reason to hand the judgment itself to a system that cannot tell us why it said yes.
Agentic AI will reshape almost everything about how context is gathered and carried, and much of what I have described here will look primitive in a few years. What I do not expect to change is the shape of the obligation. When authority lands on a real resource on behalf of a real person, someone has to be able to say why the action was allowed, in terms that person could check. Getting the context right is how we make that answer possible; keeping the decision inspectable is how we make sure it stays true.
Photo Credit: The Shape of Context from ChatGPT (public domain)
