DEV Community: Aridio Silva

Authenticated Delegation Between Autonomous AI Agents

Aridio Silva — Sat, 03 Oct 2026 00:49:14 +0000

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.

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:

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.

Zero Trust for Multi-Agent AI Systems

Aridio Silva — Sat, 03 Oct 2026 00:10:13 +0000

Why identity alone is not enough when autonomous agents can delegate work, invoke tools, and create real-world effects

SGAEIA Research Series - Article 3

Aridio Silva

Independent Researcher, Brazil

Creator of SGAEIA - Secure Governed Autonomous Edge Intelligence Architecture

ORCID: 0009-0008-2411-6995

The permission problem continues after authentication
Zero Trust moves from location to action
Delegation transfers bounded authority, not trust
Tool capability is not permission
Continuing identity does not imply continuing authorization
Keep enforcement outside model discretion
Evidence and revocation are part of authorization
Edge autonomy must not expand authority
A public SGAEIA authority model
A practical engineering review
Limitations
Conclusion
References

This developer-focused edition adapts the public research article for practical architecture and security discussions. The examples are didactic, not experimental results. It preserves the public research argument and does not disclose private SGAEIA mechanisms, schemas, or implementation details.

The permission problem continues after authentication

Imagine a human asking Agent A to prepare a customer report. Agent A delegates data retrieval to Agent B. Agent B discovers a file tool, which calls an API, which reaches a service holding both the requested records and unrelated confidential data. Every component may be functioning as designed, and the human may have been authenticated correctly. The security failure appears when that initial authentication is treated as permission for every later choice in the chain.

This is the central Zero Trust problem for multi-agent AI. A workflow can begin with a legitimate user, contain individually legitimate components, and still produce an unauthorized outcome because authority was broadened, inherited, or applied outside its original purpose [1][2]. For an engineering team, the practical question is not only “Which identity authenticated?” It is also: Is this specific action, against this specific resource, permitted under the current identity, delegated authority, purpose, policy, time, and context?

The thesis of this article is that trust must not propagate merely because agents collaborate. Identity must be explicit, authority bounded, policy externally enforceable, decisions evidenced, and derived authority revocable.

Zero Trust moves from location to action

“Never trust, always verify” is useful shorthand, but Zero Trust does not mean treating every component as permanently malicious. It means refusing to convert proximity, familiarity, ownership, or a previous decision into indefinite trust. In a conventional request path, a policy decision may govern access to a resource. In an agentic path, the system must also account for who selected the action, whose authority the agent represents, whether that authority was delegated, and whether the requested effect remains inside the authorized purpose [1][2].

An agent is not only a user or service identity. It may be a decision-making intermediary that turns natural-language intent into a sequence of operations. A correct identity answers who or what is acting; it does not answer whether the resulting operation is allowed. NIST and NCCoE work on software and AI-agent identity and authorization treats identification, authentication, authorization, auditing, and accountable principals as related but distinct concerns [4][5].

The first design rule follows directly:

Authentication establishes identity. Authorization establishes permission for an action. Neither establishes continuing trust.

For developers, this means evaluating the requested action at the boundary where the effect can occur. A successful login, a valid token, or a trusted network segment should not silently become an allow decision for every downstream operation.

Delegation transfers bounded authority, not trust

Delegation is necessary in multi-agent systems. A planning agent may ask another agent to retrieve records, analyze data, or operate a specialized tool. The security objective is not to prevent delegation but to ensure that it cannot silently widen authority. Research on authenticated delegation argues that agent systems require explicit, auditable relationships connecting principals, delegates, permissions, and accountability [3].

Suppose Agent A holds authority set α and delegates subset β to Agent B. The intended relationship is β ⊆ α: the delegate receives no more authority than the delegating principal possesses, and only the subset required for the task. That relationship also needs constraints such as resource, action, purpose, time, context, and whether further delegation is permitted. These symbols are didactic SGAEIA formalizations; they are not equations specified by NIST.

Consider an agent authorized to read customer records and generate an internal report. A valid delegation might permit a second agent to read a specified set of records for ten minutes. It should not automatically permit deletion, external sharing, access to unrelated customers, or delegation to an unknown third party. Invoking Agent B is evidence that Agent A requested assistance; it is not evidence that every operation chosen by B is authorized.

For an implementation review, preserve authority provenance: who granted what, to whom, for which purpose, and under what constraints. Also distinguish authority derived from a particular grant from authority independently held by the delegate. Without that distinction, revoking one grant can either fail to terminate dependent access or incorrectly remove unrelated legitimate authority.

Tool capability is not permission

Agent frameworks commonly expose tools to a model so that it can request actions. The technical ability to discover or call a tool is a capability. Authorization is a separate decision about whether a particular invocation, with particular arguments and effects, may proceed. Research on confused-deputy failures in LLM agent frameworks shows why capability gating alone is insufficient when a model can emit side-effecting calls [8].

