Security-by-Design for Distributed Agentic AI

SGAEIA Research Series — Article 7

Aridio Silva · Independent Researcher, Brazil · ORCID

Security for autonomous AI cannot be a filter placed around an otherwise uncontrolled system.

When an agent can select tools, hold credentials, delegate tasks, coordinate with other agents, and affect external resources, security must shape the conditions under which autonomy is allowed to exist.

This is a technical edition of the same public research work published on the SGAEIA homepage and Medium and archived on Zenodo. It reorganizes the presentation for developers and architects without changing the article's thesis, evidence, limitations, or public-disclosure boundary.

Contents

• The security boundary has moved
• Why conventional guardrails are not enough
• Security-by-Design begins with authority
• Identity must precede authority
• Delegation must not create authority
• Policy must exist before action
• Revocation is part of safety
• Zero Trust must extend to autonomous actors
• Continuous governance and evidence
• Shift Left is necessary, but not sufficient
• Distribution makes governance harder
• Security properties should be testable
• Security should survive component substitution
• The SGAEIA perspective
• What this article does not publish
• Conclusion
• References
• Research and project resources
• License and status

The security boundary has moved

Traditional software often separates a model or decision-support component from the system that performs the final action. Agentic AI can collapse that separation. An agent may interpret a goal, select a tool, call an external service, delegate work, update state, or trigger a physical effect.

The security question is therefore no longer only whether a model output is safe. It is also whether the system is authorized to perform the requested action in the current context.

Edge and distributed deployment make the problem broader. Computation may be spread across devices, gateways, local servers, cloud services, and multiple organizations. The system may distribute not only intelligence, but also operational authority.

Cover — Security-by-Design for Distributed Agentic AI. Governed distributed autonomy across edge–cloud environments, with security and governance treated as architectural properties rather than after-the-fact controls. © 2026 Aridio Silva | Project SGAEIA | CC BY 4.0.

Why conventional guardrails are not enough

Output filters, prompt constraints, network boundaries, and post-hoc logs remain useful. They are not sufficient when the system can produce a chain of actions across agents and tools.

A model may be instructed not to access a resource, while a tool gateway still exposes it. A request may be authenticated, while its delegated authority is expired or broader than the originating grant. A log may show an action, while omitting the policy, context, or evidence that made the action legitimate.

Security-by-Design therefore asks teams to establish security properties before implementation: who may act, which authority exists, how delegation narrows, where enforcement occurs, how authority is revoked, and what evidence supports later review.

Figure 1 — The New Risk Landscape for Distributed Agentic AI. Autonomous planning, tool use, delegation, and distributed execution create security boundaries that cannot be reduced to model-output filtering. © 2026 Aridio Silva | Project SGAEIA | CC BY 4.0.

Security-by-Design begins with authority

Capability is not authority. A component may technically call an API, access a database, or invoke a tool without being legitimately authorized to perform that operation now.

For a consequential action, an architectural review should ask:

• Which actor or workload is requesting it?
• Who granted the relevant authority?
• What purpose, resource, action, scope, and time limit apply?
• Which context and risk conditions must hold?
• May the authority be delegated, and how far?
• Which component independently enforces the decision?

This is not a required schema. It is a way to ensure that authority is explicit, bounded, attributable, and revocable rather than inferred from capability or proximity.

Figure 2 — Security-by-Design as an Architectural Foundation. Identity, authority, policy, evidence, revocation, and governance must be considered together before autonomous action is released. © 2026 Aridio Silva | Project SGAEIA | CC BY 4.0.

Identity must precede authority

Identity establishes which agent, workload, user, or service is participating. It does not by itself establish permission.

AuthenticatedIdentity ≠ OperationalPrivilege

Runtime authorization must evaluate the requested action against identity, resource, purpose, policy, context, delegation state, and relevant evidence. This remains true when the actor operates on the edge, inside a cluster, across a cloud boundary, or through another agent.

