Delegation & chains

Agents delegate — a supervisor hands a step to a planner, a planner to a worker. The question every resource server should be able to answer is “who really acted, and through whom?” auth51 makes that answer part of the token: the delegation path is recorded, hashed, and checked, so the chain can’t be forged or quietly rewritten.

The delegation assertion

When a call happens inside a multi-agent run, the intent token carries a delegation assertion — the record of the path that led to this action. It names the workflow and step being executed and the agent executing it, and it carries an ordered, hashed representation of every agent that participated on the way here. It’s what turns “a token from some agent” into “a token from this agent, reached through this path.”

Hashed so it can’t be rewritten

The chain of agent ids is joined in order and hashed — a compact delegation_chain value carried in the token. Completed workflow steps are hashed the same way into step_sequence_hash. Because the hash is over the ordered path, altering who delegated to whom, or reordering the hops, changes the value — and a resource server that recomputes it will see the mismatch, without calling anyone.

What the Authority validates at mint

Before it mints for a delegated call, the Authority checks the path is real: every agent named in the chain is registered, the chain represents a delegation each parent actually authorized, and the requesting agent is the last link in it. A chain that names an unregistered agent, or claims a hop no parent authorized, or puts the requester somewhere other than the end, is refused.