Your traces show the call graph. Your customer needs the authority graph.

Take a workflow that is entirely ordinary in a 2026 orchestration product. Five agents. A supervisor decomposes a request; a planner sequences it; a retriever pulls documents; a reconciler compares two ledgers; a fifth agent writes the correction. The customer is on a paid observability tier and the instrumentation is good — genuinely good, the sort of thing a platform team spent two years and a great deal of money getting right.

The trace is complete. Every span has a parent. Every hop carries its operation name from the GenAI semantic conventions: `invoke_agent`, `invoke_agent`, `invoke_agent`, `execute_tool`. Latency is broken out per hop. Tool arguments and tool results are attached. If the reconciler had timed out, an engineer would find it in under a minute, and that is not a small thing.

Then the customer's platform security lead asks a question during a design review, and it sounds like a reporting question rather than an architecture question:

Which principal authorised the write that the fifth agent performed?

The trace answers a different question with total confidence. It says the write was performed by the ledger-writer agent, which was invoked by the reconciler, which was invoked by the retriever, which was invoked by the planner, which was invoked by the supervisor, which was invoked by an HTTP request that arrived carrying a session. Five nodes, four edges, no gaps. It is a complete and correct account of who called whom.

It contains nothing whatsoever about who permitted what.

The write happened under a grant that was established once, at the outer boundary, when the session was created. Every hop after that inherited it — not by receiving it, not by requesting a narrower version of it, but by running inside a context in which it was already present. There is no span attribute recording that the reconciler was permitted to cause a ledger write, because the reconciler was never permitted to cause a ledger write in any sense that produced a record. It was simply somewhere that a ledger write was possible.

The five-agent workflow above is a constructed illustration, assembled from patterns that are documented in public specifications and vendor documentation. It is not a report of any real incident, customer or deployment, and no part of this piece describes client work.

The objection, stated properly

The strongest response to all of this is that it is condescending and mostly wrong, and it deserves to be put at full strength before it is answered.

Observability at platform scale is one of the more impressive pieces of distributed-systems engineering of the last decade. Context propagation across process, language and network boundaries is a solved problem with a standard behind it. Sampling strategies that keep the interesting traces and drop the boring ones are a genuine research contribution shipped as a product feature. Cardinality budgeting, tail-based sampling, exemplar linkage between metrics and traces, span-to-log correlation without joining on timestamps — these are hard, they are done, and they are done well. The bill for all of it is large enough to be argued about at budget time, and it keeps getting approved, because the visibility is worth it.

And the span model is open. An attribute is a key and a value. Nothing in the model prevents a platform from attaching whatever it likes to a span, including a principal identifier, a scope string, or the outcome of a policy evaluation. So the natural reading of the complaint above is: you failed to log a field. Add the field.

A platform engineer hearing an outsider say "your logging is inadequate" is right to be irritated, because that sentence is usually said by someone who has not looked, and because it is usually followed by a request to log more of something that is already being logged at a cost the requester is not paying.

I want to concede all of that, and then be precise about what it does not touch.

The gap is not a missing field. A missing field implies there was a value and nobody wrote it down. Here there is no value. When the reconciler causes a ledger write under a session credential that was minted before the reconciler existed, there is no principal identifier that would be correct to attach to that span other than the one at the boundary — which is the same one attached to every other span in the trace, and which therefore distinguishes nothing. Writing it down five times does not produce five facts. It produces one fact copied five times, and the copy carries no information about what happened in between.

The gap is not a sampling problem either. Sampling drops traces that were never going to be looked at. It has no bearing on whether the retained traces contain the object in question. Turn sampling off entirely, retain everything at full fidelity, spend the money — and the authority question is exactly as unanswerable as it was, because the fidelity is fidelity to a call graph.

The distinction I am drawing is between telemetry that is incomplete and telemetry that is complete about the wrong graph. Only the first is an instrumentation problem. The second is an architecture problem that has been mistaken for an instrumentation problem, largely because the person who first notices it is usually holding a trace viewer at the time.