An identity system is therefore a prerequisite for accountable authority, not a substitute for authorization.

Delegation must not create authority

A multi-agent workflow can pass work from a person to Agent A, from Agent A to Agent B, and from Agent B to a tool or external system. The chain must not silently broaden permission.

Delegated authority should remain equal to or narrower than the authority from which it came:

A_delegate ⊆ A_delegator

This notation is an architectural invariant, not a universal authorization calculus. It means that delegation must preserve attribution, purpose, scope, constraints, and revocation rather than create a new source of power.

Policy must exist before action

Governance statements written only in documents cannot directly stop a machine-speed action. Policies need a controlled operational expression that can be evaluated at the relevant boundary while remaining traceable to the approved normative source.

The translation must not silently redefine the requirement. A valid policy rule can still encode the wrong interpretation. Review, separation of duties, version control, testing, and evidence are therefore part of the security boundary.

An agent may propose a policy change; it must not become the unreviewed authority that approves the change constraining its own behavior.

Revocation is part of safety

Authority may need to end when a task finishes, risk changes, a credential is compromised, policy changes, or context no longer matches the grant.

Stopping a model process is not necessarily revocation. Other components may still accept its requests, reuse its credentials, or honor derived authority. Enforcement infrastructure must be able to narrow, suspend, or reject future actions.

GrantingAuthority ⇒ AbilityToWithdrawAuthority

Revocation should remain attributable and effective across dependent delegation paths. Its exact propagation and consistency mechanisms are implementation-specific and outside this public article.

Zero Trust must extend to autonomous actors

Zero Trust is not a claim that every component is permanently malicious. It is a refusal to convert network location, ownership, familiarity, or previous approval into indefinite trust.

For agentic systems, consequential actions should be evaluated at the point where authority is exercised. The decision should consider the actor, requested effect, resource sensitivity, policy, current context, delegation conditions, and relevant evidence.

TrustedLocation ≠ TrustedAction

The system must also define what happens when verification is unavailable. Reduced governance freshness should narrow autonomous action rather than expand privilege.

Continuous governance and evidence

Security-by-Design includes the governance processes that keep authority valid during operation. Continuous GRC and Evidence-as-Code connect policy intent, runtime decisions, control assessment, drift detection, and reviewable evidence.

Evidence should help a reviewer determine who acted, under whose authority, which policy and context applied, what controls were evaluated, and what effect occurred. More telemetry is not automatically better assurance. Evidence can be incomplete, misleading, stale, or collected in ways that create privacy risk.

Governance must remain open to contrary evidence and revision. A passing test or green dashboard does not establish security if the producer is compromised, the test is obsolete, or the mapping from policy to control is wrong.

Shift Left is necessary, but not sufficient

Threat modeling, Security-First, Secure-by-Design, and Shift-Left practices bring security assumptions, requirements, invariants, and tests into early engineering work. That is essential, but it does not end the security lifecycle.

Agentic systems change at runtime. Models, tools, data, policies, dependencies, and context may drift after deployment. Shift-Right verification, runtime monitoring, revocation, incident response, and continuous assurance are required to detect when an earlier assumption no longer holds.

Naming STRIDE, OWASP, NIST, or another framework is not evidence that a system is secure. The relevant claims still require system-specific verification.

Distribution makes governance harder

Distributed agents operate across edge devices, cloud services, private infrastructure, administrative domains, and intermittently connected environments. The architecture must preserve authority boundaries and accountability across those boundaries.

Offline operation must not become an authorization bypass. During degraded connectivity, previously approved authority should remain identifiable and bounded, high-impact actions should face stronger constraints, and evidence should remain attributable and reviewable. Reconnection should restore authoritative context and permit reassessment.

Security properties should be testable

Security-by-Design is stronger when its claims can be examined. A team should be able to derive tests and evidence for properties such as:

• identity is authenticated and bound to the relevant workload;
• authority is scoped, time-bounded, purpose-bound, and revocable;
• delegation never amplifies authority;
• policy is evaluated before consequential execution;
• enforcement is outside the discretion of the component being constrained;
• security decisions produce attributable evidence;
• drift triggers impact analysis and reassessment;
• degraded operation does not expand authority;
• substitutions preserve the required security properties.

These are candidate architectural properties, not a certification checklist. Test design must account for threat model, consequence, uncertainty, independence, and evidence quality.

Security should survive component substitution

Models, runtimes, communication protocols, identity systems, policy engines, and infrastructure components change quickly. A security architecture tied too closely to one implementation may become difficult to evolve.

Security-preserving substitution means that a component can be replaced only after evaluating whether the relevant identity, authority, delegation, policy, evidence, revocation, and assurance properties remain intact.

Technology neutrality is therefore an objective, not an automatic outcome. Every replacement requires an impact analysis and evidence appropriate to the changed assumptions.

Figure 3 — Security-Preserving Substitution. Components may evolve when the governing security properties and evidence remain coherent; replacement is not a free pass around assurance. © 2026 Aridio Silva | Project SGAEIA | CC BY 4.0.

The SGAEIA perspective

SGAEIA treats Security-by-Design for distributed agentic AI as a cross-cutting architectural responsibility. Its public model connects:

• intelligence and planning;
• explicit, bounded, delegated, enforceable authority;
• identity, authentication, Zero Trust, and runtime protection;
• governance, risk, accountability, compliance, and Continuous GRC;
• observability, Evidence-as-Code, and continuous assurance.

The objective is not merely autonomous operation. It is governed autonomous operation in which the authority to act remains explicit, constrained, traceable, reviewable, and withdrawable across edge–cloud environments.

Figure 4 — Toward a Trusted Ecosystem of Autonomous Agents. Bounded authority, human control, Continuous GRC, trusted collaboration, and Evidence-as-Code provide a governance foundation for distributed autonomy. © 2026 Aridio Silva | Project SGAEIA | CC BY 4.0.

What this article does not publish

This public edition intentionally does not define private implementation details, including:

• schemas;
• protocols;
• internal state machines;
• enforcement algorithms;
• operational pipelines;
• private interface contracts.

It presents public research principles and high-level architectural properties for technical and academic discussion. It does not establish production certification, legal compliance, empirical proof of effectiveness, or endorsement by any referenced standards body.

Conclusion

Agentic AI requires a different security posture because autonomous software can become an operational actor.

Once a system can select tools, hold credentials, delegate tasks, coordinate with other agents, and affect external resources, security can no longer depend mainly on filtering model outputs or auditing actions afterward.

Security must shape the authority of the system before execution. That means designing for identity before authority, bounded permission, constrained delegation, policy before action, Zero Trust, revocation, continuous governance, and verifiable evidence.

Security for autonomous AI should not be added around autonomy. It should define the conditions under which autonomy is allowed to exist.

References

1. Rose, S. et al. Zero Trust Architecture, NIST SP 800-207.
2. Tabassi, E. Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1.
3. ISO/IEC. ISO/IEC 42001:2023 — Artificial intelligence management system.
4. OWASP GenAI Security Project. Agentic AI — Threats and Mitigations.

Research and project resources

• Canonical homepage reading edition
• Article 7 Zenodo DOI
• Original Medium publication
• Academia.edu publication
• SGAEIA homepage
• SGAEIA research artifact
• ORCID — Aridio Silva
• Google Scholar — Aridio Silva

License and status

The text and original conceptual illustrations are licensed under CC BY 4.0, except where otherwise noted. 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, or production guarantee. The figures communicate public concepts without exposing private mechanisms.

© 2026 Aridio Silva | Project SGAEIA | CC BY 4.0

Autonomous AI. Governed by Design. Trusted by Evidence.