Zero Trust for Multi-Agent AI Systems

Abstract

Traditional Zero Trust asks systems to avoid granting implicit trust because of network location or asset ownership. Autonomous AI introduces additional boundaries: one agent can delegate to another, select a tool, call an API, act through a service, and affect a digital or physical resource. In that environment, authenticating the first participant does not establish that every downstream action is legitimate. This article develops a public, high-level SGAEIA model for applying Zero Trust to multi-agent systems. It separates identity from authority, capability from permission, delegation from trust propagation, and model reasoning from policy enforcement. It then derives practical architectural questions for continuous authorization, evidence generation, revocation, and operation at the edge.

Introduction — A valid request can still produce an invalid action

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. NIST Zero Trust Architecture rejects implicit trust based solely on network location or asset ownership and treats access as a resource-centered decision informed by identity and policy. NIST SP 800-207A extends that reasoning to cloud-native applications and service identities. [1][2]

Autonomous agents make this principle more demanding because they can select actions dynamically. They can plan, delegate, invoke tools, combine context, and continue operating while conditions change. The relevant question is therefore not simply, “Is this an authenticated agent?” It is:

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.

1. Zero Trust moves from location to action

“Never trust, always verify” is a 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]

That distinction matters because 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.

This rule prevents a common shortcut: Authenticated Agent → Trusted Agent → Allowed Action. A safer model evaluates the requested action against the relevant resource, authority, policy, and context at the point where the effect can occur.

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

This produces two practical requirements. First, the system must preserve authority provenance: who granted what, to whom, for which purpose, and under what constraints. Second, the system must 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.

3. Tool availability is not permission to use the tool

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.

For architects, this means evaluating the actor, delegated authority, operation, arguments, target resource, purpose, time, and relevant context. It also means treating default allow, shared credentials, and broad tool exposure as explicit risks rather than convenient implementation details. The OWASP Top 10 for Agentic Applications identifies tool misuse, identity and privilege abuse, insecure inter-agent communication, cascading failures, and rogue agents among the major risk classes for agentic systems. [6]

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

NIST SP 800-207 allows policy decisions to incorporate dynamic information such as identity, asset state, behavioral and environmental attributes. The NIST analysis of public responses on AI-agent security likewise reports broad agreement that established cybersecurity practices remain relevant but require adaptation for risks specific to agents. [1][4]

Continuous evaluation should not be interpreted as an instruction to interrupt 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. The principle is proportionality: the more consequential and irreversible the effect, the stronger the authorization and evidence expected at that boundary.

5. Put enforcement outside the model’s 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.

The OWASP Agent Control Standard describes inspectable, traceable, instrumentable agents and runtime control through policy-enforcement hooks. At a high level, this supports separating agent reasoning from a policy decision and enforcement path. [7] The public SGAEIA model represents that separation without prescribing a private implementation protocol.

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 the tested conditions; it does not prove universal security.

6. Authorization needs evidence and revocation

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 OWASP ACS emphasizes runtime 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.

7. Edge autonomy must not become authority expansion

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? SGAEIA separates operational autonomy from authority expansion. 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 therefore need explicit answers for degraded modes. Which actions remain allowed? Which grants expire locally? Which decisions require fresh remote authority? How is revocation synchronized? What happens when evidence cannot be delivered immediately? Which cyber-physical actions must fail closed, and which require a carefully bounded safety mode? The answer depends on the system, but “the network was unavailable” cannot serve as a general authorization exception.

8. The SGAEIA Zero-Trust 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:

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.

9. A practical review for architects and engineering teams

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

• 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 are labeled as project interpretations and 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.

Autonomous AI. Governed by Design. Trusted by Evidence.

Bibliography / References

Suggested citation

Silva, Aridio. (2026). Zero Trust for Multi-Agent AI Systems (Version 1.0). Zenodo. https://doi.org/10.5281/zenodo.22903766

Zenodo is the persistent source for files, version, license, and citation data.

Read the full article on Medium

Read the technical adaptation on DEV Community

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/

Figures

The cover image is not numbered. Figures 1–5 are numbered sequentially and referenced consistently in this article.

All images are original conceptual illustrations prepared for this article. They carry visible attribution and publication metadata identifying Aridio Silva as creator, SGAEIA as the project, and CC BY 4.0 as the license. They remain within the public disclosure boundary by communicating properties and high-level governance relationships without exposing private protocols, algorithms, state machines, policy logic, or reconstruction-enabling implementation details.

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.

Series continuity

Published/current entries in the SGAEIA Research Series include:

1. From Edge AI to Governed Autonomous Edge Intelligence
2. Why Autonomous AI Agents Need Bounded and Revocable Authority
3. Zero Trust for Multi-Agent AI Systems
4. Authenticated Delegation Between Autonomous AI Agents
5. Continuous GRC for Agentic AI
6. Evidence-as-Code: Making AI Governance Verifiable
7. Security-by-Design for Distributed Agentic AI
8. SGAEIA: A Reference Architecture for Secure Governed Autonomous Edge Intelligence
9. When AI Begins to Build AI
10. Rogue AI Agents: When Autonomous Systems Become a Collective
11. From Model Capability to Governed Action: An Architecture for Secure Agentic AI
12. Ten Days That Exposed the Governance Gap in Frontier AI
13. When AI Hallucination Becomes Action
14. AI’s Alien Mind: How to Govern What We Cannot Fully Understand
15. When AI Agents Form Societies: Is Security a Property of the Model or the System?
16. When AI Improves AI: Governing Recursive Intelligence Acceleration