Two graphs, and only one of them is made of events

Set the two objects side by side and define them tightly, because the whole argument turns on their being different objects rather than two views of one.

The call graph is a graph of invocations. Its nodes are executions and its edges are calls. Every edge has a moment at which it began, a moment at which it ended, and a caller that can be named at the moment it began. That is the entire reason tracing works: the edge is an event, and an event can be observed while it is happening by the code that is causing it. Instrumentation is the practice of writing down edges at the instant they are created. The reason a distributed trace is reconstructable at all is that its edges were, at some point, live.

The authority graph is a graph of grants. Its nodes are principals and its edges are permissions that one principal extended to another, bounded in some way — to a resource, to an action, to a window of time. This graph is what the security lead is asking about, and it is the graph a customer needs when they want to know whether an action was within the authority it was performed under.

In the prevailing propagation pattern, the second graph has no edges. Not unrecorded edges. No edges.

Consider what would have to happen for an edge to exist. The reconciler would have to hold a credential that is distinct from the retriever's, that names the retriever as its parent, and that is bounded more tightly than the retriever's — otherwise the edge carries no information, since a grant that is identical to its parent is not a grant, it is the same grant. None of that happens. What actually happens is one of three things, and all three are non-events.

1. A shared session. The workflow runs inside one session object that was authenticated once. Each agent reads from it. Nothing is passed; the session is simply in scope. There is no moment at which the retriever gives the reconciler anything, so there is no moment at which an edge could have been observed.
2. An inherited credential. A token or key is present in the environment, in a config object, or in a client that was constructed at startup and is shared by every agent in the process. The fourth agent does not obtain it. It has been in possession of it since the process began, alongside every other agent.
3. A system prompt carried forward. Instructions, tool definitions and accumulated conversation state move across a handoff. The receiving agent's capability changes because it now knows about tools and context it did not know about before. Its authority does not change, because authority was never the thing being handed over.

The third case is the one worth dwelling on, because it is where the confusion is most productive. In the OpenAI Agents SDK, the documented behaviour of a handoff is that the receiving agent sees the prior conversation: "When a handoff occurs, it's as though the new agent takes over the conversation, and gets to see the entire previous conversation history." The documented controls over what crosses the boundary are context-shaping controls — an input filter, settings for nested handoff history — and the documentation is explicit that without them the receiving agent still sees the history. Look down that API surface for a parameter that narrows what the receiving agent may do, and there is not one.

That is a statement about the framework's documented surface, and I am going to be careful not to stretch it. It does not say the framework passes credentials, and I am not claiming it does. What crosses is context. Whether the receiving agent's tools then reach for an ambient credential is a property of the deployment, not a documented framework behaviour. But notice the shape of the design: the thing the API gives you fine-grained control over is what the agent knows, and the thing it gives you no control over is what the agent may do, because that was never modelled as travelling in the first place.

It would be comfortable to conclude that this is a gap somebody will close in the next minor version — a new span attribute, a new field on the handoff object, done. I do not think that is right, and the reason matters more than the observation.

There are three independent reasons the object is missing, and they sit at three different layers. A patch at any one layer does not produce the object, because the object requires all three.

Reason one: the nearest standard deliberately made the ancestry non-load-bearing

RFC 8693, OAuth 2.0 Token Exchange, is the specification that comes closest to modelling this problem, and it is worth reading closely because it has thought about almost everything here and then made a choice that runs against what an authority graph would need.

It begins by drawing exactly the right distinction. Section 1.1 separates impersonation from delegation in terms that could serve as the definition of the problem: under impersonation, principal A "is given all the rights that B has within some defined rights context and is indistinguishable from B in that context." Under delegation semantics, by contrast, "principal A still has its own identity separate from B, and it is explicitly understood that while B may have delegated some of its rights to A, any actions taken are being taken by A representing B."

