SGAEIA Research Series — Article 4 of 8
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.
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:
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.
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.
At the architectural level, a delegated action should remain connected to:
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.
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.
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.
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.
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.
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
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.
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.
Within SGAEIA:
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.
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.
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.
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