Assume a file tool is available to an agent because the agent needs to read one report. Tool availability does not authorize the agent to overwrite that report, enumerate unrelated directories, change permissions, or upload data. The same distinction applies to payment, messaging, infrastructure, database, and industrial-control tools. A schema shown to the model describes what can be requested; it should not become the enforcement boundary for what may execute.

The architectural rule is simple:

The model may propose an action, but a security boundary must decide whether the concrete action is permitted.

Evaluate the actor, delegated authority, operation, arguments, target resource, purpose, time, and relevant context. Treat default allow, shared credentials, and broad tool exposure as explicit risks rather than convenient implementation details. OWASP identifies tool misuse, identity and privilege abuse, insecure inter-agent communication, cascading failures, and rogue agents among major risk classes for agentic systems [6].

Continuing identity does not imply continuing authorization

An agent can retain the same identity while losing the right to act. The task may be canceled, a credential compromised, a time window expired, a policy changed, an anomaly detected, or the delegating principal’s authority revoked. Continuous verification must therefore examine more than whether the same authenticated entity remains present. It must ask whether the current action is still legitimate under current conditions [1][4].

Continuous evaluation does not mean interrupting every harmless operation with a human approval dialog. The appropriate control depends on consequence and risk. A read-only retrieval from a bounded dataset may operate under a short-lived policy decision. A payment, deployment, credential change, external message, or physical actuation may require stronger evidence, a narrower grant, or explicit approval.

Keep enforcement outside model discretion

A prompt that says “do not access confidential files” may guide model behavior, but it does not enforce access control. If the agent retains credentials and an unrestricted tool path, the model is effectively being asked to police its own authority. Prompt instructions remain useful for behavior, yet security-critical decisions need controls that do not depend solely on the model choosing to comply [7].

The familiar Policy Decision Point and Policy Enforcement Point distinction is useful here. The decision component determines whether the request satisfies policy. The enforcement component ensures that the resulting allow, deny, or constrained decision governs execution. The model should neither manufacture its own authority nor bypass the enforcement path because it can reach the underlying tool directly.

This separation also improves testing. Teams can test whether prohibited argument combinations are denied, whether missing authority fails safely, whether expired grants terminate, and whether allowed operations remain usable. Passing such tests supports a limited claim about the specified control under tested conditions; it does not prove universal security.

Evidence and revocation are part of authorization

An ephemeral ALLOW or DENY is insufficient for consequential autonomous action. Operators may later need to reconstruct which principal initiated the task, which agent acted, what delegation chain existed, which policy was evaluated, what operation and resource were involved, which conditions affected the decision, and what outcome was observed. Authenticated-delegation research emphasizes auditability and accountability, while runtime-control guidance emphasizes traceability and instrumentation [3][7].

SGAEIA connects these needs to Evidence-as-Code: security-relevant decisions should produce or contribute to machine-verifiable evidence. This does not require publishing sensitive logs or internal policy logic. It requires preserving enough attributable, protected evidence for investigation, assurance, policy testing, continuous GRC, and correction when claims or configurations change.

Revocation completes the model. If Agent B’s authority derives from a grant made by Agent A, revoking that grant should invalidate dependent authority within the defined chain. Revocation also needs an operational meaning: a record in a registry is not enough if cached credentials, queued work, or already-issued capabilities remain effective. This public article states the property; implementation-specific propagation and enforcement mechanisms remain outside its scope.

Edge autonomy must not expand authority

Edge AI moves computation closer to users, devices, sensors, and physical processes. It can reduce latency, support contextual operation, and maintain useful behavior when centralized connectivity is limited. Edge environments may include gateways, industrial systems, vehicles, robots, local servers, and cloud services, often with intermittent links and constrained resources [11][12].

These conditions create a difficult Zero Trust question: how can an agent continue useful local operation without turning disconnection into implicit permission? A local agent may continue within a previously authorized and locally enforceable envelope, but loss of connectivity should not silently grant broader access or remove the need for evidence.

Designers need explicit answers for degraded modes: which actions remain allowed, which grants expire locally, which decisions require fresh remote authority, how revocation is synchronized, and what happens when evidence cannot be delivered immediately. The answer depends on the system, but “the network was unavailable” cannot serve as a general authorization exception.

A public SGAEIA authority model

The public SGAEIA synthesis can be expressed as a sequence of responsibilities:

Identity → Delegation validation → Authority evaluation → Context evaluation → Policy decision → Enforcement → Action → Evidence → Re-evaluation or revocation

This is an architectural synthesis informed by Zero Trust, authenticated delegation, emerging agent identity guidance, runtime controls, agent-security research, and the SGAEIA research artifact. It is not a quotation from NIST or OWASP, and it does not claim that those organizations endorse SGAEIA [1]-[10].

The model can be summarized through ten public architectural invariants:

