自主 AI 智能体之间的认证式授权：SGAEIA 研究系列第 4 篇

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.

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:

a legitimate authority origin;
identifiable actors and workloads;
a bounded purpose and action scope;
applicable context and temporal validity;
explicit delegation limitations;
revocation capability; and
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.

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.

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.

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

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

Research and project resources

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.