Dev.to Security 🔐 Cybersecurity Mon, 05 Oct 2026 20:12:14 +0000 👁 0 📖 19 min read

SGAEIA: A Reference Architecture for Secure Governed Autonomous Edge Intelligence

SGAEIA Research Series — Article 8 Aridio Silva · Independent Researcher, Brazil · ORCID An AI model becomes an architectural security concern when it can move from generating output to exercising operational power. T

SGAEIA Research Series — Article 8

Aridio Silva · Independent Researcher, Brazil · ORCID

An AI model becomes an architectural security concern when it can move from generating output to exercising operational power. Tool use, credentials, memory, code execution, delegation, network access, and physical actuation make the complete acting system—not the model alone—the relevant object of governance and assurance.

This is a technical edition of the same public research work published on the SGAEIA homepage and Medium and archived on Zenodo. The presentation has been prepared for developers, architects, and security practitioners without changing the work's thesis, evidence, limitations, authorship, license, or public-disclosure boundary.

Cover — SGAEIA: A Reference Architecture for Secure Governed Autonomous Edge Intelligence. A conceptual representation of governed autonomous intelligence operating across distributed edge, cloud, industrial, mobility, and cyber-physical environments. © 2026 Aridio Silva | Project SGAEIA | CC BY 4.0.

Abstract
1. From Model Output to Operational Effect
2. What “Reference Architecture” Means
3. The Twelve Responsibility Planes
- 3.1 Governance and GRC
- 3.2 Identity and Trust
- 3.3 Authority and Delegation
- 3.4 Governed Execution
- 3.5 Agent and Multi-Agent Coordination
- 3.6 Trajectory and Runtime Assurance
- 3.7 Edge and Distributed Autonomy
- 3.8 Cyber-Physical Safety
- 3.9 Observability and Evidence
- 3.10 Lifecycle and Change Governance
- 3.11 Integration and Substitution
- 3.12 Assurance and Verification
4. Cross-Cutting Invariants
5. The Governed Action Boundary
6. Multi-Agent Systems and Collective Authority
7. Edge Autonomy and Degraded Operation
8. Lifecycle Change and Resolved Identity
9. Assurance Without Overclaiming
10. Deployment Profiles
11. Open Research Questions
Conclusion
References
About the Author
Research and project resources
Figures and public-disclosure status
License and status

Abstract

Artificial intelligence becomes an architectural security problem when a model can do more than generate content. Tool use, persistent memory, delegated tasks, code execution, credentials, network access, and physical actuation allow model-generated intentions to cross technical and organizational boundaries. In that environment, model capability alone cannot determine whether an action is legitimate, whether authority remains valid, or whether the resulting effect matches what policy allowed. Governance must therefore become part of the execution architecture rather than remain an external review activity.

This article presents SGAEIA - Secure Governed Autonomous Edge Intelligence Architecture - as a public reference architecture for governing autonomous and distributed AI systems. It organizes the problem through twelve responsibility planes and seven cross-cutting invariants that connect identity, authority, policy, execution, observation, evidence, revocation, recovery, and lifecycle change. The architecture is intended to support different deployment models without prescribing a single product, platform, or implementation topology. Its central proposition is that autonomous capability must remain bounded by independently enforceable authority and by assurance that can be demonstrated with evidence.

The public description deliberately communicates architectural properties rather than sensitive implementation mechanisms. It does not disclose internal enforcement sequences, operational thresholds, repository-specific controls, or reconstruction-enabling schemas. It also does not claim that the architecture eliminates risk or that a reference implementation proves production readiness. The purpose is to provide a rigorous vocabulary for designing, evaluating, and governing systems in which AI can act.

Capability is not authority. Identity is not authority. Evidence is not assertion.

1. From Model Output to Operational Effect

The first generation of AI governance often treated the model as the principal unit of analysis. That perspective remains necessary for evaluating training data, robustness, harmful outputs, refusal behavior, and capability, but it becomes incomplete when the model operates inside an agent runtime. An autonomous system may browse, call tools, create code, delegate work, use credentials, update memory, interact with other agents, and affect external systems over a long trajectory. The relevant object of assurance is therefore the complete acting system, not the model in isolation.