Trust must not be inherited solely through delegation.
Authentication must not be treated as equivalent to authorization.
Tool availability must not imply permission for every invocation.
Delegated authority must remain bounded by its legitimate source and explicit scope.
Consequential actions should be authorized where authority is exercised.
Continuing identity must not imply continuing authorization.
Security-critical enforcement should remain outside model discretion.
Revocation should remain effective across dependent authority chains.
Authority provenance should remain traceable.
Security-relevant decisions should produce verifiable evidence.

These invariants are SGAEIA propositions at the public architectural level. They define properties to evaluate; they do not claim that an implementation is secure merely because it uses the same terminology.

A practical engineering review

Before allowing an autonomous or multi-agent workflow to create consequential effects, a team should be able to answer:

Identity: Can every acting principal, agent, service, and relevant tool be resolved to an accountable identity?
Authority: What exact action is permitted, against which resource, for which purpose, and for how long?
Delegation: Can a delegate prove the origin, scope, limits, and current validity of its grant?
Tool use: Does the system authorize the concrete invocation and arguments, rather than merely exposing a tool?
Enforcement: Can the model or agent bypass the policy decision or enforcement path?
Context: Which changes in risk, environment, resource, task, or policy force re-evaluation?
Evidence: Can the organization reconstruct what was requested, decided, executed, and observed?
Revocation: How quickly do dependent grants, queued work, and active sessions lose authority?
Edge operation: Which actions remain legitimate during degraded connectivity, and how is that envelope enforced?
Assurance: Which tests or arguments support each claim, and what remains untested?

A missing answer does not prove that the system is unsafe, but it identifies a governance or assurance gap. The value of the review lies in making hidden assumptions visible before an agent’s capability becomes an external effect.

Limitations

This article presents a conceptual architecture and review method. It does not specify a complete authorization protocol, credential format, policy language, state machine, revocation algorithm, or production implementation. It does not establish certification, legal compliance, or universal security. The appropriate control strength depends on the assets, actors, threat model, operating environment, consequence, and evidence available in each system.

Several cited sources are emerging standards, concept papers, surveys, or research contributions. Their presence demonstrates active work on agent identity, authorization, runtime control, and security; it does not make every recommendation equivalent or independently validated. SGAEIA propositions must be evaluated through explicit requirements, threat models, tests, and evidence before implementation claims are made.

Conclusion

Multi-agent AI extends Zero Trust beyond users, devices, and network access. An authenticated agent may still lack permission for a requested operation. A valid delegation may authorize only a narrow subset of actions. An available tool may remain unauthorized for particular arguments or resources. An authorization that was legitimate moments ago may need to be re-evaluated after context, policy, risk, or authority changes.

The resulting design principle is concise:

Do not inherit trust from collaboration. Verify identity, validate delegated authority, authorize the concrete action, enforce the decision outside model discretion, preserve evidence, and retain the ability to revoke.

Autonomy remains useful when authority remains explicit. Zero Trust for multi-agent systems is therefore not an attempt to eliminate agent collaboration; it is a discipline for preventing collaboration from silently becoming implicit power.

References

Rose, S., Borchert, O., Mitchell, S., & Connelly, S. (2020). Zero Trust Architecture. NIST SP 800-207. DOI.
Chandramouli, R., & Butcher, Z. (2023). A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Location Environments. NIST SP 800-207A. DOI.
South, T., Marro, S., Hardjono, T., Mahari, R., Whitney, C. D., Chan, A., & Pentland, A. (2025). “Position: AI Agents Need Authenticated Delegation.” Proceedings of Machine Learning Research, 267, 82211-82231. PMLR.
Riggs, J., Hamin, M., Perry, N., Edelman, B., & Cihon, P. (2026). Summary Analysis of Responses to the Request for Information Regarding Security Considerations for AI Agents. NIST. NIST.
Booth, H., Fisher, W., Galluzzo, R., & Roberts, J. (2026). Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization. NIST NCCoE. NCCoE.
OWASP GenAI Security Project. (2025). OWASP Top 10 for Agentic Applications for 2026. OWASP.
OWASP GenAI Security Project. (2026). Agent Control Standard (ACS). OWASP.
Mellafe Zuvic, D. (2026). Capability Gates Are Not Authorization: Confused-Deputy Failures in LLM Agent Frameworks. arXiv:2606.28679. arXiv.
Chhabra, A., Datta, S., Nahin, S. K., & Mohapatra, P. (2026). Agentic AI Security: Threats, Defenses, Evaluation, and Open Challenges. IEEE Access, 14. DOI.
Silva, Aridio. (2026). SGAEIA: Secure Governed Autonomous Edge Intelligence Architecture. Version 0.3.4. Zenodo. DOI.
Zhou, Z., Chen, X., Li, E., Zeng, L., Luo, K., & Zhang, J. (2019). “Edge Intelligence: Paving the Last Mile of Artificial Intelligence With Edge Computing.” Proceedings of the IEEE, 107(8), 1738-1762. DOI.
Singh, R., & Gill, S. S. (2023). “Edge AI: A Survey.” Internet of Things and Cyber-Physical Systems, 3, 71-92. DOI.

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: 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/
Zenodo record: https://doi.org/10.5281/zenodo.22903766

