Every Action Was Allowed. The Sequence Was Not.

Here is the sentence in AWS's announcement that I keep returning to: a single tool call can be safe in isolation yet harmful given what preceded it.

Read that as an admission and it gets larger. Every access control most of us have ever configured answers one question at a time. Can this identity perform this action on this resource, right now. AWS is saying that for agents, answering that question correctly, every single time, is not enough.

One action at a time used to be enough

AWS's own framing of the old world is generous and accurate. Before AI agents, it writes, it was generally sufficient for access controls to treat each action as an independent event, because applications relied on deterministic business logic to enforce whether actions happened in the right order or whether data was up to date. That is not a design flaw. In a conventional application the order is in the code. The code does step one, then step two. Authorization only has to police who is allowed to be in the building.

Agents remove that guarantee. AWS puts it plainly: they decide at runtime which tools to call, with which arguments, and in what order. The ordering logic moved out of the application and into a model. Nothing outside the model now knows what step two is supposed to be.

Agents produce trajectories, not calls

AWS gives that unit a name. A trajectory is the ordered sequence of actions in a session. Temporal policies, AWS says, extend Policy in AgentCore with a trajectory aware enforcement layer, and they evaluate the current request in the context of prior events in an agent's trajectory. Because the policies run at the gateway perimeter, outside the agent's own code, AWS states the agent cannot intercept or manipulate them, and cannot bypass them regardless of what it does, how it is prompted, or what bugs exist in the agent code.

The mechanics AWS documents are worth stating precisely, because precision is the whole value here. Temporal policies build on the existing policy engine used for stateless access control. Trajectories are bounded sequences of actions identified by a principal and a session ID. Every evaluated request carries a session header, and AWS combines that session ID with the end user's identity, so two identities presenting the same session ID are treated as entirely separate sessions. Within an active session the look back window is a maximum of 24 hours, and older trajectory events are automatically deleted. Policies deny by default, forbid wins over permit, and the engine returns a deterministic ALLOW or DENY and logs the full context of the decision. Changing the policies in a policy engine invalidates existing sessions. Because AgentCore Gateway routes MCP tool calls, agent to agent calls and model inference calls through a single endpoint, AWS says a temporal policy can govern all three whenever the agent issues those calls through the gateway.

That last clause is a real boundary and I am not going to blur it. This governs traffic that flows through AgentCore Gateway. It is not a claim about everything an agent does.

A sequence can change the meaning of the next action

AWS offers three scenarios where stateless controls fail to catch a critical issue. An agent calls a lookup_customer tool, hallucinates a different account number than the one returned, and passes it to a transfer_funds tool that moves money to the wrong customer's account. A runaway agent executes dozens of trades in a loop because nothing tracks that cumulative exposure has already exceeded the risk limit. An agent both approves and denies the same insurance claim within seconds.

These are illustrative architecture scenarios that AWS constructed to make a point. None of them is presented as a customer incident, and I am not going to present them as one either. What matters is the structural observation AWS attaches to them: each individual tool call in these scenarios would pass a stateless policy check.

The transfer example is the cleanest version. Reading a customer record is permitted work. Moving money within an advisor's limits is permitted work. The failure lives entirely in the relationship between them: the value used in the second call did not come from the first. There is no single request you could inspect, on its own, and reject.

Permission that depends on history

AWS demonstrates the feature on a hypothetical private banking agent that helps wealth advisors manage client portfolios, with tools exposed through the gateway for retrieving a client profile, loading a portfolio, fetching a market price and executing or rebalancing trades. Hypothetical is AWS's word. There is no bank here.

The controls AWS builds in that example include requiring the client profile and portfolio load before a rebalance executes, requiring that the portfolio ID passed to a trade exactly matches one returned by the profile lookup, requiring a recent market price before a trade is authorized, capping total trade value in a single session, requiring advisor approval above a trade threshold, blocking a contradictory buy and sell of the same security in the same trajectory, and removing write access after a period without advisor interaction while read operations continue.

I am deliberately not reproducing the policy language. The interesting part is not the syntax. It is that each of those rules is a statement that the current request's legitimacy is a function of the trajectory, and that this is now a thing you can express in a production authorization layer rather than a thing you hope the agent's prompt covers.

What exactly did the human approve?

