Delegating a task is not the same as delegating authority. An autonomous agent must be able to verify who delegated authority, on whose behalf, within which scope, for how long, with which constraints, and whether that authority remains valid.
Abstract
Distributed multi-agent systems increasingly allow autonomous AI agents to assign tasks, invoke tools, coordinate specialized capabilities, and act across organizational and computational boundaries. Yet assigning a task is not equivalent to transferring legitimate authority.
This article develops authenticated delegation as an architectural security requirement for autonomous multi-agent systems. Delegated authority must remain attributable to a legitimate source, explicitly bounded, resistant to amplification, contextually valid, revocable, and supported by sufficient provenance and evidence for independent verification.
Building upon workload identity, authorization, Zero Trust, least privilege, and delegated access, the article distinguishes authentication from authority and task propagation from authority propagation. Within SGAEIA, these concerns are expressed as technology-independent architectural properties and invariants. The objective is not to prescribe a delegation protocol or credential format, but to establish what must remain true when legitimate authority crosses autonomous-agent boundaries.
Keywords
Agentic AI; autonomous AI agents; multi-agent systems; authenticated delegation; bounded authority; authority provenance; constrained delegation; revocation; Zero Trust; AI security; Evidence-as-Code; SGAEIA.
1. Introduction — Delegation Is More Than Message Passing
Multi-agent AI systems exchange objectives, tasks, plans, and results. At the messaging layer, these interactions can appear to be ordinary task exchanges. At the security layer, every consequential transition raises a different question:
What makes the next autonomous actor legitimately authorized to
act?
A message can communicate intent without conveying authority. An authenticated request can still be unauthorized. Authority may expire or be revoked. An agent permitted to act may not be permitted to delegate.
Delegating a task is not the same as delegating authority.
Authenticated delegation addresses an architectural requirement between bounded authority and distributed autonomous execution: how can legitimate authority remain bounded, attributable, and verifiable when autonomous work crosses agent boundaries?
2. Task Delegation Is Not Authority Delegation
A task describes desired work. Authority describes which consequential actions may legitimately be performed in pursuit of that work.
Four concepts should remain separate:
- Identity — which agent or workload is participating.
- Intent — the objective, task, or requested work.
- Authority — the bounded set of consequential actions
legitimately available under applicable conditions.
- Accountability — the connection between exercised authority,
its legitimate origin, context, and resulting action.
TaskAssignment ≠ AuthorityTransfer
AuthenticatedIdentity ≠ OperationalPrivilege
Authentication establishes who communicated. It does not, by itself, establish legitimate authority for a particular action.
3. Identity Is Necessary — But Identity Is Not Authority
Workload-identity systems can establish cryptographically verifiable identities for applications, services, and workloads [1][2]. This answers who is calling?
Autonomous delegation adds another question: under whose legitimate authority is this consequential action being requested?
Established authorization standards such as OAuth 2.0 Token Exchange [3] and GNAP [4] demonstrate that authenticated identity and delegated authorization are distinct concerns.
An agent may have a valid workload identity while acting for a principal, purpose, organizational context, and bounded authority across administrative domains.
Identity establishes the actor. Authority establishes what that
actor may legitimately cause to happen.
4. What Makes Delegation Trustworthy?
At an architectural level, delegated action should remain connected to a legitimate authority origin, identifiable actors, bounded purpose and authority, applicable context, temporal validity, delegation limitations, revocation capability, and sufficient provenance for verification.
Existing standards provide useful building blocks. DPoP [5] and Rich Authorization Requests [6], for example, illustrate complementary mechanisms for sender-constrained authorization and structured authorization data.
The specific representation of these properties is intentionally outside the scope of this article.
Authenticity ≠ Authorization
Cryptographic authenticity establishes who produced a message. It does not automatically establish that the actor possessed legitimate authority to authorize the requested operation.
5. Delegation Must Not Amplify Authority
SGAEIA establishes Authority Non-Amplification as a core architectural invariant. Capability-oriented authorization research has long explored attenuation; Macaroons provide one relevant example of constraining delegated authority through caveats [7].
A_delegate ⊆ A_delegator
This is architectural notation rather than a universal authorization calculus.
Delegation may preserve or narrow legitimate authority. It must not
silently create authority that did not previously exist.
Capability ≠ Authority
An agent’s technical capabilities do not redefine the authority being delegated.
6. Multi-Hop Delegation Requires Authority Provenance
The final protected action must remain attributable to a legitimate origin even when several autonomous components participate.
Authority provenance should establish, at an appropriate assurance level, where authority originated, how autonomous actors became involved, whether delegation was permitted, whether applicable constraints remained in force, and whether the resulting action remained attributable to its origin.
The encoding, graph representation, credential mechanism, verification algorithm, and distributed consistency model are outside the scope of this article.
7. Delegation Creates Distinct Security Threats
Important threat classes include:
- replay;
- resource or context substitution;
- delegate substitution;
- confused-deputy behavior, a longstanding problem in capability-system literature [8];
- delegation forgery;
- unauthorized re-delegation;
- semantic drift;
- transitive trust.
These threats exploit ambiguity about where authority came from,
what it permits, or whether it remains valid.
Cryptography helps establish authenticity and integrity, but cannot alone determine whether an action remains legitimate under current policy and context.
8. Runtime Enforcement Must Remain External to Agent Intent
Autonomous reasoning may propose an operation, but a recommendation does not create authority.
Proposal ≠ Permission
Capability ≠ Authority
Zero Trust rejects implicit trust and emphasizes explicit, identity-centric authentication and authorization [9]. SGAEIA extends that direction to autonomous execution.
Delegated authority must remain subject to trusted enforcement outside the reasoning component being constrained.
An autonomous agent must not be the ultimate authority over the
boundaries of its own delegated authority.
The internal validation sequence, policy interface, credential representation, and enforcement protocol are intentionally not specified here.
9. Revocation Is Part of Delegation
Authority that can be delegated but cannot be withdrawn creates a dangerous asymmetry. Authority may need to end when a task finishes, risk changes, an agent becomes suspect, credentials may be compromised, policy changes, or context changes materially.
Delegated authority must remain revocable when the conditions
supporting its legitimacy no longer hold.
Dependency tracking, propagation, consistency, and distributed revocation mechanisms are outside the scope of this article.
10. Distributed and Edge Environments Make Delegation Harder
Cloud, edge, local, and intermittently connected environments cannot assume continuous access to centralized governance infrastructure. ACE-OAuth demonstrates that authentication and authorization can be adapted to constrained environments [10]. Yet loss of connectivity must not become an authorization bypass.
ReducedGovernanceFreshness ≠ ExpandedAuthority
Increasing uncertainty may justify narrowing autonomous action rather than expanding it.
Resilience must preserve authority boundaries rather than suspend
them.
Disconnected-operation, freshness, reconciliation, local-verification, and recovery mechanisms are intentionally not defined here.
11. Evidence Must Follow Delegated Authority
Conventional logs may show that an agent invoked a tool without establishing why it possessed legitimate authority, where that authority originated, or whether the action remained inside its delegated boundary.
Authenticated delegation therefore intersects with Evidence-as-Code.
DelegatedAction ⇒ VerifiableAuthorityProvenance
SCITT provides an IETF architecture for signed statements and transparency services intended to improve auditability, accountability, provenance, and independent verification [11]. An April 2026 Internet-Draft explores a SCITT profile for verifiable records of autonomous AI-agent actions [12]; it remains work in progress, not an established standard. W3C Verifiable Credentials Data Model v2.0 provides another standardized foundation for machine-verifiable credentials [13].
The objective is sufficient, attributable, integrity-protected evidence for the governance claim being evaluated. Evidence schemas, correlation mechanisms, storage models, and verification architecture are deliberately outside scope.
12. SGAEIA Architectural Invariants for Authenticated Delegation
Within SGAEIA:
- No task implies authority.
- No identity implies privilege.
- No delegation without legitimate authority.
- Permission to act does not imply unlimited re-delegation.
- No authority amplification.
- No transitive trust.
- No autonomous expansion of authority.
- No delegated authority without provenance.
- No irreversible delegation.
- No governance exception merely because execution is distributed.
- No security-relevant delegated action without sufficient
evidence.
These are SGAEIA architectural propositions, not quotations from the referenced standards.
13. Established Building Blocks and the Architectural Gap
Workload identity, OAuth delegation mechanisms, proof-of-possession, capability-oriented systems, relationship-based authorization, Zero Trust, provenance, and verifiable-record technologies address important parts of the problem.
But no single mechanism, by itself, answers the complete architectural question:
How can authority remain bounded, non-amplifying, attributable,
revocable, governable, and verifiable while autonomous execution
crosses multiple agents and infrastructure boundaries?
SGAEIA treats this as an architectural composition problem. Existing technologies may provide building blocks; the architecture must determine the properties their composition is required to preserve.
14. What This Article Intentionally Does Not Specify
This article addresses architectural requirements: legitimate authority origin, bounded delegation, non-amplification, provenance, external runtime enforceability, revocation, and verifiable evidence.
It deliberately does not specify implementation mechanisms such as credential and grant schemas, delegation protocols, validation algorithms, policy semantics, authority-derivation representations, revocation propagation mechanisms, distributed consistency strategies, offline synchronization, evidence schemas, or enforcement interfaces.
This boundary is intentional. SGAEIA treats authenticated delegation first as an architectural requirement. Implementation-specific mechanisms remain part of the evolving research and engineering artifact.
15. Conclusion
Autonomous agents need more than authenticated communication. They need an accountable relationship between the work they are asked to perform and the legitimate authority required to perform consequential actions.
Task ≠ Authority
Authentication identifies an actor. Delegation explains how legitimate authority may cross an autonomous boundary.
Delegation must remain constrained, non-amplifying, attributable, externally enforceable, revocable, and verifiable.
Authority may cross agent boundaries only as a bounded,
attributable, revocable, and verifiable derivation — never as
inherited trust.
Without that distinction, multi-agent systems risk transforming specialization into transitive privilege. With it, autonomous collaboration can scale while preserving governance.
References
[1] SPIFFE Project. “SPIFFE Identity and Verifiable Identity Document.” SPIFFE Standard. https://spiffe.io/docs/latest/spiffe-specs/spiffe-id/
[2] SPIFFE Project. “SPIFFE Federation.” SPIFFE Standard. https://spiffe.io/docs/latest/spiffe-specs/spiffe\_federation/
[3] Jones, M., Nadalin, A., Campbell, B., Bradley, J., and C. Mortimore. “OAuth 2.0 Token Exchange.” RFC 8693, January 2020. https://doi.org/10.17487/RFC8693
[4] Richer, J., Ed., and F. Imbault. “Grant Negotiation and Authorization Protocol (GNAP).” RFC 9635, October 2024. https://doi.org/10.17487/RFC9635
[5] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite. “OAuth 2.0 Demonstrating Proof of Possession (DPoP).” RFC 9449, September 2023. https://doi.org/10.17487/RFC9449
[6] Lodderstedt, T., Richer, J., and B. Campbell. “OAuth 2.0 Rich Authorization Requests.” RFC 9396, May 2023. https://doi.org/10.17487/RFC9396
[7] Birgisson, A., Politz, J. G., Erlingsson, Ú., Taly, A., Vrable, M., and M. Lentczner. “Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud.” NDSS Symposium, 2014. https://doi.org/10.14722/ndss.2014.23212
[8] Hardy, N. “The Confused Deputy (or Why Capabilities Might Have Been Invented).” ACM SIGOPS Operating Systems Review, 22(4), 1988, pp. 36–38. https://doi.org/10.1145/54289.871709
[9] Chandramouli, R., and Z. Butcher. A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments. NIST SP 800–207A, September 2023. https://doi.org/10.6028/NIST.SP.800-207A
[10] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and H. Tschofenig. “Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth).” RFC 9200, August 2022. https://doi.org/10.17487/RFC9200
[11] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker. “An Architecture for Trustworthy and Transparent Digital Supply Chains.” RFC 9943, June 2026. https://doi.org/10.17487/RFC9943
[12] Emirdag, P. “AI Agent Execution Profile of SCITT.” Internet-Draft, draft-emirdag-scitt-ai-agent-execution-00, April 2026. Work in progress. https://datatracker.ietf.org/doc/draft-emirdag-scitt-ai-agent-execution/
[13] World Wide Web Consortium. Verifiable Credentials Data Model v2.0. W3C Recommendation, 15 May 2025. https://www.w3.org/TR/vc-data-model-2.0/
Suggested citation
Silva, A. (2026). Authenticated Delegation Between Autonomous AI Agents (Version 2.0). Zenodo. https://doi.org/10.5281/zenodo.22727194
Read the full article on Medium
About the Author
Aridio Silva is an independent researcher based in Brazil working on the architecture, security, governance, and trustworthiness of autonomous and distributed artificial intelligence systems.
His research focuses on Agentic AI, Multi-Agent Systems, Edge AI, AI Security, Zero Trust, Security-by-Design, AI Governance, Spec-Driven Development, and continuous security assurance.
He is the creator and lead researcher of SGAEIA — Secure Governed Autonomous Edge Intelligence Architecture, an open research initiative investigating architectural foundations for secure, governed, auditable, and trustworthy autonomous AI systems operating across distributed edge-cloud environments.
Research & Project Resources
Aridio Silva — Independent Researcher, Brazil
- ORCID: https://orcid.org/0009-0008-2411-6995
- Google Scholar: https://scholar.google.com/citations?user=rPn5O48AAAAJ
- Zenodo — SGAEIA Community: https://zenodo.org/communities/sgaeia
- OpenAIRE: https://explore.openaire.eu/search/find?fv0=Aridio%20Silva&f0=q
- Medium profile: https://medium.com/@aridiosilva
- GitHub: https://github.com/aridiosilva
- LinkedIn: https://www.linkedin.com/in/aridio-silva-74997111/
- SGAEIA Research Artifact / DOI: https://doi.org/10.5281/zenodo.22557796
- Homepage: https://aridiosilva.com
- SGAEIA Homepage: https://aridiosilva.com/sgaeia
- SGAEIA LinkedIn: https://www.linkedin.com/company/sgaeia/
Figures
The cover image is not numbered. Figures 1–5 are numbered sequentially and referenced consistently in this article.
All images are original conceptual illustrations prepared for this article. They carry visible attribution and publication metadata identifying Aridio Silva as creator, SGAEIA as the project, and CC BY 4.0 as the license. They remain within the public disclosure boundary by communicating properties and high-level governance relationships without exposing private protocols, algorithms, state machines, policy logic, or reconstruction-enabling implementation details.
License
Except where otherwise noted, the text and original conceptual illustrations in this article are licensed under the Creative Commons Attribution 4.0 International License (CC BY 4.0).
© 2026 Aridio Silva. You may share and adapt this work for any purpose, provided appropriate attribution is given.
The SGAEIA software research artifact remains subject to its own Apache License 2.0.
Autonomous AI. Governed by Design. Trusted by Evidence.
Series continuity
Published/current entries in the SGAEIA Research Series include:
- From Edge AI to Governed Autonomous Edge Intelligence
- Why Autonomous AI Agents Need Bounded and Revocable Authority
- Zero Trust for Multi-Agent AI Systems
- Authenticated Delegation Between Autonomous AI Agents
- Continuous GRC for Agentic AI
- Evidence-as-Code: Making AI Governance Verifiable
- Security-by-Design for Distributed Agentic AI
- SGAEIA: A Reference Architecture for Secure Governed Autonomous Edge Intelligence
- When AI Begins to Build AI
- Rogue AI Agents: When Autonomous Systems Become a Collective
- From Model Capability to Governed Action: An Architecture for Secure Agentic AI
- Ten Days That Exposed the Governance Gap in Frontier AI
- When AI Hallucination Becomes Action
- AI’s Alien Mind: How to Govern What We Cannot Fully Understand
- When AI Agents Form Societies: Is Security a Property of the Model or the System?
- When AI Improves AI: Governing Recursive Intelligence Acceleration