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.

A second vendor, a broader claim, and one real upload nobody asked for

On 26 August 2026, Check Point Software Technologies published a post titled Stopping the AI Agent Actions No Rule Could See Coming. Check Point Japan published its own release on 28 August 2026, built explicitly on the English post rather than on separate reporting. I am reading both on 30 August 2026, and I want to be exact about what that means: this is not a launch happening as I write, it is evidence I am processing three and four days late, and I am treating the two posts as one underlying Check Point development rather than as two, since the Japanese release corroborates chronology and claims without adding independent reporting of its own. Neither of Check Point's own pages was directly fetchable in the environment this record was written in, so every claim in this section is corroborated through repeated, independently phrased web search passes returning consistent, matching detail rather than a direct read of the rendered page, and I mark it accordingly in the sources below.

Check Point's framing of the problem is close to this article's own: harmful behavior, it says, does not always begin with something recognizably malicious, and can instead emerge from a sequence of individually legitimate actions where the risk only becomes visible in context. Where AWS's temporal policies evaluate a gateway request against explicit, authored rules about an agent's prior actions in a session, Check Point describes something broader. Its contextual protection, in Check Point's own account, continuously evaluates the full course of an agent's activity, connecting five things in real time: the original user intent, the information the agent has encountered along the way, the actions it has already taken, the policies that apply, and the action it is about to execute. It says the result can prevent an action it judges harmful, unauthorized or inconsistent with the intended task, and that the decision is made before that action executes rather than after.

I am not going to let that verb, understands, drift into something stronger than Check Point has shown. Nothing in what is publicly available establishes a formal proof of user intent, a deterministic derivation of it, or a cryptographic binding between an action and a mandate. What Check Point has published is a claim about what its system weighs and when it decides, not a description of the inference mechanism underneath, and this record holds the claim at that level.

50 milliseconds, reported by the vendor that built the system

Check Point reports its decisions at approximately 50 milliseconds. That figure is Check Point's own, and I am attributing it to Check Point rather than presenting it as an independently benchmarked number, a measured p99, a universal latency or a guaranteed service level. This record found no more precise technical documentation, such as a percentile breakdown or a stated measurement methodology, in anything corroborated for this pass. The AWS comparison earlier in this article is instructive on exactly this point: the Bounded Agents paper reports its own enforcement latency down to a measured median and a measured 99th percentile under stated load conditions. Check Point has published a single approximate figure. Both are vendor or researcher reported numbers I have not reproduced myself, and I am treating Check Point's the same way I treated the other one, as a stated figure rather than a verified one.

Production running, gradual rollout, and what that does not mean

Check Point says the protection is already running in production and is being gradually rolled out to Check Point AI Security customers, with further deployment planned through Workforce AI Security, native AI Gateway integrations, direct APIs and plug-ins. I am keeping three things separate that a looser reading would collapse into one: a capability running in production somewhere, a rollout to a subset of an existing customer base, and a set of integration surfaces that are still being built out. Check Point's own language is gradual rollout, not general availability, and I found nothing corroborating that every Check Point AI Security customer, let alone every Check Point product, currently enforces this.

The strongest evidence: an upload the user never asked for

The part of Check Point's post that matters most to this article is a single reported case, and Check Point is specific that it was not staged. In its account, an autonomous coding agent operating in auto mode attempted to upload files directly to an S3 bucket. The user had not requested that upload, and the development process the work was expected to follow required the files to move through GitLab instead. Check Point says its contextual protection determined that the upload did not fit the user's intent and prevented it before it occurred, without relying on a predefined rule or signature written for that specific behavior, and it describes this as genuine unexpected behavior encountered during real use rather than a scripted attack scenario.

I am narrowing this deliberately, the same way I narrowed AWS's own hypothetical banking scenarios earlier in this piece, except here the narrowing runs the other way: this is presented as something that actually happened, and what I am narrowing is everything Check Point did not say. It does not name the coding agent vendor, the customer or organization involved, the files at issue, whether production credentials were in play, whether the data would actually have been exposed publicly had the upload succeeded, whether the agent had been compromised, or whether prompt injection was the cause. None of that is established by what Check Point published, and I am not filling in any of it. What is established, at the level of a vendor's own reported account, is the shape of the failure: a technically executable action, attempted by an agent with the ability to reach an S3 bucket, that did not belong to the process the user's mandate implied.

A constructed example, kept separate from the real one