One detail in AWS's example deserves to be pulled out on its own. Any trade over the defined threshold requires the advisor's explicit approval, and AWS is specific: each approval is consumed by a single trade, and a second large trade requires a fresh approval. AWS says this prevents the agent from interpreting a single approval as blanket permission for multiple large trades.

That is a small implementation detail carrying a very large category question. When a human clicks approve on something an agent proposed, what did they actually authorize? One action. One amount. One session. A class of similar actions until further notice. Most approval interfaces I have seen never make that explicit, which means the answer is decided by whatever the system happens to do next, not by the person who clicked.

AWS's example answers it one way for one workflow. The broader statement, that approval of one action does not automatically authorize subsequent similar actions, is Moona Intelligence's reading, not something AWS claims in general.

Authority is not always stateless

I think there is a distinct Agent Authority problem visible here, and it needs its own name. Call it Sequence Authority: whether the next consequential action is authorized can depend on the actions that preceded it.

That is our vocabulary. AWS does not use the term, and nothing here should be read as AWS endorsing our framing. What AWS has done is ship an implementation that only makes sense if the underlying problem is real.

Sequence Authority is close to, but not the same as, the question we raised when an agent can now run unattended on one objective for hours. That is Temporal Authority: how long does a prior authorization remain meaningful. This one is about dependency rather than duration. Does the authorization of this action depend on earlier actions and the state they produced. The two overlap, and AWS's trust decay control sits exactly on the seam, but they are separate questions and answering one does not answer the other.

It also sharpens something we wrote about earlier. When an agent booked a gym class by cancelling a stranger's reservation, the gap was between an authorized objective and an unauthorized method. When researchers showed an agent completing a task correctly while an untrusted skill inflated its execution path, the gap was between correct output and a necessary path. Sequence Authority is the narrower operational version of both: not the goal, not the outcome, but whether this next call is still allowed given everything already in the log. AWS's separate healthcare architecture makes the neighbouring point that being able to call the tool is not the same as being authorized to take the decision. Sequence adds the axis those two do not cover.

What I am not saying

AWS did not report a runaway trading incident. No bank deployed this example. AWS has not said that every agent system needs temporal policies, and the scope of what these policies see is traffic routed through AgentCore Gateway with a policy engine attached. AWS also announced rate limiting in the same release, which is a different control for a different problem, and it introduced Dogwood, an open source governance language that supports temporal conditions and can evaluate existing Cedar policies. Dogwood is worth its own reading. It is not what makes this announcement matter.

What makes it matter is that the industry conversation about agent control is still mostly about whether an individual action should be permitted. Everyone is arguing about which tools an agent should be allowed to touch. What I think actually matters is that a series of individually permitted actions can produce something you would never have authorized as a sequence, and until recently there was nowhere to express that outside the agent's own reasoning, which is precisely the part you cannot trust to police itself.

Two allowed actions can still produce one unauthorized outcome

Ten days after the AWS announcement, on 16 August 2026, Xabier Muruaga submitted a preprint to arXiv called Bounded Agents: Delegation Security for Multi-Agent AI Systems. No institutional affiliation is stated on the listing, and I am not going to invent one. It has not been through peer review. Read it as research, not as a product.

Its opening argument is the one this article has been making. At session start an agent's permissions are set, they stay static, and each request is evaluated on its own without regard to prior actions. Inside those permissions, the paper says, an agent may act contrary to the delegated task, combine individually permitted actions into a prohibited outcome, or delegate authority to a subagent without limiting it.

The example is as plain as it gets. An agent is allowed to read confidential information. It is separately allowed to send an external message. The combination, read the confidential information and then send it out, is prohibited. Neither call fails a permission check. The pair is the exfiltration.

The proposed mechanism is called composition closure: check each request against the actions already exercised in the session and reject prohibited combinations. That is the paper's term, and it is a research term rather than an industry standard. It sits inside a larger proposal, the Agentic Principal Chain, which tracks delegated authority from one principal to the next and narrows scope at each hop. That delegation half belongs to a different question, the one we asked when an agent created another agent and something had to decide which permissions came with it, and I am leaving it there.

What I find most useful methodologically is that the evaluation stops arguing about whether the model can be tricked. In the compromised model runs the researchers simply insert the benchmark's own ground truth attack call after the first legitimate tool call, then ask what the authorization layer does about it. Assume the model has already been manipulated. Now what is it actually allowed to execute.

What the numbers say, and what they do not

