Authority Has a Lineage

Foreword

In the previous episode, I wrote about trajectory: an autonomous system can make individually authorized decisions and still end up somewhere it was never meant to go.

A related problem is the source of authority behind those decisions.

As agents begin acting across enterprise systems, authority will pass through users, agents, tools and services. The scope of that authority may also change while a task is underway.

Security systems need to retain enough context to understand how the authority being exercised at any point came to exist.

Where did the authority come from?

Consider a manager asking an agent to review supplier contracts and identify opportunities for renegotiation.

The agent receives access to the relevant contracts and procurement data.

Later, the manager narrows the instruction to software suppliers. The original access may still exist, and the credentials may still work. A downstream system could therefore authorize a request that no longer fits the manager's current instruction.

The authorization decision needs context about the mandate behind the access.

A credential can establish what an agent is allowed to access under a particular policy. The additional context is how that authority was obtained, what task it supports, what constraints came with it and whether those conditions still apply.

This is what I mean by authority lineage.

For an autonomous system, we should be able to trace the authority behind an action back to the principal and mandate from which it originated.

Authority changes during a task

Agentic work is unlikely to follow a fixed sequence.

Instructions change as work progresses. New resources become relevant. A task that begins as analysis may later require an external action.

Suppose our contract-review agent is later allowed to contact one supplier and request revised pricing.

That instruction changes the authority available to the agent. The system now needs to retain who approved the change, what capability was added, which part of the task it applies to and how long it remains valid.

After several such changes, looking only at the current permission gives an incomplete picture.

The lineage should preserve the original mandate, the constraints attached to it, subsequent changes and the authority that remains valid at the time of the request.

Without that context, capabilities can accumulate over the course of a task while becoming progressively harder to connect to the instruction that justified them.

Authority should remain bounded as it moves

The problem becomes more difficult when work passes between systems.

An agent may invoke a specialized agent, which may call a tool or interact with a service operating under another identity. Authority is now moving across several execution boundaries.

The receiving system needs enough information to understand the authority behind the request.

If a user grants additional authority midway through the task, that change should have a traceable source. When authority is narrowed, the downstream systems relying on it should receive those constraints as well.

This becomes especially important in multi-agent environments. The identity making the final request may be several steps removed from the person or system that initiated the task.

Recent 2026 IETF Internet-Drafts are exploring related problems, including delegation chains, bounded or attenuated authority, delegation provenance and multi-hop agent authorization. An August 2026 architectural draft also discusses dynamic delegation, provenance and revocation in networks of autonomous agents. (ietf.org)

The World Economic Forum's 2026 work on agent authorization similarly includes delegated authority and operational oversight in its approach to governing agents through their deployment lifecycle. (weforum.org)

These developments point toward a broader authorization problem. Knowing which agent is making a request gives the system part of the context it needs. It also needs to understand how that agent obtained the authority it is exercising.

Lineage has to matter at runtime

The strongest use of authority lineage is during execution, while the system is deciding whether an action should proceed.

When an agent attempts an operation, the authorization system should be able to connect the request to the authority supporting it. Changes to the mandate, expired delegations and constraints introduced earlier in the task can then affect the current decision.

This makes lineage part of runtime authorization rather than information reconstructed only after an incident.

Long-running autonomous tasks make this particularly relevant. An agent may continue to possess a valid credential even after the instruction, context or delegation that justified its use has changed.

The authorization system therefore needs to evaluate the current state of the authority alongside the credential being presented.

Authority should expire with its purpose

Authority also needs a lifecycle.

Completion of the task may end it. A revised instruction may reduce its scope. A policy change may invalidate part of it. A delegation may have been created for a limited period.

Credentials do not always express these changes well, particularly when they remain technically valid beyond the task for which they were used.

An autonomous agent can continue acting during that gap.

Authority lineage gives the authorization system the context to determine whether the authority supporting an action still applies at that point in the task.

The relevant question becomes:

Does this agent still have legitimate authority for the action it is attempting now?

Doctrine

An autonomous system should carry enough authority lineage to show where its current authority came from, how it changed and whether it still applies.

Where we go next

Authority lineage helps establish the legitimacy of the authority an agent is exercising. The next question is how far that authority should allow the agent to act.

That is the subject of Episode 4.

The Autonomy Envelope