Zero Trust for Multi-Agent AI Systems

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

Zero Trust for Multi-Agent AI Systems. © 2026 Aridio Silva | Project SGAEIA | CC BY 4.0.

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

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.

Figure 1 - The Multi-Agent Trust Problem. © 2026 Aridio Silva | Project SGAEIA | CC BY 4.0.

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.

Figure 2 - Trust Must Not Propagate With Delegation. © 2026 Aridio Silva | Project SGAEIA | CC BY 4.0.

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

Figure 3 - Continuous Authority Verification Loop. © 2026 Aridio Silva | Project SGAEIA | CC BY 4.0.

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

Figure 4 - Zero-Trust Multi-Agent Enforcement Architecture. © 2026 Aridio Silva | Project SGAEIA | CC BY 4.0.

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

Figure 5 - SGAEIA Zero-Trust Authority Model. © 2026 Aridio Silva | Project SGAEIA | CC BY 4.0.

The model can be summarized through ten public architectural invariants:

1. Trust must not be inherited solely through delegation.
2. Authentication must not be treated as equivalent to authorization.
3. Tool availability must not imply permission for every invocation.
4. Delegated authority must remain bounded by its legitimate source and explicit scope.
5. Consequential actions should be authorized where authority is exercised.
6. Continuing identity must not imply continuing authorization.
7. Security-critical enforcement should remain outside model discretion.
8. Revocation should remain effective across dependent authority chains.
9. Authority provenance should remain traceable.
10. 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

1. Rose, S., Borchert, O., Mitchell, S., & Connelly, S. (2020). Zero Trust Architecture. NIST SP 800-207. DOI.
2. 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.
3. 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.
4. 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.
5. Booth, H., Fisher, W., Galluzzo, R., & Roberts, J. (2026). Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization. NIST NCCoE. NCCoE.
6. OWASP GenAI Security Project. (2025). OWASP Top 10 for Agentic Applications for 2026. OWASP.
7. OWASP GenAI Security Project. (2026). Agent Control Standard (ACS). OWASP.
8. Mellafe Zuvic, D. (2026). Capability Gates Are Not Authorization: Confused-Deputy Failures in LLM Agent Frameworks. arXiv:2606.28679. arXiv.
9. Chhabra, A., Datta, S., Nahin, S. K., & Mohapatra, P. (2026). Agentic AI Security: Threats, Defenses, Evaluation, and Open Challenges. IEEE Access, 14. DOI.
10. Silva, Aridio. (2026). SGAEIA: Secure Governed Autonomous Edge Intelligence Architecture. Version 0.3.4. Zenodo. DOI.
11. 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.
12. 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

1. ORCID: https://orcid.org/0009-0008-2411-6995
2. Google Scholar: https://scholar.google.com/citations?user=rPn5O48AAAAJ
3. Zenodo - SGAEIA Community: https://zenodo.org/communities/sgaeia
4. OpenAIRE: https://explore.openaire.eu/search/find?fv0=Aridio%20Silva&f0=q
5. Medium: https://medium.com/@aridiosilva
6. GitHub: https://github.com/aridiosilva
7. LinkedIn: https://www.linkedin.com/in/aridio-silva-74997111/
8. SGAEIA Research Artifact / DOI: https://doi.org/10.5281/zenodo.22557796
9. Homepage: https://aridiosilva.com
10. SGAEIA Homepage: https://aridiosilva.com/sgaeia
11. SGAEIA LinkedIn: https://www.linkedin.com/company/sgaeia/
12. 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).

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