This distinction changes the security question. A model can know how to perform an action without possessing legitimate permission to perform it, and an authenticated agent can still lack authority for a particular purpose, resource, or moment. A tool can be available without being authorized for the proposed use, while a locally permitted step can contribute to a globally prohibited outcome. Secure autonomy requires an architecture capable of maintaining these distinctions while the system is operating.

NIST’s AI Risk Management Framework emphasizes governance across the AI lifecycle and treats risk as contextual rather than reducible to a single technical metric [1]. Zero Trust similarly rejects implicit trust based on network location or ownership and requires access decisions to be continually evaluated [2]. The NIST Generative AI Profile adds considerations specific to generative systems, while OWASP and MITRE provide complementary perspectives on agentic risks and adversarial behavior [3][4][5]. SGAEIA builds on these directions but focuses specifically on the architectural conditions under which autonomous capability may become governed action.

2. What “Reference Architecture” Means

A reference architecture defines responsibilities, trust boundaries, required relationships, and properties that should remain true across implementations. It does not require every deployment to use the same technologies or divide components in the same way. A cloud service, an industrial Edge system, and a disconnected field platform may implement governance differently while still being evaluated against comparable architectural obligations. The value of the reference model lies in making those obligations explicit before implementation choices obscure them.

SGAEIA is not a model, an agent framework, or a certification scheme. It does not assume that every AI system requires the same controls, nor does it promise that risk can be eliminated through architecture alone. Instead, it provides a structured way to ask who is acting, what authority exists, which policy applies, what resource will actually be used, how execution is constrained, what effects occur, and which evidence supports later claims. Those questions remain relevant even as models, tools, deployment environments, and regulations change.

The architecture also separates three kinds of statement. Architectural properties describe what must remain true for governed autonomy; implementation choices describe how a particular system attempts to preserve those properties; and assurance claims describe what evidence supports a conclusion within a declared scope. Confusing these categories creates false confidence because a plausible design is not automatically an effective control, and a passing test is not evidence for conditions that were never tested. This synthesis extends the series’ earlier Security-by-Design foundation and its transition from model capability to governed action [6][7]. SGAEIA therefore treats claim boundaries as part of the architecture itself.

Figure 1 - The twelve SGAEIA responsibility planes. They are analytical boundaries that may be implemented through different component topologies, provided that trust separation and independent control remain credible. © 2026 Aridio Silva | Project SGAEIA | CC BY 4.0.

3. The Twelve Responsibility Planes

SGAEIA organizes governed autonomous intelligence through twelve responsibility planes. A plane is an architectural accountability boundary, not necessarily a standalone service or product. One component may implement several responsibilities, while one responsibility may be distributed across multiple components and locations. The important question is whether the design preserves the required independence, evidence, and control relationships.

3.1 Governance and GRC

The Governance and GRC Plane establishes policy ownership, risk appetite, obligations, exceptions, control objectives, and decision accountability. It connects organizational intent to operational constraints rather than leaving governance in documents that are reviewed only periodically. Continuous GRC uses current system evidence to determine whether assumptions, permissions, and residual-risk decisions remain valid. Human and organizational authority remains distinct from model recommendation.

3.2 Identity and Trust

The Identity and Trust Plane authenticates the humans, agents, services, workloads, devices, tools, and relevant artifacts participating in an action. Identity supports attribution and policy evaluation, but authentication does not by itself grant authority. Trust is contextual, time-bounded, evidence-dependent, and subject to re-evaluation when conditions change. This plane applies Zero Trust reasoning to environments in which software agents may act and delegate at machine speed.

3.3 Authority and Delegation

The Authority and Delegation Plane represents what an actor may do, for which purpose, against which resource, for how long, under what conditions, and with what ability to delegate. A downstream agent must not inherit all of the upstream principal’s trust or privilege merely because it received a task. Delegation should remain attributable, bounded in depth and duration, and revocable through a path independent of the agent being controlled. The effective authority of a group must also be evaluated because several limited grants can combine into excessive collective privilege.

3.4 Governed Execution