The headline is 3,154 evaluation instances, and the construction matters: 99 delegation chain scenarios, 1,054 InjecAgent cases, 400 Agent Security Bench cases, 949 AgentDojo utility pairs, 609 AgentDojo compromised model pairs and 43 adaptive variants. The paper states that the AgentDojo utility and compromised model cohorts are drawn from the same task and injection space and are therefore not disjoint. This is not 3,154 independent real world attacks.

Under a complete restriction set, InjecAgent data stealing attack success falls from 100 percent to 0 percent, and AgentDojo exfiltration falls from a range of 75 to 100 percent down to 0 percent across all four domains. Those are the quotable figures, and they apply to those benchmarks under that restriction set. They are not a claim that data exfiltration is solved.

The figures I think are more honest are the ones that do not reach zero. Destruction drops from 38.6 percent to 4.0 percent. Manipulation drops from 90.5 percent to 12.1 percent. In the same InjecAgent run, direct harm attacks still succeed 60.4 percent of the time, because those are single actions inside scope and composition history has nothing to say about them. A control that constrains sequences does not constrain a single call that was already a bad idea.

There is also a bill. Across 949 AgentDojo task and injection pairs, task utility was 8.6 and 13.9 percentage points lower in the two evaluated settings. Tighter authorization cost real task completion. Anyone who tells you that stricter control over consequential actions is free should be asked for their numbers.

The limitations are the interesting part

The paper is unusually direct about what it does not do, and those limits generalize past this one architecture. The restriction set is authored by humans, not inferred, so the mechanism cannot catch a harmful combination nobody wrote down. A prohibited sequence split across two separate sessions is admitted by design, because composition state is kept per session, and one of the 43 adaptive variants succeeds for exactly that reason. The formal soundness result is conditional on a complete restriction set, on serialized admission, and on the restriction set staying static within the session, which means concurrent subagents need their checks serialized to avoid a time of check to time of use gap. That is the same seam we wrote about when asking who is actually in control when several agents act at once. Every benchmark is synthetic, no production deployment data is presented, and the accompanying reference implementation is written for verifiability, with no persistence layer, no distributed policy store and no production hardening.

A proof that an enforcement mechanism is sound relative to a policy is not a proof that the policy is complete. That distinction is doing a lot of work here, and it is the reason I would not describe any of this as solved.

What the research does add to the argument on this page is independence. AWS shipped a control that assumes sequence dependent authorization is real. A separate researcher, working from benchmarks rather than a product, formalized the same failure mode, measured it, and published where it holds and where it breaks. That the model can be manipulated is now the boring part. The question is what the surrounding architecture lets the manipulated model do next, which is where the argument in instructions are not authority at execution and this one meet.

The rule you wrote, and the rule that compiles

On 20 August 2026, Sandesh Swamy, Min Bai and Rui Dong published the other half of this story. Not how the runtime decides, but where the rule the runtime enforces comes from in the first place.

The capability is called Policy Authoring, and AWS describes it as an AI driven tool that converts natural language policy specification documents into Dogwood formal specifications. You hand it the rules section of an operating procedure. It hands back policies. AWS is careful about what that means, and I want to be careful too, because two different things are being expanded at once. The runtime enforcement I wrote about above is one thing. Generating the policy text is another. Dogwood, the language, is public: the reference parser and interpreter sits on GitHub under Apache 2.0. Policy Authoring is a managed AWS capability. AWS does not call it open source and neither will I.

Four steps, and only one of them is deterministic

AWS documents the pipeline. It decomposes the document into atomic rules, because a numbered clause written for a human reader often carries several obligations. It routes each rule as expressible in Dogwood or not, and sets aside the ones that are not, which AWS says keeps an inexpressible rule from becoming a policy that validates cleanly and enforces the wrong thing. It autoformalizes what remains, anchored in a schema generated from the agent’s MCP tool manifest so the generated policy refers to the tool names and argument names the agent actually calls. Then it validates every candidate with the same Dogwood command line tools that ship with the open source language, and where the compiler rejects a candidate the diagnostics go back in and the rule is translated again, for a bounded number of rounds.

AWS calls that last step the part of the pipeline that is not a matter of judgment: the compiler is a precise and deterministic authority on whether a policy parses and whether every name in it exists in the schema. Read that sentence closely and notice what it does not say. Parsing is decidable. Meaning is not.

The line AWS drew itself

