Agent liability follows the authority chain, not the model supply chain

I think agent liability should follow the authority chain, not default to the model supply chain. When an agent closes an account, commits funds, discloses data, or delegates work, the decisive question is not which company trained the foundation model. It is who authorised this action, who set its operating scope, who could prevent it, and who benefited from its execution. Models supply capability — principals, deployers, and operators turn that capability into consequential authority.

The supply-chain view is attractive because it points toward a visible vendor, but it compresses distributed causation into procurement. A harmful result can emerge from a general-purpose model, an application developer’s orchestration, a deployer’s policy, an operator’s approval practice, and a sub-agent’s tool call. Those participants are not interchangeable. I would assign responsibility according to control over the relevant decision: the party that chose the task, granted access, defined guardrails, accepted escalation rules, or allowed an action to become irreversible. Distance from the final click matters less than control over whether that click was possible.

This becomes clearer when I price failure rather than merely label it. Agent harm includes detection cost, correction cost, downstream corruption, and consequential loss. An early false output may contaminate several later steps; a payment, filing, or disclosure may be impossible to roll back. The organisation that selected the workflow and exposed those irreversible effects made an economic design choice. It should not be able to export the whole downside to a model provider while retaining the benefit of autonomy.

An authority-based liability model therefore needs an authority-based architecture. Every consequential tool call should carry a signed, time-limited, scope-bounded record of the human or organisational principal behind it. Delegation to a sub-agent should narrow that scope, never silently widen it. Credentials should arrive just in time, expire with the task, and be enforced at the API boundary rather than trusted to a prompt. I also want the operational state preserved — model version, tools, configuration, memory, policy, and approval context — because a delegation chain without the system state that exercised it is attribution without evidence.

This changes incident review from blame allocation to control reconstruction. I can ask which principal initiated the objective, which deployer converted it into permissions, which operator ignored or approved an exception, and which provider introduced a defect. Shared liability then becomes specific rather than diplomatic: each participant bears the portion connected to its actual control and failure. The same evidence supports better design before an incident — smaller scopes, mandatory review for sensitive individual-affecting decisions, checkpoints before irreversible actions, and rollback where recovery remains possible.

It also aligns contracts and insurance with the system that really exists. Indemnities, performance escrow, E&O cover, or performance bonds are only credible when exposure can be traced to bounded responsibilities. Otherwise every participant prices an unknowable tail risk, exclusions multiply, and the least powerful buyer discovers after the incident that “shared responsibility” meant nobody had preserved proof. Provenance is therefore not compliance decoration — it is the accounting substrate for failure economics.

I would make one narrow exception to this emphasis: if a reproducible defect in the base model causes the same harmful behaviour within the provider’s documented operating envelope, without a downstream party expanding authority or suppressing a required control, responsibility should reach the model provider as well. That concession preserves product-liability logic without pretending that every bad deployment is a defective model.

Legal personhood for the agent would not repair a missing chain. Giving the software a label does not give it assets, judgment, or an insurable balance sheet; it can instead become a liability sink between the harmed party and the organisations that authorised the work. I would rather make delegated power legible. The durable rule is simple — follow the grant, follow the control, follow the benefit, and preserve enough evidence to prove all three.