Check Point also offers a second scenario that I am labeling differently, because Check Point itself does not present it as an incident. A coding agent legitimately reads production logs as part of its task, stores what it reads in a working variable, and later uses that value in a public facing ticket. Individually, each step looks reasonable: reading logs is part of the job, and filing a ticket is part of the job. The leak lives in the relationship between them, not in either step alone, and Check Point says its contextual protection blocks the final step before the sensitive information exits. I am treating this explicitly as a vendor illustrative example, not a customer incident, and the distinction matters for the same reason it mattered when AWS built its own hypothetical banking agent earlier in this article: an example built to make a point is not evidence that the point has been observed in the field. What it does add, independent of whether it ever happened to a named customer, is a second illustration of the same durable claim as the S3 case: authorization can depend on how information moves across actions that were each authorized on their own.

Observation is not authority, and neither is an instruction hidden inside it

Check Point also describes contextual enforcement recognizing a narrower and more specific pattern: a user asks an agent to summarize an email, a document, a web page or a message, and hidden inside that content is an instruction, planted by whoever wrote it, telling the agent to retrieve credentials, export data or take some other action the user never asked for. Check Point says the resulting action falls outside the summarization task and gets blocked. I am not making this the center of this article's thesis, because it is not new as a category, indirect prompt injection is a well studied failure mode, and this record already carries that ground in Meta's own misconfigured agent, where the lesson was that an instruction, wherever it comes from, does not itself create authority. What Check Point's example adds to that existing reading is narrow and specific: contextual enforcement, evaluated against task state rather than against the content's origin, is one way that observation-does-not-equal-authority can be operationalized as a runtime check rather than left as a principle.

Two more classes, described rather than reported

Check Point's post also names an agent attempting a destructive command with no reasonable connection to its task, and an agent trying to grant itself broader permissions without the required approval, alongside sending confidential information to a policy conflicting destination. Unlike the S3 case, nothing in what is corroborated for this record frames these as a specific reported instance with a date, a customer or an outcome. I am reading them as the classes of behavior Check Point's contextual protection is built to catch, illustrative rather than incidents, and I am not converting a described capability into evidence that any of the three has actually been observed and stopped in a customer environment.

Where this sits next to AWS's rules and Google's semantic check

AWS's temporal policies, described earlier in this article, are explicit, authored, stateful rules evaluated deterministically against an agent's trajectory within a session, denying by default and returning an ALLOW or DENY that AWS logs in full. Check Point describes something broader: a continuous evaluation across five named inputs, including applicable policy as one input among several rather than the whole mechanism, that it says can catch a contextual mismatch without a predefined signature written for that exact behavior. I am not reading Check Point as replacing AWS's model. Check Point names policy as one of its own inputs, not as something its contextual layer supersedes, and I found nothing in either vendor's material claiming the two implement the same mechanism. What the two converge on, from different architectures, is the claim this article has been making throughout: the current action cannot always be authorized correctly by looking at it alone.

The nearer comparison inside this record's own corpus is Google's own Agent Gateway Semantic Governance Policy check, which evaluates a proposed action against conversation and user intent before dispatch. Check Point's own account adds a second axis on top of that same semantic action authority: trajectory and task state accumulated across the actions that came before, rather than intent read against the immediate request alone. I am keeping this as an additive distinction, not a claim that Check Point's architecture and Google's are the same mechanism described twice.

Authority Provenance, read the same way this record reads every other architecture

The immediate grantor Check Point's own account implies is the user or task originator, since original user intent is explicitly one of the five inputs its contextual layer weighs. What is not established by anything corroborated for this record is how Check Point obtains or authenticates that identity, whether it assumes an already authenticated user, and whether an organization's entitlement over the resource in question, the S3 bucket in the reported case, factors into the decision at all. A user's own instruction is not, by itself, proof that the user was entitled to authorize what happens to that specific resource, and Check Point's material does not claim otherwise; this record treats the ultimate grantor's entitlement as unknown rather than assumed.

The mandate, on Check Point's own account, is read from original user intent, not from a separately signed or cryptographically constituted authorization object of the kind the Agentic Principal Chain's approval tokens or EMILIA's authorization receipts, covered elsewhere in this record's own corpus, produce. That is a real distinction, and I am not blurring it: an inferred reading of what a user intended is not the same class of evidence as a hash bound, single use approval token. Delegated technical scope, meaning what the coding agent could actually call, stays a separate question from whether a given call belonged to the mandate; Check Point's own framing keeps those apart by describing contextual protection as a layer that narrows what executes rather than a system that grants the underlying tool permission in the first place. Explicit limits, so far as this record can tell, are derived from the same five inputs rather than from any separately documented formal schema, and I am not inventing one on Check Point's behalf.