The Governed Execution Plane is the independently enforceable boundary between proposed intent and consequential action. It evaluates relevant identity, authority, policy, risk, resource state, trust state, and approval requirements before execution proceeds. The model may propose, explain, or prioritize an action, but it cannot become the final authority for crossing this boundary. Enforcement must remain meaningful even when the model is mistaken, manipulated, or highly confident.

3.5 Agent and Multi-Agent Coordination

The Agent and Multi-Agent Coordination Plane governs orchestration, task decomposition, subagent creation, communication, shared state, and responsibility for combined outcomes. It treats an agent collective as a potential security subject rather than assuming that independently constrained members necessarily produce a constrained whole. Coordination can create new causal paths, new privilege combinations, and ambiguity about who contributed to an effect. Governance must therefore address both individual agents and the collective behavior formed through interaction.

3.6 Trajectory and Runtime Assurance

The Trajectory and Runtime Assurance Plane evaluates behavior over time rather than limiting analysis to isolated tool calls. It correlates actions, state changes, delegation, resource use, observed effects, and deviations from declared purpose. Its role is to identify situations in which individually acceptable steps form an unacceptable trajectory or in which operational behavior diverges from the conditions under which authority was granted. Runtime assurance must remain bounded by what can actually be observed and interpreted.

3.7 Edge and Distributed Autonomy

The Edge and Distributed Autonomy Plane governs local operation under latency, constrained compute, intermittent connectivity, partial observability, and delayed central coordination. It defines how much authority may remain available offline, how long cached decisions remain valid, which evidence must be preserved, and what degraded or safe-state behavior applies. These conditions should be established before disconnection rather than improvised by an autonomous system after central governance becomes unavailable. Reconnection also requires reconciliation of policy, evidence, state, and unresolved actions.

3.8 Cyber-Physical Safety

The Cyber-Physical Safety Plane separates model-generated intent from hazardous or irreversible actuation through independent safeguards. It includes operational envelopes, safe states, local emergency authority, physical interlocks, and recovery paths. A digitally authorized command does not eliminate the need to verify whether physical conditions make the action safe. The final safety boundary must not depend solely on the same reasoning process that proposed the action.

3.9 Observability and Evidence

The Observability and Evidence Plane produces attributable records of relevant inputs, decisions, policy state, identities, execution, observed effects, exceptions, revocations, and recovery. Evidence should be designed as an expected system output rather than reconstructed only after an incident. It must also be sufficiently protected from the ordinary agent and runtime whose behavior it records. Evidence quality determines the strength of the assurance claims that can responsibly be made.

3.10 Lifecycle and Change Governance

The Lifecycle and Change Governance Plane controls changes to models, prompts, policies, tools, adapters, data, infrastructure, and architectural assumptions. It requires version identity, impact analysis, staged admission, rollback capability, and renewed evaluation when a change invalidates earlier evidence. A replacement does not inherit trust simply because it occupies the same logical role. Change governance is especially important when AI-assisted development accelerates the rate at which systems evolve.

3.11 Integration and Substitution

The Integration and Substitution Plane governs interfaces to tools, services, adapters, registries, and external resources. Functional compatibility is not proof that a replacement preserves required security properties. The system must distinguish a requested reference from the concrete artifact or service that is ultimately selected for execution. Authorization must remain connected to verified identity, provenance, and relevant equivalence conditions rather than to an ambiguous name alone.

3.12 Assurance and Verification

The Assurance and Verification Plane defines claims, protocols, testable expectations, adversarial cases, evidence requirements, residual risk, and conclusion boundaries. It distinguishes specification conformance from effectiveness under attack and separates both from production assurance. Independent review becomes more important as consequence, autonomy, and system complexity increase. A credible architecture must be able to state not only what passed, but also what was not evaluated.

4. Cross-Cutting Invariants

Responsibility planes make accountability visible, while invariants preserve security when the planes interact. SGAEIA uses cross-cutting invariants because failures often occur at boundaries: identity is mistaken for permission, delegation amplifies privilege, a replacement changes hidden assumptions, or evidence disappears while authority remains unchanged. The invariants are intended to hold across deployment profiles and technology choices. They express architectural conditions rather than product-specific mechanisms.