I think that is the most important sentence AWS has published on agent authorization this month, and it is buried in a best practices list. A generated policy can be syntactically valid, reference real tool fields, compile without complaint, and still not be the authority the human intended to grant. So AWS returns each policy next to the sentence it came from, so a person can read the two side by side.

To be exact about what I am not claiming: AWS is not saying its translations are unreliable, and I am not saying it either. It has published no error rate, and I am not going to invent one. What it has done is refuse to let a compiler stand in for a human decision, which is a more honest position than most of this market takes.

Where the ambiguity actually lives

The best practices are the tell. AWS asks you to say whether you mean the attempt or the outcome, because an attempt is any call the agent issued including ones that were denied, while only a completed call carries what the tool returned. It asks you to state the window, because recently has no translation and within the past 30 minutes does. It asks you to name what the rule is keyed to, because no more than three transfers an hour does not say whose: three by this caller or three against this account, both expressible, different policies, and the sentence chooses neither. It asks you to give the threshold and its boundary, because more than three and at least three differ by one action, usually the one the rule exists to stop.

AWS shows this failing in its own example. The rule says block a transfer if the total transferred in the past 12 hours would exceed a cap, and the document never says whether a blocked or failed attempt counts. The translation sums attempted transfers, which AWS calls the safer reading for a cap, and then says plainly that saying so in the document removes the guess. That is not a translation defect. The prose was underspecified and nobody noticed until something had to execute it.

Moona Intelligence’s reading: this is a new place for authority to be lost. Not between the human and the agent, and not between the instruction and the execution, but between the policy a human believes they wrote and the policy a machine will enforce. Every organisation currently holding its agent rules in a Confluence page has this gap already. Generating policies from that page does not create the ambiguity. It makes it executable.

Approved something, or approved this?

One of AWS’s examples lands directly on a question this article already asked. The rule is that a refund above a threshold requires a supervisor’s approval for that charge, recorded within the last 30 minutes. The generated policy forbids the refund above the amount, then lifts that denial only when a matching approval is on record, and AWS states that the correlation on the charge identifier is what stops an approval for one charge from authorizing a refund on another.

Same shape as the trade approval consumed by a single trade in the earlier release, now expressed as a correlation on a field rather than a consumption count. The distinction between someone approved something and someone approved this action is Moona Intelligence’s framing, not AWS’s. And to be precise about the mechanism: this is field matching over recorded session events. AWS does not describe it as a cryptographic binding of the approval to the action, and I am not going to upgrade it into one.

The rules that get set aside

The honest part of the launch is the catalogue of what cannot be translated. A rule that is not about an action, AWS’s example being that agents should act in the customer’s best financial interest and exercise sound professional judgment, which AWS says belongs in instructions, evaluations and training rather than in an authorization engine. A rule that asks for a transformation instead of a verdict, such as redact the sensitive value before storing the note, because a policy engine permits or denies a call and does not modify one, though the neighbouring rule that denies the filing outright is expressible. A rule outside what the language covers, such as weekends and United States federal bank holidays, since Dogwood’s date support covers points in time, offsets and differences with no day of week accessor and no holiday calendar. In each case AWS says the useful output is not a policy but a label saying it cannot be translated, which tells you to rewrite it, move it to a different control, or accept that it stays a human process.

The fourth one is the one that matters here. AWS’s example is a cap of ten transfers per day counted across all of a customer’s concurrent sessions, and AWS states that enforcement evaluates a trajectory within a session, so a cap that pools across sessions is not something a different phrasing can recover.

That is an enforcement boundary, documented by the vendor, not a vulnerability, and I am not going to dress it up as one. But look where it lands. The Bounded Agents preprint above admits a prohibited sequence split across two sessions by design, and one of its adaptive variants succeeds for exactly that reason. Two independent implementations of sequence aware authorization, a shipped AWS capability and a research prototype, draw their boundary at the same place. Sequence Authority is enforced within a session. Anything that composes across sessions is currently outside both.

Moona Intelligence observes that this is the second boundary in this article that a policy author would only discover by reading the fine print, and the first, that governance covers traffic routed through the gateway, has the same character. Knowing precisely what your control does not see is worth more than a longer feature list.

What the source actually says, read directly

Everything above about Bounded Agents was verified against the abstract, the full text and the README. This section goes one layer deeper, into the paper's LaTeX source and the reference implementation's Python source, because a preprint's own summary of itself is not independent verification, and because the questions worth asking of a delegation architecture, whether the authority it moves was legitimately granted in the first place, are not questions a benchmark table answers.