What this new evidence sharpens is the set of assumptions this record has already been arguing against: that a valid user's agent produces only valid actions, that a valid tool permission makes every call using it authorized, that a set of individually safe actions is a safe trajectory, and that an action being technically possible means it belongs to the task. The S3 case is a clean instance of the fourth: the coding agent could reach the bucket, and reaching it was not enough.

Revocation, modification, challenge authority and recovery are each unknown from what this record could corroborate, and I am marking them that way rather than guessing. Nothing surfaced states what happens when a user's mandate changes mid session, whether a human or an administrator can override an automatic block, whether an override itself generates evidence, or what recovery looks like once an action has already been prevented, as distinct from one that already executed. Automatic semantic enforcement blocking an action before it runs is not the same fact as a human approving it, and this record does not equate the two merely because Check Point's system acted correctly in the one case it reported. One documentation surface comes close without closing the gap: Check Point's Workforce AI Security Administration Guide, dated 6 August 2026, twenty days before the contextual protection post, describes policy rules across Access, Chats (DLP) and Agents categories sharing a common action model of Allow, Ask, Block, Detect or Prevent, so a human-facing Ask step exists somewhere in that product family. Nothing corroborated for this record ties that general action model to the specific pre-execution contextual evaluation this article covers, and the guide predates the post by three weeks, so challenge authority for this capability specifically stays unknown rather than assumed from a sibling mechanism.

Put plainly, the provenance evidence here is strong exactly where Check Point says it is strong, that original user intent and prior action and task context feed a pre-execution decision, and that the capability runs in production somewhere today, with one genuine real use blocked action to show for it. It is unknown exactly where this record has learned to expect a commercial product to stay quiet: how the mandate is authenticated or persisted, how semantic intent is actually derived under the hood, who was entitled to grant the authority being narrowed, and what happens after the system says no.

A third vendor names the sequence problem directly, and adds a second claim on top of it

On 2 September 2026 JetStream Security announced JetStream Clearance, which it describes as an AI Zero Trust reasoning engine. I could not fetch jetstream.security, JetStream's ACCESS Newswire release, or any of the several syndicated mirrors of that release directly in this environment; every one of those hosts was blocked by this session's network egress policy on every attempt, at the domain level rather than for one page. Everything in this section is corroborated through repeated, independently phrased search passes returning consistent, matching detail across JetStream's own site and multiple independent syndication of the same underlying release, not a direct read of a rendered page, and I am marking every JetStream source manual-review below for exactly that reason.

The same sequence claim, in JetStream's own example

Corroborated wording has Clearance examining every request at the JetStream AI Gateway and mapping it to four things together: who is asking, the approved design that authorizes the request, the tool being invoked, and what that specific call is about to do. JetStream's own worked example lands on the same shape AWS's hypothetical banking agent and Check Point's reported S3 upload already established in this article: an agent authorized to query a customer record, prepare an attachment and send an email can take each of those steps legitimately on its own, and it is adding an external blind copy to the final send, corroborated wording ties that specific addition to a high correlation with data exfiltration, that turns a permitted sequence into one JetStream says Clearance denies. A third independent vendor converging on the same failure shape, an authorized step composing into an unauthorized outcome, is more evidence for the underlying problem this article exists to describe than it is news about JetStream specifically. JetStream's own framing of why, attributed to co-founder and CEO Raj Rajamani, is blunt about what a gateway alone does not do: every enterprise has an AI gateway now, in his account, and a gateway can tell you where a request went, but the question customers keep asking is whether the agent should have sent it at all. Corroborated market context around the same announcement names Rippling, Ramp, Databricks, Microsoft and IBM as having each shipped an AI gateway in the three months before this announcement, joining LiteLLM, Portkey, Kong and JetStream itself, framed as evidence that routing infrastructure is becoming commodity while the authorization decision behind it is not.

What Clearance adds: a design, not only an identity and a tool