That is the distinction the multi-agent case needs, stated in 2020. And the RFC does not stop at the distinction. Section 4.1 defines a delegation-chain object inside the token itself: "A chain of delegation can be expressed by nesting one 'act' claim within another. The outermost 'act' claim represents the current actor while nested 'act' claims represent prior actors. The least recent actor is the most deeply nested." The RFC characterises the result as "a history trail that connects the initial request and subject through the various delegation steps undertaken before reaching the current actor."

So the ancestry object exists, in a standard, with a wire format. And then the same section says this:

For the purpose of applying access control policy, the consumer of a token MUST only consider the token's top-level claims and the party identified as the current actor by the 'act' claim. Prior actors identified by any nested 'act' claims are informational only and are not to be considered in access control decisions.

Read that as a design decision rather than as a limitation, because it is one, and it is defensible. A verifier at the far end of a chain has not observed the earlier steps. It cannot independently confirm that the third actor really did narrow what the second gave it. Asking a resource server to make access-control decisions on the strength of unverifiable assertions about events it did not witness is how you build a system that fails in ways nobody can reason about. The RFC's authors chose auditability over enforceability, and given what a JWT can prove, that was the right call.

The consequence is precise: the standard's delegation chain is history, not constraint. It tells you what a token claims happened. It is expressly not something a resource server may use to decide whether the current call is within the authority the chain describes.

There is one more thing the RFC does not do, and it is worth stating carefully because it is commonly overstated. RFC 8693 contains no requirement that an exchanged token be less privileged than the token it was derived from. It provides the client with `audience`, `resource` and `scope` request parameters to indicate the token it wants, and its response rules anticipate that the issued scope may differ from the requested one — Section 2.2.1 makes the response `scope` parameter optional when the issued scope is identical to the requested scope and required otherwise. What it never says is that the issued token must be narrower. A full-text reading finds no "fewer rights", no "narrower", no "lesser", no "more restricted" in the normative text. Whether a child credential is weaker than its parent is an authorization-server policy decision, not a protocol invariant.

The RFC is also explicit that the child's lifecycle is decoupled from the parent's: "In the absence of one-time-use or other semantics specific to the token type, the act of performing a token exchange has no impact on the validity of the subject token or actor token," and "the exchange is a one-time event and does not create a tight linkage between the input and output tokens." Revoking a parent does not, by the protocol, revoke its descendants.

The RFC does define one primitive that points the other way, and it is the closest thing in any standard to a declared, checkable delegation edge. Section 4.4's `may_act` claim "makes a statement that one party is authorized to become the actor and act on behalf of another party," usable by the authorization server to determine whether the requesting party "is authorized to engage in the requested delegation or impersonation." It is a genuine authority edge, declared in advance and checked at issuance. It is also optional, and it is checked at the authorization server rather than where the call lands.

Reason two: attenuation needs an object, and ambient context is not one

The second reason is the one I find most persuasive, and it becomes obvious the moment you compare the prevailing pattern against a construction where attenuation is structural.

A macaroon is a bearer credential built from a chain of nested keyed hashes. The paper's own description of the construction: "a macaroon's chain of HMAC values is derived by computing, for each message, a keyed HMAC value, nested so that each such value itself is used as the HMAC key for the next message," where the first message "is required to be a public, opaque key identifier that maps to a secret root key known only to the target service."

The property that falls out of that construction is the interesting one. A holder possesses only the terminal signature. That is sufficient to extend the chain by adding another caveat — appending a further restriction and computing the next HMAC — and it is not sufficient to recompute an earlier, less-constrained value, because doing so would require inverting the hash. Attenuation is therefore not a rule that a policy engine applies to the credential. It is a property of what the credential is. The paper describes a derived credential in exactly these terms: one that "has been derived as a strict attenuation of another, more permissive macaroon" by eliding that macaroon's signature and adding caveats that bind the request context.

