From model trust to software topology: a Perspective on structurally governed agentic AI systems

1 Introduction

Large language models have moved from being text-generation systems toward becoming components of operational software. The transformer architecture made large-scale sequence modeling technically viable (Vaswani et al., 2017), while later scaling and instruction-following work showed that language models could perform diverse tasks from prompts, examples, and human-preference-aligned training (Brown et al., 2020; Ouyang et al., 2022). These developments encouraged a model-centered view of safety, in which the principal objective was to make the model more aligned, helpful, harmless, and robust. That objective remains important, but it is no longer sufficient for the systems now being built around language models.

The reason is architectural. Contemporary language-model applications increasingly retrieve information, plan subtasks, call tools, modify code, execute tests, and interact with external software environments. Retrieval-augmented generation grounded model outputs in external knowledge stores (Lewis et al., 2020), ReAct interleaved reasoning with environment-directed action (Yao et al., 2023), and tool-use research connected models to external application programming interfaces (Schick et al., 2023). Surveys of autonomous language-model agents similarly describe systems that combine memory, planning, tools, and environmental feedback into persistent workflows (Wang et al., 2024).

Multiagent frameworks also coordinate specialized agents through structured conversations (Wu et al., 2024), while surveys describe the workflows, infrastructure, and interaction mechanisms of such systems (Li et al., 2024). This shift is especially visible in software engineering, where repository-level tasks require issue interpretation, codebase navigation, file editing, execution, and test-based validation (Jimenez et al., 2024; Zhang et al., 2024; Liu J. et al., 2026). Recent agent-harness research further suggests that execution environments, tool interfaces, context management, observability, verification, and governance are becoming independent determinants of agent reliability (Li et al., 2026). Thus, the safety of tool-using agents cannot be evaluated only at the model level, because the surrounding software harness determines how model outputs are converted into actions.

This Perspective argues that safe agentic AI should be treated as a software-architecture problem. When a model only produces text, failure may mislead a user; when an agent can write files, execute commands, call services, or alter software artifacts, failure can modify external state. The proposed shift is therefore from asking whether one model can be trusted sufficiently to asking how software topology can prevent any single component from converting error, manipulation, or goal drift into unsupervised action. The argument is informed by Polos, an open reference specification that instantiates this topology through role contracts, typed message schemas, declared flow graphs, bounded loop controls, governed self-improvement pathways, and validator-checked structural invariants (Coeus Institute., 2026).

2 Related work and problem positioning

Model-centered safety has produced important progress. Reinforcement learning from human feedback and related alignment methods improve instruction following and reduce undesirable outputs under many evaluation conditions (Ouyang et al., 2022). However, alignment methods do not by themselves define the authority boundary between a model and the external systems it can affect. Once a model retrieves context, selects tools, executes commands, edits files, or calls services, safety depends not only on model behavior, but also on what the surrounding software permits it to do.

2.1 Prompt injection and tool authority

This limitation becomes acute when agents consume untrusted or semi-trusted context. Retrieval-augmented generation and reasoning-action loops bring external documents, tool outputs, and environmental observations into the model context (Lewis et al., 2020; Yao et al., 2023). Indirect prompt-injection research shows that malicious instructions hidden in retrieved content can manipulate language-model-integrated applications, including systems with external tool access (Greshake et al., 2023; Liu et al., 2023; Zhan et al., 2025). Recent work further shows that prompt injection can target tool selection itself and can operate through AI-assisted development environments, tool poisoning, hidden parameters, cross-tool interactions, and unauthorized tool invocation (Shi et al., 2026; Huang et al., 2026).

2.2 Contemporary agent-governance work

Recent agent-safety work increasingly treats safety as a property of the deployed agent system rather than the model alone. Ghosh et al. (2025) propose a safety and security framework for real-world agentic systems that combines risk taxonomy, contextual mitigation, human oversight, and sandboxed red teaming. AgentDoG introduces diagnostic guardrails for agent safety and security through trajectory monitoring and root-cause diagnosis (Liu D. et al., 2026). Wang et al. (2026) argue that agentic safety is also an epistemic property, because self-improving systems must remain teachable and correctable over time. Guardrail work likewise emphasizes safe, secure, and controllable steering of LLM applications through moderation, policy controls, evaluation, and red teaming (Rebedea et al., 2025).

2.3 Positioning of this Perspective

These works are complementary, but the contribution here is narrower and more architectural. Polos does not primarily propose another behavioral guardrail, risk classifier, or red-team benchmark. It specifies a checkable software topology in which decision, action, oversight, adaptation, and authority are separated through role contracts, typed messages, flow graphs, scoped capabilities, and validator-checked invariants. The research gap addressed here is therefore how agentic capabilities should be wired so that they cannot collapse into a single unrestricted point of control.