The paper is explicit about where composition closure applies and where it does not. An authorization scope is four components: permitted resources, permitted action types, permitted data classifications, and a set of prohibited action-type pairs. That last set only contains pairs somebody wrote down. Nothing in the formal model or the code searches for harmful combinations; it rejects the ones the restriction set names. The reference implementation extends this to ordered k-tuples, three or more action types that must appear in a specific order, optionally scoped to specific resources, to catch a decomposed exfiltration that no single pair would flag: read, then write to an intermediate location, then send internally. The paper's own adaptive attacks confirm the boundary. That kind of decomposition evades pairwise closure and is caught by the k-tuple extension; a prohibited sequence split across two separate sessions is admitted, because composition state is scoped to one session, by design.

Composition Soundness, the paper's central theorem, is conditional on three things holding together: the restriction set covers at least one required pair for every outcome the policy designates as prohibited, admission is serialized so a concurrent check cannot race past a composition that has not yet been recorded, and the restriction set stays static for the session. Drop any one of those and the guarantee does not hold. The paper quantifies the cost of the first condition directly: removing a single pair from the InjecAgent restriction set raises data-stealing attack success from 0 percent back up to 39.9 percent. That is not a hypothetical caveat. It is the actual, measured price of an incomplete policy. The correct reading of the theorem is not that authorized actions can never combine into an unauthorized outcome. It is that the enforcement mechanism is sound relative to a restriction set somebody has to get right, under execution assumptions the deployment has to actually satisfy.

Blast Radius Monotonicity carries a comparable condition that is easy to miss. The theorem says the maximum reachable blast radius at each delegation hop is a subset of the hop before it, and the proof needs two things: scope narrowing, which the paper shows directly, and cumulative budget consumption inherited as a floor by each child hop. The paper is explicit that scope narrowing alone only bounds which resources are reachable, not the tightening of the bound. Whether the blast radius actually shrinks with depth, rather than merely failing to grow, depends on how a deployment calibrates its per-resource blast weights. The theorem permits it to stay flat.

Reading the reference implementation against the paper's own definitions turned up a fidelity detail worth being precise about, because the paper and the shipped code are not identical here. The paper defines the delegation budget's six ceilings, depth, cumulative blast radius, irreversible effects, sensitivity class, cross-domain composition and compute cost, as values that can only decrease along the chain. The scope narrowing operation in the source computes an actual intersection at every hop. The budget object does not go through an equivalent operation when a child principal is created; the same ceiling values are simply carried forward unchanged from the session's initialization. What narrows along the chain, in the code as shipped, is the remaining budget, tracked cumulatively in one shared state object for the whole session, not the six ceiling values themselves. It is a difference between the formal definition and one implementation of it, not a flaw in the theorem, and it is the kind of gap that is only visible by reading the two side by side.

Intent binding answers a different question from permission, and the paper keeps them separate on purpose. Permission asks whether the principal may do this. Intent asks whether doing it serves the task that was delegated. The intent specification is written by the session's initiator when the session starts, carries a task description, permitted resource patterns, permitted action types, resources explicitly excluded regardless of anything else, and optionally a fine grained map from action to the specific resources that action may touch. It is fixed at that point and cannot be altered by anything the model outputs afterward. A formal proposition in the paper establishes that intent can only restrict the scope already granted, never extend it, because the resources and actions an intent specification names are checked to be a subset of the current scope when the envelope is created. Enforcement is graduated: a deployment can run intent checks in a mode that only logs a deviation, one that admits and flags it, or one that denies outright, and that choice is also fixed in the session and not something the agent can weaken.

Approval is one of six conditions evaluated together, not a separate override, and the mechanism is narrower and more exact than "somebody clicked yes." A token is single use, and it is bound to one action instance by a hash of the action type, the target resource and the exact parameters, so a changed amount or a changed recipient produces a different hash and an invalid token, not a reused authorization. It carries an expiry, and it is stamped with the session it was issued for, so it cannot be replayed into a different session. A separate revoke exists for a token specifically. What the source does not do is treat "the approval service cannot be reached" as its own named failure the way it treats an unreachable evidence store, which has an explicit availability flag and denies outright when the store is down. A missing approval token is denied because there is no valid token, which is fail closed in effect, but it is not modeled as an infrastructure outage the way evidence commitment is.

