CoDeS LLCGoverned Autonomy at the Edge: Security and Separation of Powers in Distributed AI Estates
Author: Eric A. Doan, Founder, CoDeS LLC (Dry Ridge, Kentucky)
Company identifiers: UEI W51HJZQZTCJ4 · CAGE 233M7 · NAICS 541511, 541512, 541519, 541715
Related public record: comment on NIST docket NIST-2025-0035
Abstract
As organizations deploy AI agents that can take actions across devices and clouds, many architectures collapse reasoning, authorization, execution and verification into a single model loop. This paper describes a research architecture, CoDeS, that separates these powers. AI models propose. Local controls decide, execute and verify. We describe the roles, three governance principles and the internal R&D evidence gathered so far, and we state what has not been shown.
1. The agentic security gap
Many current deployments rely largely on prompt-level guardrails, a second model acting as a judge, and after-the-fact logs. When an agent is given tool-calling privileges, a conventional orchestrator can treat the model’s text plan as both the authorization to act and the proof that it succeeded. This creates four failure modes:
- Unbounded authority. The presence of a capability on a device is mistaken for permission to use it.
- Transitive privilege escalation. Showing that tool A and tool B are each safe leads a system to assume that chaining them is safe.
- Self-certifying prose. A return code or a model-written summary such as “Task complete” is accepted without independent readback.
- Silent failures that look like zero. An unreachable node or database returns an empty result instead of a truthful “unavailable.”
2. Architecture: separation of powers
CoDeS is designed as a local control layer above the host operating system (Windows, Linux or Android). In the prototype it separates the following roles so that no single component accumulates several kinds of authority.
| Role | Component | Designed boundary |
|---|---|---|
| Planning | GAIA | Reasons, queries and proposes candidate plans. Holds no authority and cannot approve itself. |
| Human authority | Guardian / operator | Where the governing rules require it, a person must approve. Some bounded actions can be authorized by written policy alone; the October 17 test below was approved by policy, not by a person. |
| Pre-action admissibility | ACP (Action Control Protocol) | Binds a proposed action to exact scope, identity, capability and a single-use token before it runs. |
| Boundary enforcement | Aegis | Evaluates risk, policy and integrity where things cross a boundary, and can deny, hold or quarantine. |
| Staged execution | FES | Runs only admitted, hash-guarded work units through qualified runners. |
| Independent evidence | Observation and Proof | Observation re-reads the actual result after execution. Proof keeps a receipt of that result in a hash-chained ledger. Both are separate from the component that ran the work. |
| Reconciliation | UNIFY | Compares declared intent with the observed result after the fact. It is designed not to invent success from missing evidence. Being stored for later reuse is not proof that a later job reused it. |
| Scoped memory | Three memory realms | Keeps system, operator and user records separate. |
Three governance principles
- Capability is not permission, and permission is not authority. Discovering or installing a tool grants no right to use it.
- Safe parts do not make a safe chain. Even if A is approved and B is approved, A followed by B is not approved until the combination is qualified.
- Truthful completeness. Reads report complete, partial or unavailable. An unreachable source is never shown as zero.
3. Evidence and scope
The results below come from internal R&D on a two-device prototype: an Android phone and a Windows computer. They are our own observations and have not been independently validated. See the technical evidence summary for scope and limits.
- A bounded October 17, 2026 governed-job graph test returned 13 nodes and 18 typed relationships: 7 hash-matched, 11 owner-recorded, 0 mismatches in that sample.
- An October 19, 2026 code-location benchmark found 60 of 60 correct files and lines, and reported 27 of 27 invented or out-of-scope symbols as not found, without using a model.
Relationship to standards
This work is informed by the concepts in the NIST AI Risk Management Framework (govern, map, measure, manage). Its concerns overlap with per-action mediation in zero-trust architecture (NIST SP 800-207), audit integrity controls (NIST SP 800-53) and the “excessive agency” risk in the OWASP Top 10 for LLM Applications. This is a conceptual mapping. It is not a compliance claim, and NIST has not endorsed or certified CoDeS.
4. Potential value and open questions
- Accountability. Reviewers can examine recorded decisions and observed results instead of relying on an AI-written “done.”
- Disconnected operation. The design keeps authority local so that governed work can continue without a cloud connection. We have demonstrated this only on our own prototype.
- Cost. Answering some questions deterministically, with no model, may reduce inference use. We have measured this only on narrow tasks and have not measured enterprise savings.
5. Limits and next steps
CoDeS is an internally tested research prototype. It has not been independently validated, certified or qualified for production, and it has no federal contract past performance. Next steps are independent test design, scoped technical demonstrations and controlled pilot design with interested public-sector and research partners.