Figures

The cover image is not numbered. Figures 1-5 in this DEV edition reuse the five conceptual figures from the Medium/Zenodo public article in the same order. The adaptation does not introduce a new research result.

All images should use the public Article 3 assets and retain visible attribution and publication metadata. They communicate public properties and high-level governance relationships without exposing private protocols, state machines, enforcement internals, or reconstruction-enabling schemas.

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).

The SGAEIA software research artifact remains subject to its own Apache License 2.0.

Autonomous AI. Governed by Design. Trusted by Evidence.

Read the complete public article

Read the canonical article and supporting materials on the SGAEIA homepage. The DEV post is a technical adaptation of the same public research work. The original Medium edition is available at Zero Trust for Multi-Agent AI Systems, and the persistent archival record is Zenodo DOI 10.5281/zenodo.22903766.

Why Autonomous AI Agents Need Bounded and Revocable Authority

Aridio Silva — Thu, 01 Oct 2026 20:24:14 +0000

Why trustworthy Agentic AI needs explicit, enforceable, time-bounded, and revocable permission to act**

SGAEIA Research Series - Article 2

Aridio Silva

Independent Researcher
Creator of SGAEIA - Secure Governed Autonomous Edge Intelligence Architecture

ORCID: 0009-0008-2411-6995

The permission problem changes when software can act
Capability is not authority
Make permissions specific to the task
Delegation must not widen access
Plan for expiry and revocation
Check the whole action path
Make controls enforceable and reviewable
A practical design checklist
Conclusion
References

This developer-focused edition adapts the public research article for practical design discussions. Its examples are illustrative, not experimental results. It presents public architectural properties and does not disclose private SGAEIA mechanisms or implementation details.

The permission problem changes when software can act

A traditional application often waits for a person to choose the next step. An autonomous AI agent may interpret a goal, call tools, move data between services, and delegate subtasks with less direct human involvement. Once a system can cause changes, security has to consider the agent’s authority to act, not only whether it can access information [1, 2].

Authentication can identify an agent or validate a request. That is necessary, but it does not answer whether this agent should perform a particular operation on a particular resource, for this task, under current conditions, or how long that permission should last. The central design question becomes: What may this agent do, on whose behalf, under which conditions, and how can that authority be withdrawn?

This article develops bounded and revocable authority as a security property for autonomous AI systems and a core principle of SGAEIA - Secure Governed Autonomous Edge Intelligence Architecture [3]. The aim is to let agents perform useful work while keeping their permissions explicit, limited, enforceable, observable, and withdrawable.

Capability is not authority

An email integration might technically allow an agent to search, read, send, forward, label, and delete messages. If the task is “Find this week’s invoices and summarize them,” the technical availability of those operations does not mean the agent should be allowed to use all of them. A read-and-summarize task does not implicitly authorize forwarding attachments or deleting messages.

That distinction is simple and important:

Capability describes what an agent can technically do. Authority describes what it is legitimately permitted to do.

For a developer, the practical implication is that a broad tool connection should not become a broad authorization grant. Give the task only the access it needs, and treat read, write, delete, export, approve, execute, and delegate as distinct operations. Agent-security guidance similarly emphasizes dedicated identities, least privilege, action and resource scoping, controlled tool access, and auditability [4].

Make permissions specific to the task

“Agent A has access to System X” leaves important questions unanswered. A safer design discussion identifies the agent, task scope, resource, permitted action, relevant context, duration, and whether delegation is allowed. These are conceptual dimensions for reasoning about authority, not a required implementation schema [3].

For example, an infrastructure agent assigned to remediate one service incident might need temporary write access to that service. That task alone does not justify permanent access to every service or permission to approve unrelated changes. Similarly, preparing a financial transaction does not automatically authorize the agent to approve or execute it. Least privilege for an autonomous system means the least practical authority for the current purpose, including a time limit [4, 5].

Delegation must not widen access

Multi-agent workflows can pass a task from a person to one agent, then to another agent, a tool, and an external service. Each handoff creates an accountability question: where did the permission come from, what part of it was delegated, and did the recipient gain more authority than the delegator had? Research on authenticated delegation highlights the importance of accountability and traceable delegation relationships [1].

A useful design rule is that delegated authority should be equal to or narrower than the authority from which it derives. If Agent A may read a customer record, passing a subtask to Agent B should not give B permission to modify that record. If A’s permission expires after ten minutes, B’s derived permission should not last a day. A downstream agent should not gain authority simply because another component passed it a task [1, 3].

Permissions can also combine into a capability no one intended. An agent with access to internal documents, a transformation tool, and an external messaging service might be able to retrieve sensitive information, transform it, and send it outside the organization. Each integration may look acceptable in isolation; the composed action path can create a different risk [4, 8]. Review what the agent can accomplish across the whole workflow, not only the permission list for each individual tool.

Plan for expiry and revocation

