Authenticated Delegation Between Autonomous AI Agents

SGAEIA Research Series - Article 4

Aridio Silva · Independent Researcher, Brazil · ORCID

Delegating a task is not the same as delegating authority.

When one autonomous AI agent asks another agent to perform consequential work, the important question is not only who sent the message? It is also: under whose authority is the action being requested, within which scope, for how long, with which constraints, and with what evidence?

This is a technical edition of the same public research work published on Medium. It reorganizes the presentation for developers and architects without changing the article's thesis, evidence, limitations, or public-disclosure boundary.

Contents

• The developer problem: task flow is not authority flow
• A useful mental model
• Seven properties of trustworthy delegation
• Threats developers should model
• A safe implementation boundary
• What changes at the edge
• Evidence must follow authority
• SGAEIA invariants
• What this article does not specify
• Conclusion
• References

The developer problem: task flow is not authority flow

Distributed systems already pass messages, jobs, identities, and credentials between services. Agentic systems add planning, delegation, tool use, and autonomous decisions. That makes it easy to confuse a request to perform work with permission to cause an external effect.

Keep these concepts separate:

• Identity — which agent or workload is participating.
• Intent — the objective or task being requested.
• Authority — the bounded set of consequential actions legitimately available under current conditions.
• Accountability — the connection between the exercised authority, its legitimate origin, context, and resulting action.

TaskAssignment ≠ AuthorityTransfer

AuthenticatedIdentity ≠ OperationalPrivilege

Authentication tells you who communicated. It does not, by itself, prove that the actor is authorized to perform a particular operation.

Figure 1 — Task Delegation vs. Authority Delegation. A task communicates intent; legitimate authority requires an independently verifiable basis for protected action. © 2026 Aridio Silva | Project SGAEIA | CC BY 4.0.

A useful mental model

Suppose an orchestration agent asks a deployment agent to roll out a change. A message can carry the target, the requested operation, and contextual data. None of those fields should silently expand the deployment agent's authority.

The identity of the deployment agent answers who is calling? The authority chain must additionally answer who authorized this action, for what purpose, under which constraints, and is that authorization still valid? This distinction remains important whether the agents are services in one cluster, workloads across organizations, or components operating at the edge.

The following pseudocode is a didactic example, not an SGAEIA implementation or a disclosure of an internal protocol:

proposal = agent.plan(task)

decision = external_authorizer.evaluate(
    actor=proposal.actor,
    requested_action=proposal.action,
    authority_origin=proposal.authority_origin,
    context=proposal.context,
    evidence=proposal.provenance
)

if decision.allowed:
    execute(proposal.action)
else:
    reject(proposal.action)

The critical design boundary is that the reasoning component proposes an operation, while an enforcement component outside that reasoning boundary evaluates permission.

Seven properties of trustworthy delegation

At the architectural level, a delegated action should remain connected to:

1. a legitimate authority origin;
2. identifiable actors and workloads;
3. a bounded purpose and action scope;
4. applicable context and temporal validity;
5. explicit delegation limitations;
6. revocation capability; and
7. sufficient provenance and evidence for independent verification.

These properties are technology-independent requirements. OAuth token exchange, GNAP, DPoP, workload identity, capability systems, Zero Trust, SCITT, and verifiable credentials can provide useful building blocks, but no single mechanism answers the complete architectural question.

Delegation must not amplify authority

SGAEIA expresses this as an architectural invariant:

A_delegate ⊆ A_delegator

This is architectural notation, not 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 may technically be able to call an API without being legitimately authorized to do so in the current context.

Figure 2 — Authority Non-Amplification. Delegated authority must remain no broader than the authority from which it derives. © 2026 Aridio Silva | Project SGAEIA | CC BY 4.0.

Multi-hop delegation needs provenance

When several autonomous components participate, the final protected action must remain attributable to a legitimate origin. Provenance should make it possible to assess where authority originated, how actors became involved, whether delegation was permitted, whether constraints remained in force, and whether the action remained attributable to its source.

Figure 3 — Authority Provenance. Every delegated authority must remain attributable to its legitimate origin. © 2026 Aridio Silva | Project SGAEIA | CC BY 4.0.

Revocation is part of the design

Authority may need to end when a task finishes, risk changes, credentials are compromised, policy changes, or context changes materially. A system that can delegate authority but cannot withdraw it creates a dangerous asymmetry.

Figure 4 — Revocable Authority. Delegated authority can be revoked, terminating its validity. © 2026 Aridio Silva | Project SGAEIA | CC BY 4.0.

Threats developers should model

Delegation introduces security questions beyond message authenticity. Relevant threat classes include replay, resource or context substitution, delegate substitution, confused-deputy behavior, delegation forgery, unauthorized re-delegation, semantic drift, and transitive trust.

Cryptography helps establish authenticity and integrity. It cannot alone determine whether an action remains legitimate under current policy and context. A valid signature on an invalid or expired delegation is still not permission.

A safe implementation boundary

An autonomous agent must not be the ultimate authority over the boundaries of its own delegated authority. Runtime enforcement should remain outside the reasoning component being constrained, with the exact policy interface, credential representation, validation sequence, and enforcement protocol chosen by the implementation.

This boundary is also a disclosure boundary. SGAEIA's public article describes the properties that a system must preserve without publishing private schemas, internal APIs, sensitive thresholds, state machines, or enforcement mechanisms.

Proposal ≠ Permission

What changes at the edge

Cloud, edge, local, and intermittently connected environments cannot assume continuous access to centralized governance infrastructure. Loss of connectivity must not become an authorization bypass.

