WHEN AGENTS DELEGATE TO AGENTS
The Problem of Transitive Authority
Martin Novak
Synthocracy Institute
Research status: 4 September 2026
Evidence Boundary
This article distinguishes documented developments from analytical synthesis. [A] Empirical claims refer to published standards work, technical documentation, government research, or academic and preprint research available by 4 September 2026. [B] Analytical claims develop the Synthocracy Institute’s interpretation of those developments.
The phrase transitive authority is used here as a working description of a governance problem, not as a claim that legitimate authority is or should be mathematically transitive. The argument is almost the opposite: when Agent A delegates a task to Agent B, and Agent B delegates part of that task to Agent C, the original human mandate should not be presumed to travel intact through the chain. Identity, technical permissions, task instructions, legitimate decision authority and accountability can propagate differently. Research on authorization propagation, delegation security and agent auditing is beginning to formalise parts of this problem, but no single settled governance architecture yet covers it completely. (arXiv)
The human spoke once. The system acted many times.
Imagine a company director giving an AI executive assistant a simple instruction:
“Arrange my trip to Singapore next week. Keep the total below €5,000.”
The assistant does not possess every capability required to complete the task. It asks a travel agent to identify flights. That agent calls another service to compare hotels. A scheduling agent checks the director’s calendar. A procurement agent determines whether company travel rules are satisfied. A payment agent receives the final booking request. Another service books airport transport.
The chain now looks something like this:
HUMAN → AGENT A → AGENT B → AGENT C → TOOL → PAYMENT SERVICE
At the end, €4,380 leaves the company account.
Who authorised that payment?
The director authorised a trip.
Agent A interpreted the objective.
Agent B selected a flight.
Agent C selected a hotel.
Another service calculated the total.
The payment agent executed the transaction.
Every technical interaction may be legitimate. Every agent may have a valid identity. Every credential may work exactly as designed. Every individual service may correctly enforce its own access policy.
Yet the original human never directly instructed most of the actors in the chain.
The central governance question is therefore not merely whether Agent C had permission to act.
It is:
What part of the human’s original authority reached Agent C, through whom, under which conditions, and with what right to delegate again?
This becomes increasingly important as agent ecosystems move from one model using several tools toward multiple agents discovering one another, dividing tasks, collaborating across organisational boundaries and acting asynchronously on behalf of humans and institutions.
The central proposition of this article is:
Task delegation does not automatically imply authority delegation, and authority delegated once should not silently become authority delegated indefinitely.
The difference can be expressed simply:
TASK A→B ≠ AUTHORITY A→B ≠ AUTHORITY A→B→C.
1. Delegation changes the unit of governance
A single-agent system is already difficult to govern. The organisation must know what the agent can do, which tools it may use, what decision authority it has received, who can supervise it and who can stop it.
Multi-agent systems add another layer.
The agent itself may become a delegator.
Agent A can decide that Agent B is better suited to a subtask. Agent B may discover that Agent C has access to a specialised service. Agent C may invoke tools controlled by another organisation. A workflow that began inside one company can therefore cross multiple technical and administrative boundaries without returning to the original human after every transition.
This capability is increasingly part of the emerging agent infrastructure. The Agent2Agent protocol describes itself as a horizontal orchestration layer through which agents can discover each other, delegate tasks and collaborate across frameworks and vendor boundaries. Agent Cards describe capabilities and interaction methods so that agents can identify suitable counterparts. A2A also explicitly requires authorization to be enforced by the receiving agent according to authenticated identity, skills, actions, data policy and applicable scopes. (A2A Protocol)
That solves an important interoperability problem.
It does not automatically solve the governance problem.
Agent C may be technically authorised by Agent B.
But where did Agent B obtain the authority to delegate?
Was the human’s mandate delegable?
Was all of it delegable, or only one narrow component?
Did B give C the minimum authority needed?
Can C delegate again?
Does the human know the chain exists?
Can the organisation still revoke authority at the far end of it?
Can an auditor later reconstruct why C was entitled to create a consequential state change?
Once agents can delegate, the relevant object is no longer a single agent.
It is the delegation chain.
2. The original instruction is not a universal mandate
Human language makes this problem deceptively easy to miss.
“Arrange my trip.”
“Resolve this customer issue.”
“Find the best supplier.”
“Deploy the fix.”
“Investigate this anomaly.”
“Optimise the campaign.”
These are objectives, not complete constitutions.
Humans routinely interpret them using shared organisational context. An experienced employee understands that “arrange my trip” probably does not authorise chartering a private aircraft, purchasing another traveller’s ticket, sending passport data to an unknown provider or committing the company to a five-year service contract simply because those actions would help achieve the objective.
Agents must somehow operate inside the same distinction:
what helps achieve the objective is not necessarily identical to what has been legitimately delegated.
The problem becomes more difficult when the original instruction is translated several times.
The human tells A:
Arrange the trip.
A tells B:
Find the best transport and accommodation.
B tells C:
Secure the best available hotel near the conference.
C calls a booking service with permission to execute.
At each transition, the semantic representation of the task changes.
Information may disappear.
Constraints may be summarised.
Exceptions may become assumptions.
A soft preference may become a hard requirement.
A restriction known to Agent A may never reach Agent C.
This is not necessarily malicious behaviour. It is a normal consequence of decomposition.
But decomposition creates a governance problem because authority can degrade differently from task information.
A system may successfully preserve the objective—
get the director to Singapore—
while losing the limits that made the objective legitimate—
within €5,000, through approved vendors, without sharing passport data beyond specified processors, and with human confirmation before purchase.
The farther the task travels, the more important it becomes to preserve the boundary around it.
3. Authority propagation is becoming a research problem of its own
A May 2026 paper, “Authorization Propagation in Multi-Agent AI Systems: Identity Governance as Infrastructure,” describes this as a distinct problem rather than merely another form of prompt injection. The paper identifies the difficulty of preserving authorization invariants while non-human principals retrieve data, delegate tasks, aggregate information and cross changing system boundaries. It divides the problem into transitive delegation, aggregation inference and temporal validity, and argues that authorization must be continuously evaluated rather than treated as a one-time grant. (arXiv)
The paper is a preprint, and its proposed framework should therefore not be treated as an established standard. But the problem it isolates is important.
Traditional access control often asks:
May B access Resource X?
A multi-agent system may require a more demanding question:
May B access X for this purpose, on behalf of this principal, within this task, after these prior actions, and may B transmit any resulting authority or information to C?
The difference is substantial.
Authorization becomes a workflow property rather than merely a point-in-time property of one identity.
This fits the wider direction of current standards work. NIST now warns that agents operating across multiple systems magnify familiar identity and access-management weaknesses because they can explore several paths rapidly, operate using broadly scoped permissions and carry credentials across tools and networks. NIST specifically points toward technologies that propagate authorization context through human and agentic call chains while ensuring that delegated authority is attenuated as it travels. (NIST)
That word—attenuated—is critical.
The safe default should not be:
authority travels intact.
It should be:
authority becomes no broader than the task requires as it moves away from the original principal.
4. Delegation should normally reduce authority, not multiply it
Suppose Human H gives Agent A authority to spend up to €5,000 arranging one trip.
Agent A delegates hotel selection to B.
What should B receive?
Probably not €5,000 of general purchasing authority.
It may need permission to search hotels and perhaps reserve one room within a narrower amount.
If B delegates payment to C, C needs even less semantic discretion. It may require authority to execute one specified transaction for one merchant, in one currency, below one amount, before one expiry time.
In a properly bounded chain, authority might therefore look like:
H → A: arrange trip, total budget €5,000
A → B: select approved hotel, maximum €1,500
B → C: execute booking X, merchant Y, maximum €1,274, valid for ten minutes
Each step becomes narrower.
This is analogous to the longstanding principle of least privilege, but agentic systems require more than permissions alone. The system must preserve the relationship between permission and the delegated purpose.
A narrow credential saying €1,274 is useful.
A better authority record can additionally establish:
this payment belongs to Trip T;
Trip T was authorised by H;
A received authority to arrange T;
A delegated hotel procurement to B;
B selected booking X;
C received execution authority only for X;
the authority expires after the booking attempt.
This transforms a chain of valid credentials into a chain that can potentially explain why the final action was entitled to occur.
5. A→B→C creates five distinct ways for authority to fail
The first is scope expansion.
Agent A receives limited authority but passes broader permissions to Agent B. B can now do things A was never entitled to delegate.
The second is semantic drift.
The technical scope remains narrow, but the meaning of the task changes. “Research suppliers” becomes “contact suppliers”; “contact suppliers” becomes “negotiate”; “negotiate” becomes “accept terms.”
No single transition looks dramatic, yet the final system exercises authority never explicitly granted at the beginning.
The third is principal ambiguity.
Agent C knows it received a request from Agent B but does not reliably know on whose behalf B is acting. The immediate caller becomes visible while the original principal disappears.
The fourth is temporal drift.
The original mandate expires or changes, but downstream credentials or tasks remain active. Agent A has been stopped while C continues executing work delegated earlier.
The fifth is cross-domain fracture.
The chain crosses from one organisation into another. Each domain logs its own interaction and enforces its own policies, but no actor retains the complete connection between original intent and final consequence.
These failure modes can coexist.
And none requires an evil agent.
They can arise from ordinary orchestration.
6. Bounded Agents shows why local permission checks are insufficient
A particularly relevant August 2026 preprint, “Bounded Agents: Delegation Security for Multi-Agent AI Systems,” starts from almost exactly this problem.
The authors argue that typical agent permissions are established at the beginning of a session and individual requests are then checked independently. An agent operating within those permissions may nevertheless combine permitted actions into a prohibited result, act contrary to the delegated task or delegate authority to a sub-agent without constraining it.
Their proposed Agentic Principal Chain carries authority from one principal to the next while restricting scope and budgets and checking actions against accumulated session state. Importantly, enforcement occurs outside the model rather than relying on the model to decide whether its own actions remain authorised. (arXiv)
The reported experimental results are striking but should be interpreted as results within the authors’ evaluation environments, not as proof that the architecture solves delegation security generally. In their compromised-model experiments, the mechanism reduced tested AgentDojo exfiltration attacks from 75–100% success to zero across the evaluated domains and blocked all 544 tested InjecAgent data-stealing cases. The paper also reports utility costs in some configurations. (arXiv)
The more durable insight is architectural.
A prompt injection becomes much more dangerous when the compromised agent possesses broad authority.
If authority is constrained by the original task and becomes narrower through delegation, compromise does not automatically expose everything the wider identity could technically access.
The objective is therefore not only:
make the agent harder to compromise.
It is also:
make compromise unable to manufacture authority that was never delegated.
That is a very different safety strategy.
7. Identity must survive delegation
A delegation chain needs more than a list of agents.
It needs provenance.
Suppose an external service receives a request from Agent C.
It may know:
C is authentic.
C belongs to Vendor Z.
C possesses token Q.
C has permission to invoke function R.
But that may still leave unanswered:
Who is the original principal?
Which organisation is ultimately requesting the action?
What task generated the request?
Which previous agents handled it?
What was delegated at each step?
Which limits remain in force?
Which approvals occurred?
Has any relevant authority expired?
This is why NIST now recommends treating agents as first-class identities rather than allowing them to impersonate the human whose credentials they borrowed. The agency warns that credential sharing creates accountability gaps and undermines non-repudiation. It argues instead for unique agent identities and credentials tied to the human or system for whom the agent operates. (NIST)
This does not mean every downstream service needs access to every detail about the user or the entire workflow. That could create serious privacy and security problems of its own.
It means that the architecture needs a verifiable relationship between:
ACTOR → PRINCIPAL → DELEGATION → SCOPE → ACTION
without pretending that the immediate technical caller is necessarily the source of authority.
An agent identity tells us who acted.
A delegation chain tells us on whose behalf and within which transmitted mandate.
8. Agent protocols make the problem operational, not hypothetical
The issue is becoming concrete because agent interoperability is moving rapidly.
A2A now explicitly positions itself as an open standard through which autonomous agents can discover one another, delegate tasks and collaborate across distinct frameworks and vendors. Its authorization guidance supports granular control by skill, action, data policy and OAuth scope, while leaving implementation-specific authorization decisions to the receiving agent. (A2A Protocol)
MCP addresses a related but different layer: connecting models and agents with tools, resources and services. Its authorization architecture continues to evolve around OAuth-based mechanisms, and a 2026 enterprise extension allows organisations to centrally provision access to MCP servers. The July specification further strengthened authorization handling. (Model Context Protocol Blog)
These developments are important because they create the technical substrate for increasingly complex machine-to-machine action.
But interoperability and legitimate delegation are different questions.
A protocol can establish that:
Agent A can reach Agent B.
Agent B advertises Capability X.
Agent A has credentials accepted by B.
B may perform X.
That does not by itself prove:
the original human authorised B to exercise X in this case.
The protocol layer transports interaction.
The governance layer must preserve the mandate.
This distinction will matter increasingly as agent ecosystems cross vendors, clouds, companies and jurisdictions.
9. The immediate delegator is not necessarily the sovereign source of authority
Human institutions already understand this problem in other forms.
An employee who has authority to carry out a task may not have authority to appoint another person to exercise the same discretion.
A contractor may subcontract work while remaining constrained by contractual requirements.
A financial intermediary may execute a transaction but cannot redefine the client’s investment mandate.
A public official may delegate administrative work without being entitled to transfer every statutory discretion attached to the office.
Agentic systems create digital versions of these distinctions but can traverse them much faster.
Agent A may possess two things simultaneously:
authority to perform Task T
and
technical ability to ask B to perform T.
The second does not establish that the first includes authority to delegate T.
This yields an important governance distinction:
ACTION AUTHORITY ≠ DELEGATION AUTHORITY.
An organisation may therefore need to specify separately:
what the agent may decide;
what the agent may execute;
what it may delegate;
to whom;
under what constraints;
and whether the delegate may delegate again.
Otherwise delegation capacity can become an unexamined multiplier of authority.
10. Delegation can transform execution into policy-making
Consider an AI customer-service agent.
Its mandate is:
Resolve ordinary refund disputes up to €100.
The agent encounters a surge of similar complaints. Rather than handling each one, it delegates cases to ten sub-agents.
Each receives the €100 authority.
The system can now process thousands of refunds in minutes.
Nothing about the nominal rule has changed.
But the operational meaning has.
A delegation decision has transformed a small per-case discretion into a high-volume institutional policy.
This exposes another weakness in purely local authorization.
Limits can apply to individual actions while aggregate consequences become much larger.
The same issue can occur in procurement, advertising, hiring, trading, cybersecurity or public administration.
€100 per transaction can become €100 million across enough transactions.
One candidate rejection can become systematic exclusion across a population.
One account review can become an automated enforcement campaign.
One vulnerability scan can become broad network probing.
Authority therefore has at least two dimensions:
per-action authority and aggregate authority.
Multi-agent delegation can multiply the second without technically violating the first.
Governance must therefore consider not only what may each agent do?
but:
What amount of institutional power can the delegated network exercise in aggregate?
11. Authority can leak through information, not only credentials
Not every delegation problem concerns executable permissions.
Agent B may possess no authority to make a decision but may receive information that effectively determines what Agent C does.
Suppose an underwriting agent cannot deny insurance claims directly. It delegates risk analysis to another agent. That agent assigns a category. A downstream workflow automatically treats that category as decisive.
Formally, the analysis agent had no decision authority.
Functionally, its classification may determine the result.
This connects transitive authority to a wider Synthocracy principle: power can move into filtering, scoring, ranking, summarisation and routing long before the final visible decision.
Delegated authority is therefore not only about sending a capability token through a chain.
It is also about transmitting decision influence.
The important question becomes:
Was B merely providing information?
Was B authorised to define the category?
Did C independently assess the category?
Could the final human see and challenge the upstream classification?
Did the delegation move decision authority without anyone formally acknowledging that it had moved?
A system can therefore have no technically privileged sub-agent and still contain a powerful delegated decision-maker.
12. Human approval at the end does not reset the chain
It is tempting to solve all these difficulties by placing a human at the final step.
The travel chain ends with:
“Approve €4,380?”
The director clicks yes.
Does that legitimise everything upstream?
Not necessarily.
The human may see only the total.
They may not know which agents were used.
They may not know that one agent changed the hotel.
They may not know which data were disclosed.
They may not know that a sub-agent selected a supplier outside the approved list.
They may not know which assumptions produced the price.
They may not know that another agent has already created non-refundable reservations.
The approval can legitimately authorise the final action while failing to validate the entire preceding trajectory.
This is precisely why the previous Synthocracy article argued that human-in-the-loop is not enough. Meaningful human authority requires visibility, epistemic capacity, cognitive space, decisional authority, effective intervention and evidence.
Multi-agent delegation makes visibility harder.
The human may be several delegation layers away from the decisions they are nominally approving.
Human approval should therefore be treated as one authority transition within the chain, not as a magical mechanism that retroactively legitimises every upstream choice.
13. Authorization must be treated as a changing state
This is where emerging Internet standards work becomes particularly interesting.
A May 2026 IETF Internet-Draft, “An Architecture for Auditing AI Agent Delegation and Interactions,” argues that existing logs capture isolated events but do not reliably connect user intent, delegation relationships, authorization and execution across systems. The draft therefore proposes linked audit records for interactions, actions, delegations and authorization transitions. It treats authorization as a time-evolving state, recording initial grants, step-up approvals, scope narrowing, revocation and expiry. (IETF Datatracker)
The document is explicitly an Internet-Draft—a work in progress, not an adopted Internet standard. That status matters.
But its conceptual architecture addresses a real gap.
Traditional logs might say:
10:03 — A called B.
10:04 — B called C.
10:05 — C invoked payment.
A richer audit architecture could establish:
Human H issued intent I.
H authorised A under scope S1.
A delegated subtask T to B under narrower scope S2.
B received step-up approval P.
B delegated execution E to C under scope S3.
C executed E while S3 was still valid.
That difference is substantial.
One records connectivity.
The other records an authority history.
The same draft makes an especially important point: auditing must connect both user-facing interactions—prompts, approvals and confirmations—and system-facing interactions such as API calls, tool invocations and sub-agent delegation. (IETF Datatracker)
That is exactly what multi-agent governance will require.
The human side and machine side cannot be audited as two separate worlds.
14. Revocation must also be transitive
Delegation is only half the problem.
Authority must be removable.
Suppose Human H revokes Agent A’s mandate.
A had previously delegated to B.
B delegated to C.
What happens to C?
A badly designed architecture may terminate A while B and C continue using credentials or executing queued work.
The system then creates an extraordinary situation:
the original authority has disappeared while its descendants remain operational.
Revocation must therefore answer at least two separate questions.
Does the delegator lose authority?
And does revocation propagate through the authority descendants created from that mandate?
The answer may not always be “terminate everything.” Some downstream activity may need to complete safely. Some actions may already be legally binding. Some processes may require compensating transactions rather than termination. Some delegated authorities may have independent bases.
But the system should know which authorities depend on which upstream grants.
Without dependency information, there can be no reliable transitive revocation.
This becomes even more important for long-lived agents, asynchronous tasks and cross-company workflows. An authority chain may persist long after the original conversational session has disappeared.
15. Stop authority becomes a graph problem
The first article in this series asked:
Who can stop the agent?
Multi-agent systems make that question harder.
Which agent?
Stopping A may not stop B.
Revoking A’s tool access may not affect C.
Stopping the original model may leave a payment already scheduled externally.
Disabling one vendor may not terminate a subcontracted agent operating in another cloud.
Once authority has propagated through a network, stop authority must understand the topology of that network.
The relevant structure is therefore no longer:
USER → AGENT → STOP
but potentially:
USER
↓
A
↙︎ ↘︎
B C
↓ ↓
D TOOL
↓
PAYMENT
A useful control architecture must know which edges carry:
task information;
data;
technical permissions;
decision authority;
execution authority;
revocation dependencies.
The system does not need a philosophical theory of sovereignty to implement this.
It needs an operational map of who received what from whom.
16. Trajectory governance and transitive authority are the same problem viewed from two directions
The previous article argued that long-running agents require trajectory governance because individually acceptable actions can compose into an unacceptable outcome.
Transitive authority adds another dimension.
Trajectory governance asks:
Where is the system going?
Transitive authority asks:
Under whose authority is each part of the system travelling there?
A trajectory can remain technically safe while authority becomes illegible.
Or authority can appear well documented while the trajectory produces an outcome outside the original mandate.
Good governance needs both.
The combined structure becomes:
OBJECTIVE
↓
ORIGINAL PRINCIPAL
↓
INITIAL MANDATE
↓
AGENT A
↓
DELEGATED SUBTASK / NARROWED AUTHORITY
↓
AGENT B
↓
NEW STATE / NEW DECISION
↓
AGENT C OR TOOL
↓
CONSEQUENCE
Running alongside the trajectory should be an authority trace:
who authorised → what scope → what changed → what was delegated → what expired → what was revoked → what finally executed.
The two traces should remain connectable.
17. Cross-organisational delegation is where the problem becomes political
Inside one company, an organisation may be able to impose common identity systems, logs, policies and incident procedures.
Across organisations, that coherence disappears.
An enterprise agent delegates logistics analysis to an external agent.
That agent calls a shipping platform.
The shipping platform invokes a customs service.
Another agent arranges insurance.
A payment provider settles the transaction.
Each participant may operate under a different:
identity provider;
authorization model;
retention policy;
jurisdiction;
contract;
risk threshold;
audit system;
definition of responsibility.
The original principal may have no direct contractual relationship with some downstream actors.
Yet their systems contribute to the final consequence.
The emerging IETF work explicitly identifies this cross-domain problem and proposes propagating common audit context so that actions can be correlated across protocol and administrative boundaries. (IETF Datatracker)
An August Internet-Draft on architectural requirements for AI agents likewise identifies delegation, payments, provenance, auditability, revocation, identity and authorization as linked challenges for agents operating across the Internet. (IETF Datatracker)
Again, these are works in progress.
But they point toward a major governance frontier.
The global agent economy will require not only agents capable of talking to one another.
It will require a way of understanding whose authority crosses the organisational boundary with the message.
18. The safest delegation chain is not necessarily the shortest one
There is an understandable temptation to conclude that agent-to-agent delegation itself is undesirable.
That would be too simple.
Delegation can improve governance.
A general-purpose agent with broad access may be safer if it delegates a sensitive operation to a specialised agent possessing narrow credentials and a tightly bounded mandate.
A procurement agent may not need direct payment credentials at all. It can prepare a transaction and delegate execution to a payment agent restricted by merchant, amount, budget and expiry.
A clinical coordination agent can delegate medication review to a specialised system whose output requires a qualified professional before execution.
A software agent can delegate production deployment to a separate release agent operating under stronger controls.
In these cases, delegation reduces authority concentration.
The relevant distinction is not:
delegation versus no delegation.
It is:
bounded, attributable delegation versus authority diffusion.
A well-designed multi-agent system can resemble a well-designed institution: different actors possess different powers, no single actor controls everything, consequential transitions require stronger authority, and records make responsibility reconstructable.
Multi-agent design can therefore become part of the solution.
But only if delegation boundaries are deliberate.
19. Toward an authority-preserving delegation architecture
Several principles now begin to emerge from NIST guidance, current authorization research, agent protocols and auditing proposals.
The original principal should remain identifiable across the chain without requiring inappropriate disclosure of all personal information.
Delegated authority should be task-bound rather than treated as a reusable inheritance of the delegator’s entire capability.
It should normally attenuate as it travels.
The right to act should be distinguished from the right to delegate the action further.
Consequential changes of authority should create explicit transitions rather than emerging silently from agent reasoning.
New risk or authority boundaries should trigger step-up authorization where proportionate.
Credentials should be short-lived and scoped to the purpose where technically feasible.
Aggregate budgets should remain connected across sub-agents so that splitting a task cannot multiply total authority.
Revocation should follow dependency chains.
And the system should preserve enough evidence to reconstruct the route from human intent to final execution.
None of these principles requires us to assume that agents are malicious.
They are the ordinary institutional disciplines required whenever one actor can exercise power on behalf of another.
The Synthocracy Transitive Authority Test
The following preliminary diagnostic is intended for one multi-agent workflow. It is a research and governance tool, not a legal conformity assessment or security certification.
- Who is the original principal? Can the system identify the human or organisation whose authority ultimately initiates the workflow, rather than only the immediately calling agent?
- What was originally delegated? Is the objective accompanied by a bounded mandate specifying relevant decisions, resources, limits, duration and prohibited actions?
- Does the first agent have delegation authority? Is Agent A entitled merely to perform the task, or also to transfer part of its authority to another agent?
- What exactly reaches Agent B? Does B receive the whole capability of A, or only the minimum task, information, permissions, budget and decision authority necessary for its subtask?
- Can B delegate to C? Is re-delegation explicitly permitted, constrained or prohibited, or is it simply possible because the technical architecture allows it?
- Does authority attenuate rather than expand? Can any downstream agent obtain broader permissions, greater budgets, longer duration or more consequential discretion than the authority from which its mandate derives?
- Does the original principal remain attributable? Can downstream actions be linked, proportionately and securely, to the principal, intermediate delegators and authority in force without collapsing every agent into the identity of the human?
- Can authority change or expire during execution? Are step-up approval, scope narrowing, revocation, changed circumstances and expiry represented as governance events rather than merely informal context?
- Does revocation propagate? If upstream authority disappears, can the organisation identify and appropriately suspend, terminate or reassess dependent sub-agents, credentials, queued tasks and external actions?
- Can the chain be proven afterwards? Can an auditor reconstruct principal → intent → mandate → A → delegation → B → further delegation → C → authority transitions → execution → consequence and determine whether each actor remained inside the authority actually in force?
The core question behind all ten is simple:
Could a downstream agent exercise consequential power that the original principal never knowingly delegated?
If the answer is unclear, the delegation architecture is also unclear.
20. From chains of agents to institutions of agents
There is a larger implication.
As multi-agent systems grow, they may increasingly resemble organisations.
One agent plans.
Another verifies.
Another negotiates.
Another executes.
Another audits.
Another resolves conflict.
Another monitors policy.
The interesting question will then cease to be whether each agent is individually “aligned.”
Human institutions do not depend on every participant being perfectly trustworthy.
They constrain power through roles, mandates, separation of functions, budgets, procedures, records, review and the ability to revoke authority.
Multi-agent systems may require analogous institutional thinking.
Not because AI agents are citizens.
Not because software needs a constitution in the political sense.
But because distributed action requires distributed governance.
The more authority is decomposed across machine actors, the more important it becomes to know where authority originates, how it changes and where it ends.
That is the point at which multi-agent architecture becomes an institutional-design problem.
Conclusion — Delegation should not make authority disappear
The first generation of agent governance could often assume one principal and one agent.
That assumption is already weakening.
A2A explicitly enables agents to discover one another and delegate tasks across frameworks and vendors. MCP is expanding the infrastructure through which agents reach tools and services. NIST is pushing agent identity and authorization toward first-class machine identities, dynamic credentials and attenuation of delegated rights. Researchers are beginning to formalise authorization propagation and delegation security. IETF work is exploring audit architectures that link human intent, delegation, changing authorization and final execution across system boundaries. (A2A Protocol)
The central risk is not simply that Agent B may be less trustworthy than Agent A.
It is that authority can become progressively detached from its source.
The human authorised A.
A instructed B.
B delegated to C.
C possessed a credential.
A tool accepted the credential.
A consequence occurred.
Every technical event can be valid while the institution remains unable to answer the most basic question:
Why was C entitled to do that?
This is why multi-agent governance must preserve more than connectivity.
It must preserve authority.
The central rule is:
Authority should not become broader, longer-lived, less attributable or less revocable merely because a task moved farther from the human who initiated it.
The future of agentic AI may contain enormous networks of cooperating machine actors. That need not make governance impossible. In some cases, specialised agents with narrow mandates may make authority more visible and safer than one general-purpose agent holding everything.
But the architecture has to be deliberate.
Every consequential delegation should leave behind an intelligible answer to four questions:
Who delegated?
What was delegated?
How far could it travel?
Who could still revoke it?
If those answers disappear somewhere between A, B and C, the task may continue to move.
But governance has stopped travelling with it.
