A Deterministic Control Plane for LLM Coding Agents

Abstract: 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.

• The paper introduces a deterministic control plane that enforces supply-chain principles to manage configurations and permissions for LLM coding agents.
• It employs content addressing, tamper detection, and phase-gated lifecycle enforcement to secure agent definitions against prevalent security threats.
• Empirical analysis of over 10,000 GitHub repositories highlights critical deficiencies in current agent configurations, motivating the proposed approach.

Deterministic Control Planes for LLM Coding Agents: An Expert Commentary

Motivation and Empirical Evidence

The paper "A Deterministic Control Plane for LLM Coding Agents" (2606.26924) addresses the absence of structured governance in the configuration and process layers that steer LLM-driven coding agents. The research is framed around empirical evidence from a large-scale prevalence study (N=10,008 public GitHub repositories) that establishes three principal deficiencies:

• Configuration propagation as unmanaged, shared software: 10.1% of tracked configuration files (adjusted for forks) are present as exact duplicates across independent repositories, with 75.5% of clone pairs distributed across organizational boundaries. These files—often encoding project-specific permissions or constraints—currently lack any formal supply chain or provenance guarantees.
• Stagnant and weakly governed agent definitions: 58% of agent configuration files are never revised after initial commit, with a median of just one commit. This is considerably less than the revision depth observed in CI/CD pipelines in the same repositories, even after accounting for artifact-age confounds (median: 0.4 vs 0.6 commits/month).
• Absence of explicit permission boundaries: Fewer than 1% of agent configuration files declare tool permissions, in stark contrast to 33% among CI/CD workflows, as ascertained by regex-based parsing.

These findings collectively imply that agent control files circulate as de facto shared components absent of supply-chain rigor, are rarely reviewed or maintained, and lack enforceable execution boundaries. The architecture and experimental corpus robustly support these conclusions.

Proposed Architecture and Reference Implementation

The deterministic control plane introduced in this work, as instantiated in Rel(AI)Build, is fundamentally orthogonal to the LLM harness/runtime. Rather than replacing the execution substrate, it overlays deterministic governance as a managed software supply chain. Key architectural pillars include:

• Content Addressing and Tamper Detection: Every agent definition is content-addressed (SHA-256) upon registration and installation, with lockfiles HMAC-stamped to detect accidental edits or automated corruption. Append-only, hash-chained audit logs provide tamper-evident provenance with each governance mutation.
• Deterministic Permission Enforcement: Pre-execution gates statically enforce per-tier tool allowlists (fail-closed) and scoped write permissions with normalized path checks, precluding directory traversal regardless of agent or harness dialect.
• Attack-Informed Blocklists: Static blocklists (regex-derived) covering command and path patterns are injected as runtime hooks in target IDEs (e.g., PreToolUse for Claude Code, beforeShellExecution for Cursor), addressing known attack classes such as privileged escalation and workspace trust violations.
• Phase-Gated Lifecycle Enforcement: Execution is strictly bounded by a deterministic state machine, encoding phase invariants (ordering, delegation receipts, security scans, and human-in-the-loop gates)—with all transitions auditable and rollback paths deterministic.
• Tokenization-Normalization and Prompt Drift Measurement: Prior to compilation, body normalization and Jaccard-based drift detection quantify lexical changes, providing operational visibility into prompt mutation risk. Thresholds for LOW/MED/HIGH drift are calibrated for triage, not yet for behavioral prediction.
• Define-Once, Compile-to-Many: Canonical agent definitions are compiled into native configuration formats for multiple IDE harnesses, with governance properties enforced pre-compile and the output mapped bijectively (where possible) to original constraints.

The implementation explicitly separates authoring/distribution, compilation, and runtime-governance planes. All governance logic is pure, auditable code—never delegated to further LLMs or inference-time heuristics.

Threat Model and Security Posture

The architecture is aligned with current industry standards (NIST AI RMF, SLSA, NTIA SBOM) and explicitly scopes its mitigations to pre-execution controls. Deterministic blocklists, permission enforcement, and phase transitions are designed to defend against the majority of agent/dialect-agnostic threats highlighted in the OWASP Top Ten for LLM applications, including context poisoning, privilege escalation, uncontrolled recursion, and workspace trust abuse.

A key claim—well supported by the design and corpus study—is that configuration-layer supply chain risks in LLM coding harnesses now strongly resemble those already recognized and regulated in traditional software: configurations are widely-shared, prone to copy-paste propagation, and can encode privileges with little to no lifecycle management. The proposed deterministic overlay aligns agent definitions with practices already standard for source and build artifacts.

Residual risks remain, particularly for prompt injection (where only HITL gates and AC-scope checks provide final defense), for adversaries with local key access (HMAC default is machine-local), and for runtime enforcement disparities (where the harness itself is not under direct governance-plane control).

Experimental Conformance and Limitations

Conformance testing covers enforcement and regression properties (N=237 agent definitions, 7 harness formats) and demonstrates that injected violations trigger expected aborts or failures at pre-execution gates (integrity, permissions, blocklists, phase-guard invariants). These are robust as invariant checks but cannot be extrapolated to developer productivity, defect rates, or outcome effectiveness.

A single-case drift-detection vignette illustrates detectable scope creep (e.g., implementation without test trace), demonstrating the mechanism without claims of real-world effect size.

Key limitations:

• No runtime behavioral validation of the drift metrics; e.g., Jaccard thresholds are operational defaults, not yet shown to correlate with actual agent degradation or leakage.
• Cooperative trace linkage; agents must opt-in to trace-update calls, and non-compliance is detectable but not preventable ex ante.
• Local HMAC signing, not global attestation; organizational pipeline-grade signatures and SBOM integration are deferred.
• Heterogeneous runtime enforcement across harnesses remains an open problem, as does the full empirical calibration of process overhead vs. security outcomes.
• Prompt injection, in fully adversarial settings, is mitigated but not eliminated.

Implications and Future Directions

By porting software supply-chain principles to the agent-definition layer and treating these files as first-class, governed artifacts, this work closes a substantial governance gap that is increasingly relevant as LLM coding agents are granted project-wide write and execute capabilities. The architecture generalizes to any content-injection harness as a deterministic, tool-agnostic overlay, positioning it as a reference design for regulated and multi-team LLM agent deployments.

Future research avenues include empirical validation of drift metrics' predictive value, controlled cohort studies measuring developer outcomes, and broad adoption of per-agent SBOM integration. The architecture encourages convergence on governance by construction, rather than by runtime inspection or heuristic anomaly detection.

Conclusion

This paper rigorously documents that the configuration and process layers underlying LLM-driven coding agents are currently ungoverned, circulating as undeclared shared components with weak lifecycle discipline and insufficient permission articulation. The proposed deterministic control plane overlays mature supply-chain and process governance mechanisms, all realized in testable code and independently of the underlying LLM harness. The architecture is validated for enforcement fidelity and is motivated by strong prevalence data, but claims related to developer outcomes, overheads, or field generalizability await future empirical study. (2606.26924)