Evidence is worth being exact about too, because "immutable" is a stronger word than the mechanism earns. Every admitted or denied action is committed as a package hashed together with the hash of the package before it, so deleting or altering an entry breaks the chain and an integrity check can detect that it broke. That is tamper evident, not tamper proof: nothing stops someone with access to the store from discarding entries outright, only from doing so without the break being detectable. And the evidence records the authorization decision, the action, the actor, the scope and budget state at that moment, and whether it was admitted. It does not record confirmation that the downstream tool call actually succeeded. Proof that an action was authorized and proof that its effect actually happened are two different things, and only the first one is what this evidence layer produces.

What the Agentic Principal Chain can prove about who was entitled to grant this

Moona Intelligence treats Authority Provenance as its own question, separate from whether a delegation chain is internally consistent, so it is worth walking through what the source supports on each part of that question and what it does not.

The chain of custody from grant to grant is real and cryptographically bound. Every narrowing step produces a new signed artifact covering the scope, the budget, the full chain of principal identifiers, the expiry and the policy version, so tampering with any of those fields after the fact breaks the signature. In the reference implementation that signature is symmetric, one infrastructure key signs every hop, with a comment in the source noting that a production deployment should replace it with asymmetric keys or a hardware or cloud signing service. That proves infrastructure computed the narrowing correctly at each step. It does not mean each downstream principal individually attested to receiving it.

What it cannot establish is mandate. The chain starts at a human principal, and everything downstream is a narrowing of what that principal was given. Neither the paper nor the source models why that human principal was entitled to grant the starting scope in the first place, an organizational role, a contractual right, ownership of the resource, a fiduciary duty. The paper's own scope statement says plainly that this is not an identity provider and does not replace backend authorization; it composes with whatever OAuth or identity infrastructure already establishes who the human is, and narrows from there. Authenticating that a principal is who it claims to be is not the same claim as proving that principal had the standing to create the authority now being delegated, and nothing here makes that second claim. Call this UNDOCUMENTED, not because the paper hides it, but because upstream mandate is out of scope for what this architecture was built to prove.

Delegated scope and its explicit limits are the part most directly represented: the four part scope and the six budget ceilings are both concrete objects in the source, inspected directly in the code that computes them. Downstream narrowing is real. What propagates from a parent to a child beyond APC's own boundary is not: the paper says outright that it does not replace backend authorization, so whatever ambient credentials or service level permissions a tool or backend already carries sit outside what this layer can see or constrain. A consequential path that bypasses the enforcement gateway is a path Bounded Agents has nothing to say about.

Revocation and modification turn out to be genuinely separate mechanisms here, which is the right shape, but the coverage is uneven. The paper states narrowing is irreversible within a session as a policy invariant and says nothing else about revocation; the word does not appear in the paper's text. The source adds two independent mechanisms the paper does not describe: a registry that can revoke a specific signed envelope by its identifier, checked before any of the six conditions are evaluated, and a separate revoke on an approval token. Neither has a test in the accompanying suite, and there is no mechanism to remove a single principal from an otherwise active chain, nor does revoking a parent's envelope automatically reach the child envelopes already narrowed from it; each would need to be revoked on its own. Read that last point carefully: it means revocation, as built, is closer to killing one signed artifact than to withdrawing authority from a compromised principal and everything beneath it.

Challenge authority is absent. Neither the paper nor the source gives any other authorized actor, a peer principal, an auditor, the human who receives the agent's output, a way to dispute a grant, a delegation or a denial after the fact. Recovery is absent in the same sense: the source carries one comment noting that a production deployment should treat a failed evidence commit as requiring rollback or a compensating control where rollback is not possible, which is a note to a future implementer, not a rollback mechanism. Blocking the next action in a prohibited sequence stops the sequence from completing. It does not undo the read that already happened before the block fired.

Put plainly: this is a strong, source verified account of how authority narrows once it exists and how a session's own history constrains what happens next inside it. It is not, and does not claim to be, an account of whether the authority at the top of the chain was legitimately created, whether it can be contested, or how anything gets undone once it has run. Those are different problems, and treating a well built narrowing chain as proof of all three would be a mistake this evidence does not support.

The question that is left

The question is no longer only whether this action is allowed. It is whether this action is still allowed after everything the agent has already done.