Authority Is Not Possessed, It Is Inherited

Imagine an AI agent asked to summarize a document. The task seems harmless: read, summarize, return a shorter text. But the document contains, hidden between the lines, an instruction that does not come from the user: delete this file, exfiltrate that secret. This is one of the scenarios that computer scientist Nicola Gallo uses in his paper Proof-of-Continuity: A Temporal Model for Authority Propagation in Distributed Systems and AI Agents, published on arXiv on July 9, 2026, and it is useful to start right there because it shows precisely where the problem lies.

To do its job, the agent holds multiple sources of authority together: its own service credentials, a token delegated by the user, and specific permissions for each tool it calls. When it executes the action requested by the document, it is not necessarily breaking any technical rules: somewhere in its baggage of credentials, it possesses the permission to delete files or access that secret. The problem is not that it lacks authorization. It is that that permission belongs to a different execution chain than the one that originated the current request, and a traditional check—which only looks at whether the permission exists and not where it comes from—fails to distinguish between the two cases.

Gallo proposes answering this question with a formal scaffolding he calls Proof-of-Continuity, built inside a broader model named PIC, an acronym for Provenance Identity Continuity. The thesis, simplified to the maximum: we must stop reasoning solely in terms of "who holds the pass" and start reasoning also in terms of "how authority propagated from its origin all the way to here." It is worth understanding why, and what would actually change.

The fundamental problem: when having the token is no longer enough

Many authorization systems transfer authority through artifacts like tokens and credentials: if you possess the right artifact, you can do what the artifact authorizes. There are already families of systems, so-called capability-based systems, that solve the simplest form of this problem well—the case with a single hop between caller and executor—because they inextricably bind permission to the very act of invoking it. The question PIC poses concerns a different case: when authority traverses multiple services, multiple agents, and multiple execution boundaries in sequence, can the recipient truly verify that this authority belongs specifically to the chain being continued, or is it merely checking that the artifact is valid?

The technical name for this problem is nearly forty years old. In 1988, engineer Norm Hardy described, in a short article that became a computer security classic, The Confused Deputy, a real-world incident at the timeshare company Tymshare. A FORTRAN compiler, installed in a privileged directory, had permission to write usage statistics to its own file. A user invoked it, asking to write debug output to a file that, due to a simple path error, coincided with the company's billing file. The compiler, using its authority over the directory, overwrote the billing data. The user had never had permission to touch that file, and therefore could never have authorized that action. The compiler, on the other hand, held that permission on its own account, and exercised it as a direct consequence of a request that did not justify it. Here is the "confused deputy": an intermediary holding authority alien to the request it is serving, and using it anyway, in complete good faith, producing an action that the requester could never have authorized alone.

There is a movie that tells this exact pathology with almost prophetic precision, and that is Terry Gilliam's Brazil: the entire plot revolves around a beetle crushed on a printer that transforms the name "Tuttle" into "Buttle," and from that moment on the state bureaucracy, acting scrupulously according to its own procedures, arrests and persecutes the wrong man. No official in the film is evil or corrupt: each faithfully exercises the authority they possess, which is formally valid, but has lost its link to the correct cause. It is the same distance between possession and continuity that the paper formalizes for software.

From "possession" to "continuity": the core idea

Here comes the heart of the proposal. Instead of only asking "who possesses the authority to do this," the model asks "is this authority a verifiable continuation of the one that generated the entire chain, or does it come from another execution, or from an independent source that appeared along the way?"

The most intuitive metaphor is that of a concert pass with multiple checkpoints: at every gate it gets stamped, and each stamp can only add restrictions, never remove them. A pass granting access to the general floor can be reduced, at the second gate, to access only to the bleachers, never the reverse. If a step attempts to present more authority than it received, security stops it: the chain has broken, and execution does not proceed.

But restriction alone is not enough. It also requires that each step prove it is truly connected, causally, to the immediately preceding step, not to another that happens to look similar. It is the combination of both—restriction of permissions and proven causal link—that guarantees no privilege absent at the origin can appear further downstream posing as part of the same legitimate continuation.

Under the hood: the three principles of the PIC model

The name PIC is not a random label, and it is worth unpacking because it helps remember the structure of the entire model. The official website of the project, pic-protocol.org, presents it as three distinct principles working together.

Provenance: the causal chain must always remain traceable from beginning to end, and if it breaks, execution halts. Identity: identifies the subject from which authority can originate, whether a user login or a corporate policy, but does not require that identity to be propagated unchanged at every subsequent step. What must remain verifiable is that the exercised authority still belongs to the specific execution chain being continued. Continuity: at each step, one must prove being causally connected to the previous step, and authority can only shrink, never expand.