Two further properties of the construction matter for the multi-agent case. Derivation requires no round trip: "by adding caveats, new, more restricted authorization credentials can be directly derived from macaroons, without proxying requests to the target service, or re-minting new credentials from it." And third-party caveats convert a delegation into a verifiable obligation on a named external principal — a caveat carries a root key and assertion encrypted for the discharging service, a hint to its location, and the same key encrypted for the target service so the target can verify a discharge it never issued. The paper notes that such caveats "can ensure that each request authorized by a macaroon is subject to any number of extra steps for authentication, authorization, or audit."

I am citing macaroons as a design precedent with a published construction and a prototype implementation, not as prevailing industry practice. No cloud platform I am aware of exposes anything like it as a delegation primitive, and I have found no primary source claiming production deployment at scale. What the paper establishes is narrower and sufficient: this is not an open research problem. Somebody worked out how to make a credential that is structurally weaker than its parent, published it, and the field moved on to other things.

Set that against ambient propagation and the asymmetry becomes stark. To attenuate, you need a thing. A session that is in scope is not a thing that was handed over; it is a condition that obtains. A client object constructed at process start is not a thing the fourth agent received; it is furniture. There is no handover moment at which a narrower version could have been produced, because there is no handover. That is what makes this structural rather than negligent. It is not that engineers forgot to narrow the credential at the boundary. There is no boundary at which narrowing is an available operation.

Reason three: the telemetry layer has no field for it, and the layer above has no object to put in one

The third reason closes the loop, and it is the one a platform team can verify in ten minutes without taking anyone's word for it.

Enumerate the OpenTelemetry GenAI semantic conventions attribute registry. There are sixty-three `gen_ai.*` attributes, and every one of them carries Development status rather than stable — worth saying plainly, because a convention at Development status is still moving and any argument that treats it as frozen is wrong. The registry covers agent metadata (`gen_ai.agent.id`, `gen_ai.agent.name`, `gen_ai.agent.version`, `gen_ai.agent.description`), conversation and workflow identifiers, prompts, messages, retrieval, memory, evaluation, tool calls (`gen_ai.tool.name`, `gen_ai.tool.call.id`, `gen_ai.tool.call.arguments`, `gen_ai.tool.call.result`) and token usage.

Not one attribute names a credential, a principal, a scope, a permission, an authorization decision, or a delegating parent agent. Every attribute whose name contains "token" is a model-token attribute rather than a security-token one: `gen_ai.token.type`, whose enumerated values are `input` and `output`, together with `gen_ai.request.max_tokens` and the `gen_ai.usage.*` counters.

The span conventions match. The operation enumeration runs to eighteen values, all at Development status, and the ones a multi-agent workflow emits are `create_agent`, `invoke_agent`, `execute_tool`, `chat`, `plan` and `invoke_workflow`. That vocabulary makes the call graph recoverable in some detail — which agent invoked which sub-agent or tool, with what arguments, producing what result — and specifies no field for the authority under which the invocation was made.

I want to be careful about what this absence supports. It supports the claim that the attributes do not exist, which is checkable. It does not support a claim that the working group considered such attributes and declined to add them; no primary statement of intent was located, and inventing one would be exactly the kind of secondary-source drift this argument cannot afford. The absence is the finding on its own.

Now put the three layers together. The credential layer offers an ancestry object that the standard tells verifiers not to act on. The runtime layer has nothing to attenuate because authority never becomes an object. The telemetry layer defines no field, and would have nothing to fill it with if it did. Adding a `gen_ai.principal.id` attribute tomorrow would produce a field populated, at every hop, with the same boundary identity — which is what the current trace already tells you, spelled differently.

/** GenAI operation vocabulary, per the GenAI span conventions (Development status). */
export type GenAiOperation =
  | "create_agent"
  | "invoke_agent"
  | "execute_tool"
  | "chat"
  | "plan"
  | "invoke_workflow";

/**
 * The subset of the gen_ai.* registry that a multi-agent workflow actually populates.
 * Read down the list looking for authority. There is none: the registry describes what
 * the agent did, never what it was permitted to do.
 */