A permission that was appropriate when a task started may become inappropriate if the task is cancelled, the context changes, a credential is suspected of compromise, or the work is complete. Temporary work should not quietly leave behind permanent privilege. Agent security therefore needs a way to expire or withdraw authority during operation, with downstream systems checking whether permission remains valid [4, 6].

Revocation also raises a delegation question. If Agent A’s grant is withdrawn, should agents whose permissions came only from A continue acting? A governed design should be able to trace where delegated authority came from and consider how revocation applies to dependent grants. A separate, independently authorized grant may need different treatment; the key is to make the provenance and decision reviewable [1, 3].

Check the whole action path

A one-time “allow” decision may not be enough for a workflow that can invoke multiple tools or delegate work. A practical lifecycle to consider is: request an action, evaluate whether it is authorized, grant limited permission, enforce the decision, observe relevant execution, re-evaluate if conditions change, and revoke or expire the permission when it is no longer valid. This is a conceptual SGAEIA model, not a product-specific implementation prescription [3].

At the edge, agents may operate with intermittent connectivity or partial local context. Resilience can require an agent to continue within authority already granted, but a network interruption should not automatically become permission to expand that authority. This separates operational autonomy from unbounded authority [3, 9, 10].

Make controls enforceable and reviewable

A prompt such as “do not delete files” can guide an agent’s behavior, but it is not the same as an authorization control enforced by the systems that expose the files or tools. Security boundaries should not depend solely on an agent choosing to obey them. Independent enforcement, appropriately scoped access, and runtime controls help keep a mistaken or manipulated plan from becoming an authorized external action [4, 6].

After an action, a reviewer should be able to determine who acted, on whose behalf, what resource and operation were involved, what authority applied, whether delegation occurred, and what evidence supports the decision. Auditability is part of the architecture: it helps teams investigate outcomes and assess whether the system stayed within its intended boundaries [1, 4]. Evidence has limits; logs or tests alone do not certify a deployment.

A practical design checklist

For each consequential action an AI agent can take, ask:

Actor and purpose: Which agent is acting, and for what task?
Resource and operation: Which specific resource can it affect, and which actions are allowed?
Conditions and duration: When is the permission valid, and when does it expire?
Delegation: Can this authority be passed on, and can the next agent receive anything broader?
Withdrawal: How can the permission be suspended or revoked if the task ends or risk changes?
Evidence: What can an operator or reviewer inspect afterward?
Composition: What can the agent accomplish by combining its tools and permissions?

These questions translate a broad “agent has access” statement into decisions engineers can review across identity, scope, resource, action, context, time, and delegation. The exact controls depend on the system and threat model; using a checklist does not by itself establish that a system is secure [3, 5, 7].

Conclusion

The security of autonomous AI cannot be reduced to whether an agent is authenticated. Identity helps answer who is acting; authority must also answer what the agent may do, against which resources, under what conditions, for how long, on whose behalf, and with what right to delegate.

The engineering goal is not to eliminate useful autonomy. It is to make permission to act explicit, bounded, enforceable, traceable, and revocable. As the SGAEIA principle puts it: Autonomous AI. Governed by Design. Trusted by Evidence.

References