Figure 2 - Cross-cutting invariants. The same governance properties constrain identity, authority, execution, evidence, lifecycle change, and distributed operation. © 2026 Aridio Silva | Project SGAEIA | CC BY 4.0.

The first invariant is Authority Non-Amplification: delegation, composition, fallback, retry, or substitution must not increase authority beyond the originating authorization. Model Non-Authority establishes that model output, confidence, self-description, or generated credentials do not constitute permission. Revocability requires authority to remain withdrawable through a control path that does not depend on cooperation from the agent being constrained. Together, these invariants prevent technical capability or workflow complexity from silently becoming legitimate power.

The next group connects evidence and change to authorization. Evidence Before Assurance requires significant claims to map to observable evidence, an explicit protocol, a known environment, and a bounded conclusion. Security-Preserving Substitution requires replacements to preserve relevant security properties or trigger renewed authorization and evaluation. Autonomy Bounded by Assurance ensures that authority does not expand when monitoring, containment, recovery, identity, or revocation assurance degrades.

The final invariant is Action-Effect Reconciliation. A successful request, API response, or tool return does not prove that the external effect matched what policy authorized. The architecture should compare intended action, executed operation, and observed consequence, especially when systems interact with mutable environments or physical processes. Material divergence should create evidence and may require containment, revocation, compensation, recovery, or human investigation.

5. The Governed Action Boundary

A consequential action begins as model-generated intent, but it becomes operational only through an architectural decision boundary. Trusted system context identifies the acting subject, task, owner, runtime, and relevant state; authority and policy are then evaluated against the proposed purpose and resource. The concrete tool, service, model, adapter, or artifact must be resolved and checked before execution. The resulting decision may permit, deny, constrain, defer, or escalate the action.

Figure 3 - The governed action boundary. Model-generated intent is evaluated through trusted context, authority, policy, execution controls, runtime observation, and evidence before an assurance claim is made. © 2026 Aridio Silva | Project SGAEIA | CC BY 4.0.

Execution is not the end of the governance process. Independent observation must determine what happened, whether the action remains consistent with the authorized trajectory, and whether the resulting effect matches policy expectations. Evidence records the decision context and material outcome, while post-effect reconciliation identifies divergence and informs revocation, recovery, or further review. This creates a closed governance loop rather than a one-time permission check.

The boundary also preserves separation of duties. A single component should not be able to select a resource, authorize its use, execute the action, observe the outcome, and declare the result compliant without independent checks. The exact implementation will vary by deployment, but the architectural principle remains stable: reasoning proposes action, while trusted controls decide whether and how action may occur. That separation is fundamental to secure agentic AI.

6. Multi-Agent Systems and Collective Authority

Multi-agent systems create risks that are difficult to see when each agent is evaluated independently. Authority can propagate through delegation, shared memory, service identities, messaging, common tools, and task graphs. Several individually permitted actions may reconstruct sensitive information, consume excessive resources, or produce an external effect that no local decision anticipated. The collective can therefore possess effective power that is not visible in any single member’s permission set.

SGAEIA addresses this problem by evaluating delegation and behavior as graphs and trajectories rather than as isolated requests. Relevant evidence includes identity transitions, delegation edges, changes in plan, shared-state mutation, resource use, tool invocation, and external effects. The goal is not to centralize every decision, but to retain enough governance continuity to detect amplification, attribution gaps, and policy-relevant divergence. Collective behavior must remain explainable in terms of bounded authority and attributable contribution.

This approach also changes incident response. Revoking one agent may be insufficient if delegated authority, cached state, derived credentials, or unfinished tasks remain active elsewhere in the collective. Containment must consider the reachable authority graph and the evidence required to reconstruct how the group produced an outcome. Secure multi-agent design therefore depends on both local enforcement and system-level coordination controls.

7. Edge Autonomy and Degraded Operation

Edge environments expose a tension between local usefulness and centralized governance. A system may need to continue operating when connectivity is slow, intermittent, or unavailable, yet the absence of a central service must not create unlimited local authority. SGAEIA treats offline operation as a pre-governed mode with explicit limits on duration, consequence, resource access, delegation, and evidence obligations. The more difficult revocation and observation become, the narrower residual authority should generally be.