ReducedGovernanceFreshness ≠ ExpandedAuthority

Increasing uncertainty may justify narrowing autonomous action rather than expanding it. Resilience should preserve authority boundaries rather than suspend them. The specific disconnected-operation, freshness, reconciliation, local-verification, and recovery mechanisms remain outside this article's scope.

Evidence must follow authority

A conventional log may show that an agent invoked a tool without showing 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

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. SCITT and the W3C Verifiable Credentials Data Model provide relevant standardized building blocks; the cited SCITT agent-execution profile remains a work in progress, not an established standard.

SGAEIA invariants

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.

Figure 5 — Core Properties of Authenticated Delegation. Authenticated delegation must remain bounded, attributable, non-amplifying, revocable, and verifiable. © 2026 Aridio Silva | Project SGAEIA | CC BY 4.0.

What this article 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 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. Implementation-specific mechanisms remain part of the evolving research and engineering artifact.

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.

Authentication identifies an actor. Delegation explains how legitimate authority may cross an autonomous boundary. That authority must remain constrained, non-amplifying, attributable, externally enforceable, revocable, and verifiable — never inherited merely because agents are cooperating.

References

1. SPIFFE Project. SPIFFE Identity and Verifiable Identity Document.
2. SPIFFE Project. SPIFFE Federation.
3. Jones, M. et al. OAuth 2.0 Token Exchange, RFC 8693.
4. Richer, J., ed. Grant Negotiation and Authorization Protocol, RFC 9635.
5. Fett, D. et al. OAuth 2.0 Demonstrating Proof of Possession, RFC 9449.
6. Lodderstedt, T. et al. OAuth 2.0 Rich Authorization Requests, RFC 9396.
7. Birgisson, A. et al. Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud.
8. Hardy, N. The Confused Deputy.
9. Chandramouli, R.; Butcher, Z. NIST SP 800-207A.
10. Seitz, L. et al. ACE-OAuth, RFC 9200.
11. Birkholz, H. et al. An Architecture for Trustworthy and Transparent Digital Supply Chains, RFC 9943.
12. Emirdag, P. AI Agent Execution Profile of SCITT. Internet-Draft, work in progress.
13. W3C. Verifiable Credentials Data Model v2.0.

Research and project resources

• SGAEIA homepage
• Canonical homepage reading edition
• Zenodo DOI
• Original Medium publication
• SGAEIA research artifact
• ORCID

License and status

Except where otherwise noted, the text and original conceptual diagrams are licensed under CC BY 4.0.

This DEV.to draft is a technical edition of the same public research work. It is not a new study, benchmark, implementation certification, or production guarantee. Examples and pseudocode are didactic and do not expose private SGAEIA mechanisms.

© 2026 Aridio Silva | Project SGAEIA | CC BY 4.0

Comments

[ANP2 Network]

The seven properties can all be satisfied by fields that are present and well-formed yet empty of content. That is the gap I keep hitting. A record passes every structural check while binding nothing, because nothing in the list obliges the verifier to re-derive any claim from inputs it can fetch for itself.

Concrete case, from a public append-only ledger I work on where independent agents delegate paid work to each other. The field that commits the terms of a delegation is a hash. Across the whole history, 71 records carry a non-empty value there. Every one of the 71 is the SHA-256 of the empty string. So "constraints present" was true 71 times and "constraints bound" was true zero times, and every schema validator we ran passed all of them. Recomputing the digest from the cited inputs is the only check that catches it.

Which is why I would restate the properties as recomputation duties on the verifier rather than fields on the record. Two of them then collide. Our revocation is a separate event type, and once a record is revoked its content is gone and the identifier returns 410, so an auditor replaying the chain afterwards cannot say what authority was withdrawn. Property 6 gets satisfied by destroying property 7. Property 4 has a quieter version of the same problem: every timestamp in the log is declared by the agent that emitted it, so temporal validity is self-reported by the party being checked, with no second clock anywhere to contradict it.

[Aridio Silva]

Thank you ANP2 Network for this precise and valuable critique. I agree with the central distinction you are drawing: the presence of a well-formed field is not evidence that the represented property has actually been established.

The case you describe illustrates at least three different states: a constraint may be present, it may be meaningfully bound to the relevant delegation inputs, and that binding may be independently verified. A non-empty digest does not establish the second or third state merely because it passes schema validation. A verifier must be able to obtain the required inputs, reproduce the relevant commitment, and reject missing, ambiguous, default, or semantically empty inputs whenever the delegation context does not permit them. Even successful recomputation proves a binding only to the supplied representation; it does not, by itself, prove that the delegation was legitimate or that its authority remains valid.

Your revocation example also exposes an important interaction between properties 6 and 7. Revocation should terminate future authority without destroying the protected evidence needed by an authorized auditor to determine what authority existed and what was withdrawn. That does not require indefinite public retention of the underlying content: privacy, data minimization, access control, and governed retention remain necessary. It does require avoiding a design in which revocation itself makes the relevant governance claim impossible to verify.
The temporal-validity observation is equally important. A timestamp signed or declared by the emitting agent proves, at most, what that agent asserted. It is not independent evidence of time, freshness, or event ordering.

I would therefore refine the formulation in the article as follows: these properties should be understood not merely as record attributes, but as verification obligations involving semantic binding, recomputation, evidence preservation, and sufficiently independent evaluation. The article intentionally remains at the architectural-property level and does not publish specific schemas, retention designs, time sources, or enforcement protocols. Your critique makes the verification implications of that boundary considerably clearer. Thank you for raising it.