export interface GenAiAttributes {
  readonly "gen_ai.operation.name": GenAiOperation;
  readonly "gen_ai.agent.id"?: string;
  readonly "gen_ai.agent.name"?: string;
  readonly "gen_ai.agent.description"?: string;
  readonly "gen_ai.conversation.id"?: string;
  readonly "gen_ai.tool.name"?: string;
  readonly "gen_ai.tool.call.id"?: string;
  readonly "gen_ai.tool.call.arguments"?: string;
  readonly "gen_ai.tool.call.result"?: string;
  /** The only "token" in the registry is a model token, not a security token. */
  readonly "gen_ai.token.type"?: "input" | "output";
}

export interface GenAiSpan {
  readonly traceId: string;
  readonly spanId: string;
  /** Recorded at every hop. This single field is what makes the call graph recoverable. */
  readonly parentSpanId: string | null;
  readonly name: string;
  readonly startUnixNano: bigint;
  readonly endUnixNano: bigint;
  readonly attributes: GenAiAttributes;
}

What breaks, mechanically

The absence of the authority graph is not an aesthetic complaint. Four specific things fail, and they fail in ways that are visible to a customer before they are visible to a platform.

Revocation has no target. The operator's instinct on discovering a misbehaving agent is to revoke what it was using. In the ambient pattern, what it was using is the session credential that every other agent in the workflow is also using, so revocation is all-or-nothing at the workflow boundary. There is no per-hop credential to kill, because there was never a per-hop credential to begin with. And where token exchange is in use, the RFC is explicit that revoking the parent does not by the protocol revoke the child: the exchange is a one-time event that creates no tight linkage between input and output tokens. Either way, the operator ends up terminating the workflow, which is a blunt instrument that costs the customer four working agents to stop one.

Attribution after the fact resolves to the wrong principal. When the customer's incident review asks who did this, the honest answer available from the data is the boundary session, which is usually a human user or a service account standing in for one. That answer is technically true, materially misleading, and it lands the accountability on whoever authenticated at the front door for a decision made four hops in by a component they have never heard of. Every incident review that reaches this point produces the same finding, and the finding is about the platform.

Blast radius cannot be bounded in advance. A security architect assessing a proposed workflow wants to know the maximum damage the fourth agent can do. Under attenuation, that is a bounded and computable question: the fourth agent's authority is the intersection of every caveat accumulated along the chain, and it is strictly smaller than the third's. Under ambient propagation, the fourth agent's authority equals the boundary grant, so the answer is the whole grant, for every agent, always. The architect either accepts an unbounded answer or refuses the deployment — and refusing the deployment is a decision about your product.

The confused-deputy boundary is per-hop, not per-chain. The Model Context Protocol takes this seriously and gets the boundary rule right. Its authorization specification requires that servers "MUST validate that access tokens were issued specifically for them as the intended audience" and "MUST NOT accept or transit any other tokens"; for upstream calls it requires a separate token issued by the upstream authorization server and states that the server "MUST NOT pass through the token it received from the MCP client." It grounds this in resource indicators and protected-resource metadata, and names the failure mode it prevents as the confused deputy. That is a good rule and it forecloses a real attack. What it does not do — and does not claim to do — is carry a chain. It establishes that this token was meant for this resource. It says nothing about whether the caller was permitted, by whoever authorised the workflow, to reach this resource at all.

The A2A protocol makes the same boundary honest in a different way, by declining the problem explicitly. Its documentation states that "A2A protocol payloads, such as JSON-RPC messages, don't carry user or client identity information directly. Identity is established at the transport/HTTP layer." Credentials are acquired outside the protocol, and "authorization logic is specific to the agent's implementation, the data it handles, and applicable enterprise policies." It also notes that "agents are typically opaque because they don't share internal memory, tools, or direct resource access with each other." Taken together, those three statements mean the authority behind a cross-agent call is not recoverable from the protocol, by design and by declaration.

There is a fifth consequence I will state carefully, because the mechanism is clear and the frequency is not. Content that enters the workflow at hop two — a retrieved document, a tool result, a message from another agent — becomes part of the context that steers hop four. Hop four acts under the boundary grant. So the reachability question is not whether hop two can escalate its privileges; it never needed to, because hop four already holds everything the boundary held. That is a mechanism argument, not an incident report, and I have no primary measurement of how often it is exercised in production.

