A Deterministic Control Plane for LLM Coding Agents

Source

• Source name: arXiv
• Source kind: paper
• Authors / organization: Padmaraj Madatha
• Venue: arXiv: cs.SE
• Published: 2026-06-25
• Collected: 2026-06-26
• URL: http://arxiv.org/abs/2606.26924v1
• PDF: https://arxiv.org/pdf/2606.26924v1
• DOI: UNKNOWN

Plain-Language Brief

The author proposes a new control plane for coding agents, which are tools that have broad access to files and shell commands. The current configuration layer of these agents is poorly managed, with configurations often being undeclared shared components across different repositories. The proposed control plane aims to address this issue by implementing a deterministic system that ensures one-to-one mapping, enforces tiered permissions, and prevents attacks. It also compiles a single canonical definition for seven IDE targets and detects prompt drift.

What the Document Says

• The author discusses an issue with LLM coding agents' configuration layer being poorly managed.
• A study of 10,008 public GitHub repositories found that agent configurations propagate as undeclared shared components.
• The proposed solution is a deterministic control plane called Rel(AI)Build.
• Rel(AI)Build treats agent definitions as a managed supply chain.
• It enforces tiered permissions and attack-derived blocklists before LLM invocation.
• It gates feature work through a phase state machine with requirement-to-file-to-test traceability.
• It compiles a single canonical definition to seven IDE targets.
• It detects prompt drift via Jaccard similarity.
• Conformance tests on injected violations confirm each mechanism enforces its stated invariant.

Key Concepts Mentioned

• LLM coding agents
• configuration layer
• control plane
• Rel(AI)Build
• tiered permissions
• attack-derived blocklists
• phase state machine
• Jaccard similarity

Claims Made by the Document

• Agent configurations propagate as undeclared shared components across independent repositories.
• Configurations are rarely revised and rarely declare permission boundaries.

Evidence Used

• 10.1% of tracked paths are SHA-256 exact duplicates across independent repositories
• 75.5% of clone pairs crossing organisational boundaries
• 58% single-commit; 0.4 vs 0.6 commits/month age-normalised against CI/CD workflows
• <1% of agent configs vs 33% of Actions workflows, n=31 true positives

Methods / Approach

UNKNOWN

Limitations Stated by the Authors

UNKNOWN

Limitations Noted by the Agent

Agent interpretation — not from the source.

UNKNOWN

Open Questions

UNKNOWN

Notes for Future Q&A

May include interpretation. Labeled where it does.

UNKNOWN

Raw Abstract / Excerpt

LLM coding harnesses grant agents broad file and shell access, yet the configuration layer that steers them -- rules files, agent definitions, IDE-specific markdown -- is largely unmanaged. A prevalence study of 10,008 public GitHub repositories (n=6,145 agent config files) finds that agent configurations propagate as undeclared shared components: 10.1% of tracked paths are SHA-256 exact duplicates across independent repositories (fork-adjusted, threshold-independent), with 75.5% of clone pairs crossing organisational boundaries. Two further patterns are indicative: configurations are rarely revised (58% single-commit; 0.4 vs 0.6 commits/month age-normalised against CI/CD workflows), and rarely declare permission boundaries (<1% of agent configs vs 33% of Actions workflows, n=31 true positives). We propose a deterministic control plane above the harness that maps one-to-one to these gaps. Rel(AI)Build treats agent definitions as a managed supply chain (SHA-256 content addressing, HMAC-stamped lockfiles, hash-chained audit logs); enforces tiered permissions and attack-derived blocklists before LLM invocation; gates feature work through a phase state machine with requirement-to-file-to-test traceability; compiles a single canonical definition to seven IDE targets; and detects prompt drift via Jaccard similarity. Conformance tests on injected violations confirm each mechanism enforces its stated invariant; developer outcomes remain future work. Governance of this layer must be deterministic and tool-agnostic -- not delegated to further LLM orchestration.