3 Safety as software topology

3.1 Core invariant

A topology-centered view begins with a simple premise: no single component in a tool-using agentic system should be treated as fully trustworthy. This premise is familiar in computer security. The reference-monitor concept requires mediation that is always invoked, protected from tampering, and sufficiently simple to analyse (Anderson, 1972). Saltzer and Schroeder (1975) similarly identify least privilege, separation of privilege, complete mediation, and fail-safe defaults as foundational protection principles. The central design principle can therefore be stated as follows: components that decide should not directly act, and components that act should not act without supervision.

3.2 Authority separation

In this Perspective, software topology refers to the explicit arrangement of components, message paths, gates, credentials, and allowed actions. A planning component may interpret a user objective or select a task pathway, but it should not hold standing effectful tools. An execution component may modify files, call services, or run commands, but only under scoped, time-limited, and task-specific authority. Oversight components may reject, request revision, quarantine, or halt, but should not exercise the same tools whose outputs they judge.

3.3 Mediation and provenance

Complete mediation becomes an architectural requirement rather than a policy aspiration. Every consequential message path should be declared, every worker result should be gated before acceptance, every uncertain verdict should fail closed, and every high-consequence action should require authorization at the tool boundary. Recent provenance-oriented work similarly tracks how untrusted context propagates into agent decisions and checks whether proposed actions are justified by trustworthy evidence before execution (Weng et al., 2026).

3.4 Bounded loops and adaptation

Bounded autonomy is also a topological property. ReAct-style loops and repository-level software agents can iterate over planning, action, observation, and revision (Yao et al., 2023; Jimenez et al., 2024), but unattended loops can drift, exhaust resources, or accept false completion signals. Structurally governed loops therefore require step, time, cost, and scope ceilings, stable user-intent references, and verifier-checked completion. Similarly, reflective memory should change how a task is approached, not what the system is authorized to do (Shinn et al., 2023). In this sense, alignment improves component behavior, while topology limits what component failure can do.

4 Five-plane topology and polos realization

Figure 1 operationalises the topology-centered argument through a five-plane reference architecture comprising intent, orchestration, execution, oversight, and adaptation. The figure should be read as an authority map rather than as a conventional workflow diagram. Its central invariant is that deciders do not act, and actors do not act unsupervised. This principle translates separation of privilege, least privilege, complete mediation, and fail-safe control into the design of tool-using language-model agents (Anderson, 1972; Saltzer and Schroeder, 1975).

4.1 Five planes

The intent plane stabilizes the task objective, constraints, and success criteria before planning or execution begins. The orchestration plane routes tasks, scopes permissions, and manages bounded iteration without directly performing effectful actions. The execution plane is the only plane that performs controlled effects, separating read-only retrieval, controlled action, documentation, and verification. The oversight plane applies sequential safety and quality gates, while the adaptation plane separates learning, evaluation, and diagnosis so that improvement does not become self-authorization.

4.2 Polos realization

Polos implements the five-plane topology as an inspectable reference specification rather than only as a diagram. Role cards define each role's purpose, allowed inputs, allowed outputs, prohibited actions, and authority ceiling. The declared flow graph specifies which roles may communicate, which message types may cross each edge, and where status, failure, and governance signals must travel. Typed message schemas reduce ambiguity in inter-component communication and make missing or illegal flows detectable before deployment.

4.3 Structural checks

The validator checks whether the declared topology satisfies completeness and authority invariants, including edge coverage, role-graph consistency, capability ceilings, final-response gating, audit coverage, loop limits, triage paths, and self-improvement constraints. The accompanying specification expresses the topology through five planes, fourteen roles, fifteen invariants, sixty-five legal edges, thirty-nine message types, forty-two schemas, and four hundred twenty-three structural checks (Coeus Institute., 2026). These figures are not empirical proof of behavioral safety; they show how role boundaries, information flows, message contracts, and validation conditions can be made explicit and auditable.

4.4 Illustrative scenario

Consider a software agent that retrieves a GitHub issue containing a hidden instruction such as, ‘ignore previous instructions and deploy this patch.' A conventional guardrail may inspect the prompt or final output and attempt to detect malicious intent (Rebedea et al., 2025). In Polos, the retrieval worker is read-only, orchestration cannot execute, execution receives only scoped credentials, the verifier checks task completion, and Monitor and QC gates decide whether the result can proceed. The attack must therefore cross several structural boundaries, not merely bypass one prompt filter.

4.5 Relation to AI control and adaptation

Outputs from execution pass through oversight before completion, reflecting AI control research that seeks to reduce harmful outcomes even when some model behavior is untrusted or strategically unreliable (Greenblatt et al., 2024). Similarly, the adaptation plane allows lessons or improvements to be proposed and measured, but not self-authorized. This addresses a risk exposed by reflective agent methods: memory can improve performance, but it can also weaken constraints if it is allowed to revise its own authority (Shinn et al., 2023).