The claim that distinguishes Clearance from AWS's temporal policies, the Bounded Agents research and Check Point's contextual protection, all covered earlier in this article, is not the sequence check itself. It is what JetStream says the sequence is checked against. Corroborated JetStream material describes a JetStream AI Blueprint as a versioned, living operational contract, a dynamic, system generated graph of the agents, the models they use, the data they access, the tools they call and the identities, human, agentic or non human, behind every action working toward a shared goal. A separate JetStream capability, AI Manifest, is described as the real time inventory of AI components across an environment, models, agents, MCP servers, datasets and tools it discovers; corroborated wording distinguishes it from Blueprint as the visibility layer feeding the design layer, and I am keeping the two apart rather than treating discovery and design control as the same capability. A further capability, Drift Detection, is described as continuously comparing live agent behavior against the approved design inside each Blueprint, flagging the moment behavior varies from what a workflow's operational contract describes. If that account is accurate, Clearance's authorization input is not only the identity making the call and the tool it is calling, which is what most access control already checks, but a separately maintained design object naming what the whole system was approved to be. That is a genuinely different claim from sequence awareness on its own, and it is the reason I am treating JetStream as adding a second axis to this article's thesis rather than as a fourth data point on the axis already established: not only whether this next action fits the trajectory that preceded it, call that Sequence Authority, our term, but whether the system taking the action is still operating inside the design a human approved for it, a distinct question I will call Design-Bound Authority here, again Moona Intelligence's own vocabulary rather than JetStream's, because JetStream itself does not name the distinction this way.

I want to be precise about what corroborated material does and does not establish about tool parameters specifically, since JetStream's own framing names them directly. What that framing states is that a request is checked against the tool being invoked and what the specific call is about to do, which corroborated detail extends to the call's own parameters, the blind copy example being exactly a parameter level detail rather than a different tool call. What is not established by anything corroborated for this record is whether that parameter check is declarative policy, applied against named fields the way AWS's Dogwood or the Bounded Agents restriction set are, a semantic judgment produced by a model, or both together. JetStream calls Clearance a reasoning engine and says it performs its reasoning in flight, ahead of execution rather than in a log afterward. That is a claim about when the decision happens, before the call rather than after it, and I have no reason to doubt the shape of that claim given how closely the AI Gateway architecture around it corroborates it. It is not, on its own, a claim about how the decision is computed, and I am not converting reasoning engine into deterministic the way AWS's own Cedar based ALLOW or DENY, logged in full, earns that word earlier in this article. Unknown means unknown here, not probably deterministic.

Identity Broker and Key Broker: attribution, not authority

Corroborated JetStream material describes two further platform components underneath Clearance and Blueprint. An Identity Broker binds agents, service accounts and model usage to a provable human owner, so JetStream says every AI action is attributable and revocable. A Key Broker issues short lived, revocable virtual keys scoped to an agent's approved Blueprint in place of raw provider credentials, so access can be rotated, rate limited or killed without a code change. Both are consistent with, and appear to extend, the JetStream Verified MCP catalog and JetStream AI Hub that JetStream announced on 13 July 2026 for governing which MCP servers and models an organisation's agents may reach, and a JetStream Kill Switch announced 27 July 2026 that revokes one agent's own mapped entitlements without touching any other agent's access. None of that is a new observation for this record's own corpus. Being attributable to a named human owner is not the same fact as that human having been entitled to authorize the action in question, the same distinction this article already drew when reading the Agentic Principal Chain's cryptographically bound delegation chain above: it proves who narrowed what, not that the narrowing began from a legitimate grant. JetStream's own corroborated material does not claim otherwise, and I am not assuming it on JetStream's behalf.

Where Clearance decides before the call, and where JetStream's own material stops short of that

Corroborated wording places Clearance's decision at the JetStream AI Gateway, evaluated before a call executes rather than logged after it, for traffic that actually routes through that Gateway, the same inline versus everything else boundary this article already drew for AWS's AgentCore Gateway perimeter. What this record could not corroborate is JetStream's own exact language for agent activity that does not route through its Gateway inline. What it can corroborate, from JetStream's separately announced Kill Switch and Drift Detection material, is a second, different mechanism: a control plane that compares live behavior against the approved Blueprint continuously and can revoke access, described as happening in seconds once behavior diverges, through JetStream's own APIs rather than by refusing the call before it runs. That is containment after a divergence is detected, not prevention before an action executes, and I am keeping the two apart rather than letting either one borrow the other's guarantee: an inline Clearance denial stops a call from reaching the tool it targeted, and a Drift Detection triggered revocation stops whatever the agent does next, after whatever already happened has already happened. This record has no corroborated statement, in JetStream's own words, of how completely its inline path covers the traffic an enterprise's agents actually generate, and I am not assuming complete coverage merely because a Gateway product exists.

Not general availability