Degraded operation also requires a defined safety posture. Some actions may continue under cached policy, some may require local human authority, and others may need to stop or transition to a safe state. Evidence should be buffered with integrity protection and reconciled after connectivity returns. The architecture must also address conflicting state, expired policy, revoked authority, and effects that occurred while central governance was unavailable.

Cyber-physical deployments add another constraint because digital recovery may not reverse a physical consequence. Independent safety barriers, operational envelopes, and emergency controls should remain effective even when the AI runtime is degraded or compromised. The architecture should therefore connect cyber authorization to physical permissibility without assuming that one can substitute for the other. Governed Edge autonomy is useful precisely because it defines what the system may still do when ideal conditions do not exist.

8. Lifecycle Change and Resolved Identity

Autonomous systems change continuously. Models are replaced, tools are updated, prompts evolve, dependencies resolve to new versions, adapters select different endpoints, and policies respond to new evidence. A logical name may remain unchanged while the concrete executable resource behind it changes materially. Treating those substitutions as automatically trusted allows implementation drift to bypass prior governance decisions.

SGAEIA therefore distinguishes declared, authorized, resolved, executed, and observed identity at the architectural level. The public principle is straightforward: authorization of a reference is not authorization of an unverified resolved artifact. A system should either establish that the selected resource matches what was authorized, establish an explicitly governed equivalence, or refuse and escalate the action. The detailed mechanisms remain implementation-specific and are outside this public disclosure.

This property connects supply-chain security, lifecycle governance, Zero Trust, and Evidence-as-Code. Verification should generate evidence showing which identity was requested, which identity was selected, which policy decision applied, and what actually executed. When assumptions change, previous assurance must be re-evaluated rather than inherited by naming convention. The result is a stronger connection between change control and runtime authority.

9. Assurance Without Overclaiming

Architecture can improve assurance, but it cannot eliminate uncertainty. A reference implementation can demonstrate that a mechanism behaves as expected under declared tests, while a production system introduces additional dependencies, scale, operators, adversaries, and environmental conditions. Conformance to a specification is not identical to security effectiveness, and neither establishes universal protection. SGAEIA makes these distinctions explicit so that evidence does not become a rhetorical substitute for assurance.

Evaluation should therefore identify the system boundary, threat assumptions, protocol, environment, available tools, success criteria, denominator, attempts, errors, and retained utility. A low attack-success rate can be misleading if legitimate work has become impossible, while a textual refusal is insufficient if a connected tool still performs the prohibited action. Measurements should connect behavior to effects and explain which conclusions the evidence supports. Unknown or degraded evidence should not silently justify greater autonomy.

The architecture is similarly careful about standards and certification. Alignment with NIST, OWASP, MITRE, ISO/IEC, or other frameworks can improve coverage and shared language, but mapping does not itself prove conformance or operational effectiveness. SGAEIA remains an independent research architecture rather than an accredited certification program. Any deployment claim must be supported by evidence specific to that deployment and its declared context.

10. Deployment Profiles

The same architectural responsibilities can be expressed through different deployment profiles. A cloud-managed enterprise agent may emphasize centralized policy, short-lived credentials, rapid revocation, tool mediation, and high-volume trajectory monitoring. A disconnected Edge platform may emphasize bounded offline authority, local safety controls, evidence buffering, trust freshness, and later reconciliation. A multi-agent operational system may emphasize delegation graphs, shared-state integrity, collective authority, and causal attribution.

Figure 4 - Example SGAEIA deployment profiles. Cloud-managed agents, disconnected Edge systems, multi-agent operations, and cyber-physical autonomy share architectural properties while implementing controls according to context. © 2026 Aridio Silva | Project SGAEIA | CC BY 4.0.

A cyber-physical profile must also preserve independent actuation safety and recovery from effects that persist after digital execution stops. These profiles do not represent maturity levels, and one is not inherently more secure than another. Each profile shifts the balance among latency, autonomy, observability, revocation, local authority, and recovery. The reference architecture enables those tradeoffs to be stated and evaluated rather than hidden inside implementation detail.