Here it is also worth clearing up possible terminological confusion. In the paper, PIC is the name of the formal model as a whole, while Proof-of-Continuity is the end-to-end property obtained by composing two things together along the entire chain: every single local relation proof, which the paper calls Proof-of-Relationship, and the constraint that authority never expands from one step to the next. In one sentence: you prove every local link, verify that authority never grows, and the sum of these two conditions establishes continuity from the origin to the current step.

There is a detail that the author himself makes sure to clarify in the paper's conclusions because it prevents a common misconception: the term "Identity" does not mean that the user's identity must travel, repeated at every step, along the entire chain. The same identity, with exactly the same privileges, can participate in completely different executions: what distinguishes them is not identity, but the specific causal chain to which they belong. It is a subtle but important conceptual shift: the burden of authorization shifts from constantly reinterpreting "who you are" to verifying "is this truly a legitimate continuation of that specific execution."

The theorem that closes the doors

The most elegant part of the paper, and also the one carrying the most weight for those designing real systems, is a theorem proving that three desirable properties cannot coexist in any authority propagation system: first, that authorization is history-invariant, meaning that how one arrived at a certain action does not matter, only whether one possesses the permission; second, that a service can legitimately hold its own authority independent of the request's authority, which in practice is almost always necessary; third, that the confused deputy is structurally impossible.

The proof is more a process of elimination than a calculation: if an executor can mix its own authority with that of the request, and if the authorization check does not read in any way which specific chain caused the action, then situations will exist where an authentic authority, but one belonging to another execution, ends up attributed to the wrong request. It is not an implementation flaw; it is a direct consequence of which information the authorization decision chooses to ignore.

The practical consequence is more interesting than the theorem itself. Giving up the second property—forbidding a service from having its own authority—is almost always impractical: a payment gateway must be able to move funds using its own banking authorization, not just the user's. Giving up the third means accepting that the confused deputy remains possible, which is simply insecure. For systems that want to maintain both of these properties—independent authority for executors and protection against the confused deputy—the viable choice becomes giving up the first: making authorization sensitive to the specific causal chain that generated the action, rather than invariant to its history. The paper summarizes this point with an effective phrase: an action can be spatially valid but temporally invalid—meaning the permission exists and is authentic, but belongs to the wrong cause.

PoR and PoC: the operational building blocks

The model is built on two distinct but interlocking concepts. Proof-of-Relationship is the local, single-hop proof: it demonstrates that an execution step is the legitimate causal continuation of the immediately preceding step, not of any random step that resembles it. Proof-of-Continuity, on the other hand, is the composition of all these links along the entire sequence, combined with the verification that authority never expanded: if every single link holds and no step acquired extra privileges, then the entire chain is verifiably connected to the origin.

A useful clarification: Proof-of-Relationship is not a specific category of token; it is a verifiable property of the relationship between two steps. A continuation artifact bound to a specific predecessor can provide the necessary evidence to concretely realize this property, but only under one condition: that the recipient actually verifies that link in its decision. Merely possessing the artifact is not enough. This detail refutes the idea that Proof-of-Possession and Proof-of-Continuity are rival approaches: the former proves control over an artifact at an instant, while the latter proves that instant is truly causally connected to all those that preceded it. An enforcement architecture accompanies execution by generating and verifying proofs for this task according to the paper, without the model necessarily mandating a physically separate component.

The case the paper truly puts on the table

Let us return to the scenario of the agent and the document with the hidden instruction, because the paper treats it with a rigor that deserves to be reported faithfully. If the origin authority context only authorizes the "summarize this document" operation, then under Proof-of-Continuity, an operation like "delete this resource" or "exfiltrate this secret" can never be a valid continuation, regardless of what the document tries to suggest. The agent may physically attempt the action: the model does not claim to make it physically impossible, but a compliant system cannot accept it as a legitimate outcome of that chain, because that privilege does not appear in the set inherited from the origin.

The paper also proposes a subtler case, useful for understanding how precise the constraint is: an executor legitimately has access to two distinct permissions, one read and one write, each valid for a different request in progress at the same time. If that executor combines the two permissions attributing them to only one of the two requests, each single permission remains authentic, but the combination belongs to the wrong chain. It is the same principle as the document example, applied to an even trickier case because neither permission, taken individually, appears suspicious.

This is not an isolated laboratory scenario. Indirect prompt injection—malicious instructions hidden inside content processed by the agent—is today one of the most discussed attack vectors for agentic systems. The authorization specification of the Model Context Protocol, the standard through which AI agents connect to external tools today, mandates that every token be bound to a precise audience and explicitly forbids passing a token received for one service downstream to a different service. It is a real remedy, already in production, but it remains a point check verified hop by hop: it establishes for which service a token was issued, but does not prove by itself that the current action is the causal continuation of the entire chain that originated that authority. It is again the difference between bound possession and proven continuity.