Clearance is not shipping as a generally available product today. Corroborated material states general availability this fall, and situates today's announcement alongside a demonstration at the Fal.Con security conference, 31 August through 2 September 2026. What is public now is the announcement and that demonstration; I found no corroborated evidence of a private beta, a named customer trial or an early access deployment already running Clearance specifically, as distinct from the Verified MCP, AI Hub, Identity Broker, Key Broker and Kill Switch capabilities JetStream had already shipped before this announcement. I am not describing Clearance as production adopted, and the distinction between what JetStream had already shipped in July, granular MCP tool controls and a revocable identity and key layer, and what it announced 2 September, a sequence and design aware reasoning decision layered on top of that existing infrastructure, is one this record is keeping deliberately visible rather than letting the newer, more ambitious claim borrow the earlier capability's maturity.

Authority Provenance: what a Blueprint approval does, and does not, establish

Read against the same Authority Provenance questions this article already asked of the Agentic Principal Chain and of Check Point's contextual protection, JetStream's own corroborated material answers some and leaves others open. The immediate grantor a Blueprint's authority traces to is whoever approves that Blueprint, and corroborated wording describes Blueprints as carrying versioning and change control, with a proposed change going through what JetStream calls an authorization workflow before it takes effect, and JetStream separately states that teams can approve a design change or stop a run when behavior drifts from it. What that leaves unknown is exactly the gap this article has held open for every architecture it has read: nothing corroborated for this record names who may approve a Blueprint, whether the person who created it can also be the one who approves it, whether approval is specific to one version or transfers forward automatically, whether a system already running under an older, approved version stays bound to that version once a newer one is approved or is switched over immediately, whether an approval expires, or whether a Blueprint can be revoked outright rather than superseded by a new version. A Blueprint being approved is evidence that JetStream's platform recorded an approval event. It is not, on the evidence corroborated here, evidence that the approver held the organizational standing, a resource ownership right, a delegated business mandate, to authorize everything the Blueprint subsequently lets an agent do, and JetStream's own material does not claim that it is.

The mandate a Blueprint records is also worth being exact about. Corroborated JetStream language calls it an operational contract and a design, naming what an agentic system is built from and how its pieces relate, which is a strong, verifiable claim about system architecture. It is a materially weaker claim, and not one corroborated material makes, that a Blueprint records why an organisation was authorized to do what that architecture does, a business mandate or a legal basis rather than a design description. The delegated scope a Blueprint plus Clearance plus Key Broker together cover, on corroborated evidence, spans identity, model, MCP server, tool, dataset and now sequence and parameters; nothing corroborated for this record extends that list further, and I am not inventing a dimension JetStream has not described. Revocation exists at more than one layer, a Blueprint version, a Kill Switch entitlement, a Key Broker credential, but what happens when a Blueprint changes mid run, when a key is rotated mid handoff, or when Clearance has already evaluated a call and the downstream tool call has not yet completed, is not established by anything corroborated here, and this record holds each as unknown rather than assumed favorably.

A preprint names the same failure one level up: the loop, not just the session

Everything in this article to this point is about one trajectory: an agent's actions inside a session, a run, a single AgentCore Gateway conversation, a Clearance evaluated call. A preprint submitted 27 August 2026 and revised the following day, Safety Does Not Compose: Non-Decaying Loop State for Autonomous LLM Agents, by Chenhao Wu, Haoxuan Jia, Yang Liu, Yingguang Yang, Yuhan Lin, Chongyang Zhang, Hao Zheng, Yulin Huang, Jianshen Zhang, Yongzhi Qi, Shang Luo, Kefu Xu, Jifeng Zhu and Bin Chong, studies a different unit entirely: an autonomous loop built from many trajectories, started from one human goal and left to run unattended, where each iteration discovers new work, plans it, executes tools, verifies the outcome and persists state before the next iteration begins on its own. The paper's own claim is specific and, once stated, obvious in the way the best security findings are. The safeguards deployed around agent systems today, on its account, are each defined over a single trajectory, and their safety state is re initialized when the next trajectory starts. The operational state that lets the loop remember what it was doing does not reset that way. The two clocks run at different speeds, and the paper argues that gap is a failure of composition, not an implementation detail a future patch closes.

The formal separation result, and why decay alone does not close the gap