11. Open Research Questions

SGAEIA defines a disciplined architecture, but several questions remain open. Effective authority must be computed across identities, delegation, tools, services, and multi-agent graphs without creating unacceptable overhead. Runtime systems need observables that detect impermissible trajectories while preserving legitimate autonomy and operational privacy. Oversight capacity must also scale with concurrency, trajectory length, consequence, and uncertainty.

Edge environments raise questions about revocation guarantees, policy freshness, and evidence continuity during disconnection. Evidence systems must balance independence, confidentiality, integrity, cost, and reconstructability. Substitution requires defensible criteria for security equivalence across models, tools, adapters, and services. Finally, action-effect reconciliation remains difficult when external environments are only partially observable or when consequences emerge after a delay.

These are research questions rather than claims that the current architecture has solved every aspect of governed autonomy. Their inclusion is important because a reference architecture should expose the boundaries of current knowledge, not hide them. Future SGAEIA work will continue to evaluate these questions through Research-to-Architecture analysis, specification, testing, and evidence. Architectural evolution should remain deliberate even when capability changes quickly.

Conclusion

Secure autonomous intelligence requires more than a capable model and more than a collection of controls. It requires an architecture in which identity, authority, delegation, execution, observation, revocation, evidence, recovery, and change remain connected throughout the system lifecycle. Those responsibilities must survive model error, manipulation, substitution, disconnection, multi-agent composition, and machine-speed operation. They must also produce evidence strong enough to support bounded and honest claims.

SGAEIA provides a reference architecture for that purpose. Its twelve responsibility planes make accountability visible, while its cross-cutting invariants prevent authority and assurance from being weakened at component boundaries. The governed action boundary separates reasoning from permission and connects execution to observation and effect. Different deployment profiles can implement these properties differently without abandoning the core principle that autonomy must remain governable.

The result is not a promise of perfect control. It is a disciplined basis for useful autonomy whose operational power remains explicit, bounded, attributable, revocable, and subject to evidence. As AI systems acquire greater capacity to act, governance becomes part of the technical frontier rather than an administrative layer around it. That is the architectural direction SGAEIA is intended to advance.

Autonomous AI. Governed by Design. Trusted by Evidence.

References

[1] Tabassi, E. (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1. National Institute of Standards and Technology. https://doi.org/10.6028/NIST.AI.100-1

[2] Rose, S., Borchert, O., Mitchell, S., & Connelly, S. (2020). Zero Trust Architecture. NIST Special Publication 800-207. National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-207

[3] National Institute of Standards and Technology. (2024). Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. NIST AI 600-1. https://doi.org/10.6028/NIST.AI.600-1

[4] OWASP GenAI Security Project. (2025). OWASP Top 10 for Agentic Applications for 2026. https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/

[5] MITRE. Adversarial Threat Landscape for Artificial-Intelligence Systems (ATLAS). https://atlas.mitre.org/

[6] Silva, A. (2026). Security-by-Design for Distributed Agentic AI. SGAEIA Research Series - Article 7. https://doi.org/10.5281/zenodo.22816239

[7] Silva, A. (2026). From Model Capability to Governed Action: An Architecture for Secure Agentic AI. SGAEIA Research Series - Article 11. https://doi.org/10.5281/zenodo.22837908

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 and project resources

Figures and public-disclosure status

The cover is unnumbered, and Figures 1–4 are numbered sequentially and referenced consistently. All five images are the public homepage assets and carry the SGAEIA attribution and CC BY 4.0 license information.

The images communicate architectural properties and high-level governance relationships without disclosing private protocols, operational thresholds, enforcement state machines, repository-specific identifiers, or reconstruction-enabling implementation detail. No C2PA Content Credentials claim is made.

License and status

Except where otherwise noted, the text and original conceptual illustrations are licensed under the Creative Commons Attribution 4.0 International License (CC BY 4.0). The SGAEIA software research artifact remains subject to its separately stated Apache License 2.0.

This DEV Community draft is a technical edition of the same public research work. It is not a new study, implementation certification, legal-compliance determination, accredited standard, or production guarantee.