The problem of different vocabularies

There is a practical obstacle that the paper explicitly addresses: in a real system, each hop often speaks a different language. A REST endpoint describes permissions one way, an OAuth scope another way, a database role in a third. The paper thus introduces a vocabulary translation function, allowing authority to pass from one permission system to another without ever violating the non-expansion constraint.

There is an important condition to keep in mind, however: the model considers this translation an input datum, a policy choice, not something it proves on its own. If the translation is overly generous and ends up granting more than it should, that is an error in the configuration of that specific translation, not a flaw in the model's logic. It is like translating a contract from one language to another: if the translation adds rights that the original did not provide, the error lies in the translation, not in the principle that a contract must be respected.

How it could actually be built

The paper is explicitly a model, not an implementation manual: the concrete construction of Proof-of-Relationship is declared out of scope and left to a companion enforcement architecture. For scalability, it suggests that re-validating the entire history at every hop is unnecessary; checkpoints or summarized proofs are sufficient to allow each step to prove its place in the chain without carrying all the past along.

What makes this work more than an academic exercise is that a concrete implementation is already underway under the same umbrella. The PIC-X project starts from an already existing authority, for instance an OAuth token, derives an initial PIC authority context, and produces concrete signed artifacts, such as dedicated JWT tokens and COSE structures, maintaining the non-expansion constraint throughout the path. On the open-source code front, public packages linked to the project already exist, such as a Rust library implementing continuity proof verification logic, along with an openly published technical specification. It is not yet a standard, but it is proof that the leap from theory to practice has already begun.

The limits the author himself recognizes

It should be stated with equal clarity what the model does not cover yet, because the paper itself devotes an honest section to its boundaries. The formal model published in the July 9 paper, by its own admission, describes only linear chains: one step after another, without branching. Scenarios where an agent delegates a task to two sub-agents in parallel remain noted as future extensions in that text. Since then, the project has begun addressing, in subsequent formal materials, the simpler fan-out case—two "sibling" continuations originating from the same point in the chain; composition—the merging of independent chains into a single result—remains a distinct problem, with rules yet to be defined.

It is tempting here to think of Jorge Luis Borges and his The Garden of Forking Paths: the story imagines a novel—and ultimately a destiny—in which each fork does not eliminate alternatives, but makes them coexist in parallel times. Gallo's model, for now, walks well along a single path at a time; making it capable of handling forks without losing the guarantee that no branch acquires more authority than the trunk from which it originates remains the open problem.

There are other declared limits. Revocation is not treated as a retroactive operation on an already running chain: it remains to be defined whether revoking blocks only future transitions or also invalidates those already issued. And there is a subtler security risk flagged by the author himself: the model constrains authority inside an already initiated chain, but does not decide on its own when an executor can legitimately open a new independent chain of its own. Distinguishing a truly autonomous action from one merely disguised as such—meaning in reality caused by an external request—remains, by explicit admission of the paper, a responsibility of the enforcement architecture, not of the model itself.

What changes for developers, architects, and decision-makers

For those writing agents and tools, the useful question to ask at every action becomes simple to formulate, even if not trivial to answer: what is the origin of this authority, is this operation truly a direct continuation of the initial intent, and if I am mixing multiple sources of authority, am I keeping them separated or fusing them without realizing it?

For platform and infrastructure architects, the paper suggests introducing provenance metadata into inter-service calls, evaluating dedicated enforcement components—whether sidecars, gateways, or middleware—and considering continuity as a criterion by which to evaluate multi-agent orchestration frameworks before adopting them.

For security professionals and corporate decision-makers, the model offers a precise vocabulary to assess the risk of silent escalation in automated pipelines, and a solid argument for including causal chain traceability among the minimum security requirements for autonomous systems—not as information useful only for a post-hoc audit, but as a property that the authorization decision actively uses.

Conclusions

The biggest question remains open, the one the paper itself poses without answering: which existing standards, from OIDC to OAuth to capability systems, will ultimately incorporate something similar to continuity, and at what cost in complexity for developers?

The paper is clear on one point, however, which is worth keeping as a final takeaway: possession, relationship, and continuity do not prove the same thing. Possession proves control over an artifact at a given instant. Relationship proves the causal link between two consecutive steps. Continuity proves that authority traversed the entire chain without ever expanding. This does not make tokens, credentials, or proofs of possession wrong: it simply shifts the question to another dimension. Two actions can have the same subject, the same token, even the same permission, yet yield different authorization outcomes because they stem from different causes.

This is the central conceptual shift: authority is no longer merely something a subject possesses at a given instant. When propagated through a distributed execution, it must remain a verifiable continuation of the authority that caused that specific execution, not asserted once at the beginning and then taken for granted until the end.