What the field already knows, and where it stops

Score the published specifications against the four properties an authority graph would need — that it names the delegating parent, that the child is weaker than the parent, that the constraint is checked where the call lands, and that it is visible in telemetry — and a clear pattern appears.

• Naming the parent is solved. RFC 8693's nested `act` claim does it, with a wire format, and `may_act` goes further by declaring the permitted actor in advance.
• Structural attenuation is solved. The macaroon construction makes the child weaker than the parent as a property of the credential rather than of a policy, and does it without a round trip to the issuer.
• Checking at the point of use is solved. Macaroon caveats are verified at the target service; MCP's audience binding is checked at the resource; third-party caveats extend the check to a named external discharger.
• Identity for workloads is solved. SPIFFE standardises naming, issuance and verification: a SPIFFE ID is an RFC 3986 URI comprising a trust domain and a path, and an SVID is the document with which a workload proves its identity.

That last one carries a caveat that is easy to get wrong in this argument's favour, so I will state it against myself. SPIFFE standardises identity and authentication, not authorization. It defines no privilege, scope or delegation semantics, and leaves access-control decisions to consuming systems. More pointedly, SPIRE's Delegated Identity API — the nearest thing in that ecosystem to workload-to-workload delegation — is impersonation, and the project says so in its own documentation: it "explicitly and by-design grants the authorized delegate workload the ability to impersonate any of the other workloads it can obtain SVIDs for," and such a workload "becomes a 'trusted delegate' of the SPIRE Agent, and may impersonate and act on behalf of all workload SVIDs it obtains." Authorization is an allowlist of delegate identifiers; what the delegate receives is the full identity of the delegated-for workload, not an attenuated derivative naming a parent. Anyone claiming SPIFFE solves agent delegation is claiming the opposite of what the project documents.

So the pieces exist, and they exist in different places. Ancestry lives in a token standard that instructs verifiers not to enforce it. Attenuation lives in a 2014 paper with a prototype implementation. Point-of-use checking lives in two protocols that each cover one hop. Identity lives in a system that is careful to say it is not doing authorization. Telemetry has no field at all.

Nothing here is a research problem. The gap is an assembly problem, and assembly problems belong to whoever owns the substrate.

Who is asking, and why no specification is coming to settle it

Three groups of buyers have a structural reason to ask this question rather than a stylistic one, and they are the three markets where an agent platform's growth is currently being fought over. In North America, supervised institutions run a second line whose entire function is to establish which principal stands behind an action before that action is approved at scale. In the Gulf, national programmes and their delivery partners are procuring against a sovereignty requirement, and a platform that cannot account for its own agents without a foreign vendor in the loop fails that requirement on its face. In India, regulated entities and the capability centres that build for offshore parents inherit a standard set elsewhere, which means the evidence has to travel — and evidence that cannot be reconstructed does not travel.

None of those buyers is currently holding a specification that tells them what to demand, and one common assumption about that is worth correcting. The revised interagency model risk management guidance issued on 17 April 2026 — OCC Bulletin 2026-13, "Model Risk Management: Revised Guidance," with the parallel Federal Reserve issuance SR 26-2 — supersedes the earlier SR 11-7 and SR 21-8 framework. OCC 2026-13 states that generative and agentic AI models "are novel and rapidly evolving" and "as such, they are not within the scope of this guidance," and that the guidance "does not set forth enforceable standards or prescriptive requirements."

Read that as a deferral rather than an exemption, because every obligation attached to the underlying action is untouched — what was withdrawn is the framework that would have specified the controls. The architectural consequence for a platform provider is direct. No control specification for agent delegation is going to arrive on a timeline that matters to a product roadmap, and whatever is eventually written will be written against what the industry has already built. The shape of this primitive is being set by product decisions rather than by regulation, and it is being set now.