South, T., Marro, S., Hardjono, T., Mahari, R., Whitney, C. D., Chan, A., & Pentland, A. (2025). “Position: AI Agents Need Authenticated Delegation.” Proceedings of the 42nd International Conference on Machine Learning, PMLR 267, 82211–82231. PMLR.
Chhabra, A., Datta, S., Nahin, S. K., & Mohapatra, P. (2026). “Agentic AI Security: Threats, Defenses, Evaluation, and Open Challenges.” IEEE Access, 14, 49455–49482. DOI.
Silva, Aridio. (2026). SGAEIA - Secure Governed Autonomous Edge Intelligence Architecture. Zenodo. DOI.
Yser, Y., & Kohlenberg, T. (2026, July 16). “Least privilege for AI agents: Identity, access, and tool binding.” Microsoft Security Blog. Microsoft.
Rose, S., Borchert, O., Mitchell, S., & Connelly, S. (2020). Zero Trust Architecture. NIST SP 800-207. DOI.
OWASP GenAI Security Project. (2026, September 1). Agent Control Standard (ACS). OWASP.
Tabassi, E. (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1. DOI.
OWASP GenAI Security Project. (2025, December 9). OWASP Top 10 for Agentic Applications for 2026. OWASP.
Zhou, Z., Chen, X., Li, E., Zeng, L., Luo, K., & Zhang, J. (2019). “Edge Intelligence: Paving the Last Mile of Artificial Intelligence With Edge Computing.” Proceedings of the IEEE, 107(8), 1738–1762. DOI.
Singh, R., & Gill, S. S. (2023). “Edge AI: A survey.” Internet of Things and Cyber-Physical Systems, 3, 71–92. DOI.

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 exploring architectural foundations for secure, governed, auditable, and trustworthy autonomous AI systems operating across distributed edge-cloud environments.

Research & Project Resources

ORCID: 0009-0008-2411-6995
Google Scholar: Profile
Zenodo - SGAEIA Community: Community
Medium: Aridio Silva
SGAEIA Homepage: https://aridiosilva.com/sgaeia
SGAEIA LinkedIn: Company page
Public article on Medium: Why Autonomous AI Agents Need Bounded and Revocable Authority
Zenodo record: Version 1.0, DOI 10.5281/zenodo.22715664

Suggested citation

Silva, Aridio. (2026). Why Autonomous AI Agents Need Bounded and Revocable Authority (Version 1.0). Zenodo. https://doi.org/10.5281/zenodo.22715664.

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.

Read the complete public article

Read the canonical article and supporting materials on the SGAEIA homepage. The DEV post is a technical adaptation of the same public research work.

From Edge AI to Governed Autonomous Edge Intelligence

Aridio Silva — Thu, 01 Oct 2026 15:51:10 +0000

Why autonomous AI agents need security, governance, and bounded authority by design

SGAEIA Research Series — Article 1

Aridio Silva

Independent Researcher, Brazil

Creator of SGAEIA — Secure Governed Autonomous Edge Intelligence Architecture

ORCID: 0009–0008–2411–6995

Why developers need to think beyond model security
From a recommendation to an action
Delegation should not silently expand authority
Bound authority and make it withdrawable
Apply Zero Trust to agent actions
Make governance part of the engineering lifecycle
Design security in from the start
Governed Autonomous Edge Intelligence
Replace technologies without weakening security properties
Questions to take into your next design review
References

This developer-focused edition distills the public Zenodo article into architectural questions and design principles. It is conceptual: no private protocols, implementation logic, state machines, policy internals, or reconstruction-enabling details are disclosed.

Why developers need to think beyond model security

For many years, AI systems mostly analyzed data, generated predictions, classified information, or produced content. People considered the output and decided what to do next. Agentic AI changes that pattern: an agent may interpret a goal, call a tool, use an external service, coordinate with another agent, and cause a change in a digital or physical system [3, 5].

At the same time, AI workloads are moving from centralized cloud platforms toward devices, gateways, local servers, private infrastructure, and cloud services. Edge deployment can help address latency, connectivity, privacy, resilience, bandwidth, and operational constraints. When autonomy and distribution meet, however, a system distributes more than computation: it may distribute the authority to act [1, 2].

Figure 1 — From Computation to Authority. This figure contrasts distributed computation with the additional distribution of operational authority in Agentic Edge AI. © 2026 Aridio Silva | Project SGAEIA | CC BY 4.0.

That change creates a practical engineering question: how can an AI system receive enough authority to be useful while keeping that authority limited, reviewable, and withdrawable? Protecting models, data, networks, and devices remains necessary, but developers also need to reason about which actions an agent may take, under what conditions, and on whose behalf.

From a recommendation to an action

Imagine two systems monitoring industrial telemetry. One recommends that an operator stop a machine. Another is authorized to authenticate to an industrial control system, invoke a tool, stop the machine, open an incident record, and ask another agent to investigate. Both use AI, but the second crosses from producing information into exercising operational authority [3, 5].

This distinction applies beyond industrial control. Any agent that can change a record, invoke a service, access a resource, delegate a task, or trigger a physical action creates security questions about the action itself. The central concern is not simply whether the model produced a plausible response; it is whether the requested action is authorized in its current context.

Delegation should not silently expand authority

A multi-agent workflow can pass work from a person to an agent, from that agent to another agent, and then through a tool or service to an external system. Authentication helps establish which actor is making a request, but identity alone does not explain what that actor may do, why it may do it, or who granted the relevant permission [4, 8].

A useful public design principle is that delegated authority should remain equal to or narrower than the authority from which it came. In practical terms, a downstream agent should not gain broader permission merely because a task passed through another component. Developers should be able to explain the origin and limits of authority at an appropriate level, while implementation details remain specific to the system and its threat model [4, 15].

Figure 2 — Chain of Delegated Authority in a Multi-Agent System. This conceptual figure traces how authority can pass among agents and systems while remaining bounded by its originating grant. © 2026 Aridio Silva | Project SGAEIA | CC BY 4.0.

Bound authority and make it withdrawable

The article describes authority as a combination of identity, scope, resource, action, context, time, and delegation constraints. These are conceptual dimensions, not a required implementation schema. They help teams ask whether a permission is attached to the right actor, resource, operation, environment, period, and delegation boundary [15].

Figure 3 — Bounded and Revocable Authority for Autonomous AI Agents. The figure summarizes authority as explicit, contextual, constrained, and capable of withdrawal. © 2026 Aridio Silva | Project SGAEIA | CC BY 4.0.

Authority also needs a way to be reduced or withdrawn when an agent is compromised, behaves unexpectedly, violates policy, or operates under changed conditions. Stopping a model process alone may not be enough if other components can still accept its requests. The broader architectural principle is that enforcement should not depend solely on an autonomous agent choosing to obey a limit [9, 15].

Apply Zero Trust to agent actions

A network location or deployment environment is not, by itself, proof that an agent should be trusted. Agents can run at the edge, call cloud services, use external tools, collaborate with remote agents, or cross administrative boundaries. A Zero Trust perspective therefore asks for authorization to be evaluated in relation to the requested action and its relevant context [9, 10].

For engineering teams, this means treating each consequential action as a decision point. The system should have a way to assess the actor, permission, policy, resource sensitivity, context, and delegation conditions that matter for that action. The article presents this as a principle for governed Agentic AI, not as a claim that one particular runtime design guarantees security [9, 10].

Make governance part of the engineering lifecycle

Policies, standards, procedures, and audits remain important, but a policy stored only in a document cannot directly stop an unauthorized machine-speed action. For autonomous systems, governance needs to connect to engineering mechanisms that can make constraints machine-readable, enforceable, observable, and testable [8, 11, 15].

The article frames this direction as executable governance: policies define constraints, system components enforce them, telemetry records relevant decisions, evidence helps show whether controls were applied, and tests examine whether intended security properties hold. This does not remove human governance. It gives people more timely information to inspect and challenge.

Evidence-as-Code extends this idea by treating evidence about architecture, controls, tests, policy enforcement, and system behavior as something that can be generated and evaluated through repeatable processes. The aim is to ask not only whether a system passed a past review, but what evidence supports the claim that it remains within its authorized boundaries under the conditions being assessed. Such evidence has limits and does not by itself certify a deployment [11, 15].

Design security in from the start

In distributed multi-agent systems, adding identity, authority, delegation, revocation, auditability, trust boundaries, and policy enforcement after deployment can require substantial redesign. Security-by-Design treats these properties as architectural concerns; Security-First makes security assumptions part of early engineering choices; and Shift-Left brings threat analysis and verification earlier into development [12, 14, 15].

Threat modeling and applicable security guidance can help teams identify risks and derive requirements, tests, and evidence. The specific methods and controls should fit the system, domain, and threat model. Naming a framework or using a checklist is not evidence that a system is secure [6, 7, 13, 14].

Governed Autonomous Edge Intelligence

The article uses Governed Autonomous Edge Intelligence for the direction that emerges when distributed edge intelligence and autonomous action are considered together. Its central proposition is that a sustainable architecture needs to connect intelligence with authority, security, governance, and evidence. The aim is not to eliminate useful autonomy, but to make the authority to act explicit, bounded, traceable, enforceable, reviewable, and withdrawable [1, 2, 3, 5, 15].

SGAEIA — Secure Governed Autonomous Edge Intelligence Architecture — is presented in the public article as an open, technology-neutral research initiative exploring these architectural requirements. It is a research architecture, not a claim of production certification or universal assurance. Its public discussion focuses on concepts, properties, and research direction rather than implementation-sensitive mechanisms [15].

The article describes five connected dimensions: intelligence (perception, reasoning, planning, decisions, and collaboration); authority (permission to act and delegate); security (identity, authentication, policy, and runtime protection); governance (risk, accountability, compliance, and traceability); and evidence (observability, auditability, and material that can support verification). These dimensions may apply across edge devices, industrial systems, vehicles, IoT sensors, gateways, robotics, private infrastructure, regional nodes, and cloud services [15].

Figure 4 — Governed Autonomous Edge Intelligence (SGAEIA). This high-level illustration connects intelligence, authority, security, governance, and evidence across edge-cloud environments. © 2026 Aridio Silva | Project SGAEIA | CC BY 4.0.

Replace technologies without weakening security properties

Models, agent runtimes, communication protocols, identity systems, policy engines, and infrastructure components change quickly. A reference architecture tied too closely to one implementation may become difficult to evolve. The article therefore explores security-preserving substitution: a component should be replaceable without silently weakening the architectural security properties associated with it [15].

This is a design objective, not an automatic outcome of technology neutrality. Teams still need to evaluate each replacement against the properties, assumptions, and evidence relevant to their system.

Questions to take into your next design review

When an AI agent can act, ask: Should it be allowed to perform this action? Who granted the authority? Can it delegate that authority, and under what limits? What conditions change the decision? How can authority be withdrawn? What evidence will let a reviewer understand what happened [3, 5, 15]?

The architectural shift can be summarized simply: Edge AI distributes computation; Agentic Edge AI distributes computation and authority. Governed Autonomous Edge Intelligence asks how that authority can remain bounded, enforceable, auditable, and revocable. The result is a research direction summarized by the SGAEIA principle: Autonomous AI. Governed by Design. Trusted by Evidence.

References

Zhou, Z., Chen, X., Li, E., Zeng, L., Luo, K., & Zhang, J. (2019). “Edge Intelligence: Paving the Last Mile of Artificial Intelligence With Edge Computing.” Proceedings of the IEEE, 107(8), 1738–1762. DOI: 10.1109/JPROC.2019.2918951.
Singh, R., & Gill, S. S. (2023). “Edge AI: A Survey.” Internet of Things and Cyber-Physical Systems, 3, 71–92. DOI: 10.1016/j.iotcps.2023.02.004.
Wang, L., Ma, C., Feng, X., et al. (2024). “A Survey on Large Language Model Based Autonomous Agents.” Frontiers of Computer Science, 18, 186345. DOI: 10.1007/s11704-024-40231-1.
South, T., Marro, S., Hardjono, T., Mahari, R., Whitney, C. D., Chan, A., & Pentland, A. (2025). “Position: AI Agents Need Authenticated Delegation.” Proceedings of the 42nd International Conference on Machine Learning, PMLR 267, 82211–82231. PMLR.
Datta, S., Nahin, S. K., Chhabra, A., & Mohapatra, P. (2025). “Agentic AI Security: Threats, Defenses, Evaluation, and Open Challenges.” arXiv:2510.23883.
OWASP GenAI Security Project. (2025). “Agentic AI — Threats and Mitigations.” OWASP Agentic Security Initiative.
OWASP GenAI Security Project. (2026). OWASP Top 10 for Agentic Applications 2026. OWASP.
OWASP GenAI Security Project. (2026). Agent Control Standard (ACS). OWASP.
Rose, S., Borchert, O., Mitchell, S., & Connelly, S. (2020). Zero Trust Architecture. NIST SP 800-207. DOI: 10.6028/NIST.SP.800-207.
Chandramouli, R., & Butcher, Z. (2023). A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments. NIST SP 800-207A. DOI: 10.6028/NIST.SP.800-207A.
Tabassi, E. (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1. DOI: 10.6028/NIST.AI.100-1.
Scarfone, K., Souppaya, M., & Dodson, D. (2022). Secure Software Development Framework (SSDF) Version 1.1. NIST SP 800-218. DOI: 10.6028/NIST.SP.800-218.
OWASP Foundation. Threat Modeling Cheat Sheet. OWASP Cheat Sheet Series.
CISA et al. (2023). Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software. CISA publication.
Silva, Aridio. (2026). SGAEIA — Secure Governed Autonomous Edge Intelligence Architecture. Research artifact. DOI: 10.5281/zenodo.22557796.

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: 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–4 are numbered sequentially and referenced consistently in the article.

All final images follow the SGAEIA Image Editorial Standard and contain embedded publication metadata.

Creator: Aridio Silva
Project: SGAEIA
License: CC BY 4.0
Institutional URL: https://aridiosilva.com/sgaeia

The images are original conceptual illustrations prepared for this article. They remain within the public disclosure boundary by communicating concepts, properties, and high-level governance relationships without exposing private protocols, algorithms, state machines, policy logic, or reconstruction-enabling implementation details.

Suggested citation

Silva, A. (2026). From Edge AI to Governed Autonomous Edge Intelligence (Version 1.0). Zenodo. https://doi.org/10.5281/zenodo.22715250.

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).

The SGAEIA software research artifact remains subject to its own Apache License 2.0.

Autonomous AI. Governed by Design. Trusted by Evidence.

Read the complete article on the SGAEIA homepage

For the full public article and its figures, visit the SGAEIA homepage.

DEV Community: Aridio Silva

Authenticated Delegation Between Autonomous AI Agents

Contents

The developer problem: task flow is not authority flow

A useful mental model

Seven properties of trustworthy delegation

Delegation must not amplify authority

Multi-hop delegation needs provenance

Revocation is part of the design

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

Research and project resources

License and status

Zero Trust for Multi-Agent AI Systems

Contents

The permission problem continues after authentication

Zero Trust moves from location to action

Delegation transfers bounded authority, not trust

Tool capability is not permission

Continuing identity does not imply continuing authorization

Keep enforcement outside model discretion

Evidence and revocation are part of authorization

Edge autonomy must not expand authority

A public SGAEIA authority model

A practical engineering review

Limitations

Conclusion

References

About the Author

Research & Project Resources

Figures

License

Read the complete public article

Why Autonomous AI Agents Need Bounded and Revocable Authority

Contents

The permission problem changes when software can act

Capability is not authority

Make permissions specific to the task

Delegation must not widen access

Plan for expiry and revocation

Check the whole action path

Make controls enforceable and reviewable

A practical design checklist

Conclusion

References

About the Author

Research & Project Resources

Suggested citation

License

Read the complete public article

From Edge AI to Governed Autonomous Edge Intelligence

Contents

Why developers need to think beyond model security

From a recommendation to an action

Delegation should not silently expand authority

Bound authority and make it withdrawable

Apply Zero Trust to agent actions

Make governance part of the engineering lifecycle

Design security in from the start

Governed Autonomous Edge Intelligence

Replace technologies without weakening security properties

Questions to take into your next design review

References

About the Author

Research & Project Resources

Figures

Suggested citation

License

Read the complete article on the SGAEIA homepage