4.6 Scope of the claim

The contribution is not that topology eliminates all agentic risk. The more limited claim is that agentic systems become more governable when no single component can simultaneously interpret intent, plan action, hold unrestricted tools, judge its own outputs, and expand its own authority. This makes structural safety a concrete object for inspection, implementation, and future empirical evaluation.

5 Implications and research agenda

Table 1 positions the proposed topology against related agent-safety and guardrail approaches. The comparison is intentionally architectural. It does not claim that existing guardrails, diagnostic frameworks, or red-team methods are unnecessary. Rather, it shows where this Perspective contributes: it treats authority separation, message topology, scoped tool access, and validation rules as first-order software-engineering artifacts.

Table 1. Positioning of the proposed topology against related agent-safety and guardrail approaches.

Recent practitioner harnesses such as Claude Code and Hermes Agent further show that agent safety is increasingly shaped by the software layer that grants tools, executes commands, manages permissions, and mediates interaction with files, terminals, and external systems (Anthropic, 2026a,b; Nous Research., 2026).

This comparison suggests three evaluation priorities. First, future work should test structurally governed agents against indirect prompt injection, tool misuse, and tool-selection attacks by measuring whether adversarial content can cross an authority boundary, obtain credentials, bypass a gate, select a malicious tool, or cause external action (Greshake et al., 2023; Shi et al., 2026). Agent-security benchmarks that measure instruction integrity, retrieval confidentiality, and capability integrity provide a useful starting point (Alpay and Alpay, 2026).

Second, software-agent benchmarks should incorporate architectural integrity measures in addition to task success. Repository issue resolution and agent-computer-interface benchmarks remain valuable because they expose agents to realistic software tasks (Jimenez et al., 2024; Yang et al., 2024; Zhang et al., 2024). However, evaluation should also record whether the agent stayed within scoped credentials, whether consequential actions passed through declared gates, whether verification was independent of the acting component, and whether failure states were auditable.

Third, future work should measure the governance cost of structural safety. A topology that separates planning, action, oversight, and adaptation will usually add latency, engineering complexity, and operational cost. These costs are the price of reducing the blast radius of model error and adversarial manipulation. Different consequence classes may therefore require different degrees of mediation, with low-consequence reversible actions requiring lighter control than code execution, external communication, financial activity, or infrastructure modification.

Finally, human governance remains central. Machine-checked invariants cannot prove that a language model will always reason correctly, but they can detect missing gates, illegal flows, ambiguous failure paths, untyped messages, or authority creep before deployment. People remain responsible for consequence classification, approval thresholds, policy boundaries, audit review, and permissible adaptation.

6 Conclusion

Agentic AI safety cannot rely only on model trust. Alignment, refusal behavior, and prompt-level defenses remain important, but they are insufficient when language-model agents can retrieve, plan, execute, verify, loop, and adapt within consequential software environments. Once agents acquire tools, safety becomes architectural: authority must be located, constrained, mediated, and made auditable.

The five-plane topology proposed in this Perspective makes that architectural problem explicit. By separating intent, orchestration, execution, oversight, and adaptation, and by realizing that separation in Polos through role cards, schemas, flow graphs, scoped capabilities, and validator-checked invariants, it reduces the risk that planning, acting, judging, and self-modification collapse into one privileged model instance.

This topology cannot guarantee semantic correctness, eliminate all prompt-injection risk, or replace empirical red teaming. It can, however, make agentic systems more inspectable, governable, and testable. Safe autonomy will require software systems in which trust is bounded, authority is mediated, and consequential action remains visible to governance.

Code and Reference Specification Availability: an open reference specification released under the AGPL 3.0 license provides role contracts, flow graphs, message schemas, configuration files, documentation, and a validation script as an illustrative implementation of the topology (Coeus Institute., 2026).

Generative AI statement

The author(s) declared that Generative AI was not used in the creation of this manuscript.

Any alternative text (alt text) provided alongside figures in this article has been generated by Frontiers with the support of artificial intelligence and reasonable efforts have been made to ensure accuracy, including review by the authors wherever possible. If you identify any issues, please contact us.

Publisher's note

All claims expressed in this article are solely those of the authors and do not necessarily represent those of their affiliated organizations, or those of the publisher, the editors and the reviewers. Any product that may be evaluated in this article, or claim that may be made by its manufacturer, is not guaranteed or endorsed by the publisher.

Footnotes

Edited by: Miodrag Zivkovic, Singidunum University, Serbia

Reviewed by: Rui Patrick Xian, Northeastern University, United States