The limits of this argument

There are four ways this could be wrong, and they are worth stating at the strength I would state them if I were arguing the other side.

It could be a question nobody actually asks. The entire piece rests on the claim that customers ask the authority question and find the answer missing. I have no primary measurement of how often that happens. No publisher I could trace to a methodology issues a figure for how many production multi-agent deployments propagate credentials ambiently, share a session credential across sub-agents, or lack per-delegation scoping — and the vendor surveys and analyst percentages circulating on agentic identity were not traceable to a primary methodology, so I will not repeat them. The prediction under test is this: as multi-agent workflows move from pilots to systems that write to systems of record, the authority question becomes a routine design-review question rather than an occasional one. That is a forecast, and it is falsifiable.

It could be the customer's problem rather than the platform's. The strongest structural objection is that authority modelling belongs to the customer's identity provider and policy layer, that platforms should stay out of it, and that a platform-owned delegation primitive would be an opinionated intrusion into a domain where enterprises have made expensive and incompatible choices. I take that seriously. My answer is narrow: the customer cannot construct the object from what the platform emits, because the object is created — or not created — inside the orchestration runtime, at a moment the customer has no hook into. Whoever owns the moment of handoff is the only party who can make an edge exist. That is not a claim about who should own policy; it is a claim about who owns the instant.

The cost could be prohibitive. A per-hop credential derivation that requires a round trip to an authorization server would add a network hop to every delegation in a workflow that may have dozens, and would put the issuer on the critical path of every agent handoff. That is a real objection to a real implementation. It is not an objection to the argument, because the macaroon construction demonstrates local derivation without contacting the issuer — but local derivation trades against revocation and key management in ways any honest design has to price. I am not pricing them here.

It could be reconstructable after all. Here is the condition that would falsify the core claim. If someone can show a sound procedure that takes only the telemetry a current platform emits and returns, for an arbitrary deep-hop action, the specific grant it was performed under and the bound that grant imposed — with soundness meaning it does not merely return the boundary principal relabelled — then the authority graph is recoverable and this piece is wrong. I do not believe such a procedure exists, for the reason developed above: you cannot recover an edge that was never created. But that is the shape of the disproof, and it is a shape a platform team could construct in an afternoon if I am mistaken.

What an answer would have to be

This piece is a teardown and it stops here deliberately. But the shape of what would close the gap is constrained enough by the foregoing to state without building it, and stating it is the fairest way to end an argument of this kind.

Three properties, all of which have to hold together, because any two without the third reproduce something that already exists and already fails.

1. The child names its parent, and the naming is verifiable rather than asserted. RFC 8693's `act` chain has the naming and, by design, not the verifiability at the point of use. Whatever replaces it has to be checkable by the party doing the checking.
2. The child is weaker than its parent by construction, not by policy. Monotone attenuation has to be a property of the credential, so that a holder of the narrow thing cannot produce the broad thing. The macaroon construction shows this is achievable; the question is what it looks like as a runtime primitive rather than a cookie format.
3. The constraint is evaluated where the call lands. A check performed only at an authorization server, at issuance, is a check performed before the interesting decisions were made. The bound has to travel with the credential and be enforced by the resource.

Add a fourth, which is the platform-specific one: the resulting object has to be emitted. An authority edge that exists in the runtime and never reaches the telemetry pipeline solves the security problem and leaves the customer's incident review exactly where it started.

How to build that — what the runtime primitive is, where it sits relative to the orchestration loop, what it costs per hop, and how it degrades when a downstream service knows nothing about it — is a separate piece, and a longer one. It is forthcoming as "Carrying authority across handoffs: attenuation as a runtime primitive."

What I would leave a platform team with is smaller and more immediate. The next time a customer asks which principal authorised a deep-hop action, notice that your answer is a reconstruction. Notice which primitives they are reconstructing it from, and notice that you chose those primitives. That choice was made — it is being made continuously, in every release — and as far as I can tell it has never been framed as a product decision by anyone in a position to make it differently.