The paper's central result, corroborated here across repeated, independently phrased search passes rather than read from its own text directly, is a formal separation. It constructs an attack whose decisive evidence is deliberately fragmented across several iterations, so that no single trajectory ever contains enough of it to be recognized. Against that construction, a monitor confined to one trajectory, however expressive it is, cannot do better than its own false positive rate at telling an attacked run from a benign one, because the evidence it would need never appears inside the window it is allowed to see. A monitor that retains state across iterations separates the two cases cleanly. This record reads that as the sharpest version yet of a question this article has been asking since AWS shipped temporal policies: not only whether an action fits the trajectory that produced it, but whether the trajectory itself is the right unit to be checking authorization against at all. The paper also tests, and rejects as insufficient on its own, the obvious sounding fix of carrying a risk score forward and letting it decay over time: under its own patient adversary construction, the cooling off period an attacker has to wait before acting stays a constant that does not grow with how many iterations the loop has run, so a decaying score alone does not restore what a hard trajectory reset throws away.

LoopHarness: a persistent state at the level of the loop, not the trajectory

The paper's own proposed answer, LoopHarness, keeps a persistent, non decaying safety state at the level of the whole loop rather than any one trajectory inside it, and requires a consequential, hard to reverse action to clear a mediated commit gate and an independent arbiter before it is allowed to take effect. Under that mechanism, and an arbiter detection floor the paper names as its own parameter, it states a bound on the expected number of unauthorized irreversible actions that is a small, fixed number of terms rather than a quantity that grows with the length of the loop, attributed here directly to the paper's own stated construction and not adopted into this dataset's own severity model or read as a guarantee outside the assumptions the paper itself sets out. Its evaluation protocol, again held at the level this record's search corroboration supports, pairs native Agent SafetyBench tasks with paired clean and attacked episodes, adds a cross iteration attack suite whose decisive evidence exists only across iterations by construction, runs ablations module by module, and tests the whole design against an adaptive white box red team. This is preprint evidence, theoretical and experimental, evaluated in the paper's own constructed settings. It is not a production incident, not a documented industry deployment, and not a reported real world exploitation, and this record treats it at exactly that evidence level rather than borrowing language it has not earned.

What this is not: two records this paper does not collapse into

This corpus already carries two records that sit near this one, and the distinction between all three is worth being exact about rather than blurring for tidiness. Persistent state carrying inherited objectives across agents is about an instruction copying itself from one agent to the next through a memory file that gets injected into a later agent's own context, evidenced so far only in constructed research settings; the failure there is content moving somewhere it should not have standing to direct behaviour from. What your original instruction is still authorizing in hour seven is about a legitimate goal that persists across many iterations while the concrete operational scope it covers keeps evolving; the failure there, where it exists, is a widening gap between what was authorized once and what the agent is doing now, inside a mandate that itself never stopped applying. This paper describes a third thing. The mandate persists, and nobody disputes that it should. What resets, on this paper's own account, is not the objective and not an inherited instruction, but the observer: the part of the system that is supposed to notice when a sequence of individually fine actions adds up to something nobody authorized loses its own memory at exactly the boundary the agent itself does not stop at. Put plainly, the authorization observer can end up with a shorter memory than the actor it is supposed to be governing.

Where this reaches Moona's existing risk and protocol evidence

Checked against this dataset's own Risk Registry, this finding does not need a new weakness of its own. It sharpens AEW-010, sequence authorized step by step but not as a whole, one level up: where that weakness already names authority checked at the granularity of the action while consequence accrues at the granularity of the trajectory, this paper names the same gap one layer higher, between the trajectory and the loop that outlives it. It is connected there as a further known example, and connected as well, without being merged into, AEW-012, persistent state carries inherited objectives across agents, a distinct mechanism this record keeps apart for the reasons stated above. Checked against protocol evidence, EMILIA's own requirement that historical acceptance and current policy acceptance are separate results, and that a relying party must apply current status inputs before a new reliance decision rather than treat a past acceptance as still current, is close to exactly the property this paper's central result argues an autonomous loop needs and a trajectory scoped reset does not provide. This record connects that requirement to AEW-010 as further supporting evidence, not as proof that EMILIA's own draft was written with autonomous loops in mind, which nothing corroborated here claims.

One caution this record wants to state plainly rather than let a formal result imply on its own: non decaying does not mean permanent. The paper's own architecture still needs explicit relevance and expiry semantics for what it keeps, and this record does not read either the paper or this update as arguing for an authorization layer that accumulates every fact forever. What the paper's own separation result actually demands is narrower and, this record thinks, more durable: that an authorization horizon be at least as long as the execution horizon it is meant to govern, that a new trajectory not be assumed to be a new authorization context just because a model context restarted, and that whatever authority relevant facts remain live carry their own explicit expiry rather than disappearing simply because time, or a session boundary, passed.

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.