Blog · arXiv Analysis · Last reviewed June 25, 2026

The Agent Config Becomes the Supply Chain

Padmaraj Madatha's June 2026 arXiv paper on deterministic control planes for LLM coding agents treats repository instructions, rules files, and IDE-specific agent definitions as a supply-chain problem. The useful warning is that copied configuration can steer coding agents before anyone has declared what authority that configuration should have.

The Config File Joins the Build

The arXiv record for A Deterministic Control Plane for LLM Coding Agents lists arXiv:2606.26924 [cs.SE], submitted June 25, 2026, with Artificial Intelligence and Cryptography and Security as additional subject areas. The author is Padmaraj Madatha, and the arXiv comments describe a 45-page paper with dataset and reproduction scripts archived under Zenodo DOI 10.5281/zenodo.20780913.

The paper's object is not the model and not the IDE. It is the layer that tells coding agents how to behave inside a repository: rules files, agent definitions, and IDE-specific markdown. These files can decide what the agent should read, modify, avoid, test, explain, or treat as project truth. They sit close to source code, but they are often governed with less discipline than source code.

That makes the page in-theme for Spiralism. The agent config is a small text artifact that turns into delegated authority. Once copied into a repository, it can shape future edits, tests, terminal commands, and review habits. The prompt becomes infrastructure.

What the Study Found

Madatha reports a prevalence study of 10,008 public GitHub repositories, including 6,145 AI agent configuration files. The most robust finding is propagation: 10.1 percent of tracked paths were SHA-256 exact duplicates across independent repositories after fork adjustment, and 75.5 percent of clone pairs crossed organizational boundaries.

The paper treats two other patterns as indicative rather than definitive. First, many configs show shallow revision history: the abstract reports a 58 percent single-commit majority and an age-normalized rate of 0.4 commits per month for agent configs versus 0.6 for CI/CD workflows in the same repositories. Second, declared permission boundaries are rare: less than 1 percent of agent configs compared with 33 percent of GitHub Actions workflows, with the paper warning that the parser has only 31 true positives.

The conservative reading is not that copied configs are always malicious. It is that agent instructions now move like software components while often lacking the metadata, lockfiles, review practices, and permission declarations expected of other build machinery.

The Control Plane Proposal

The paper proposes a deterministic control plane above the coding harness, not a replacement for it. The reference implementation is Rel(AI)Build. It treats agent definitions as managed supply-chain artifacts through SHA-256 content addressing, HMAC-stamped lockfiles, and hash-chained audit logs.

Rel(AI)Build also enforces tiered permissions and attack-derived command and path blocklists before the LLM is invoked. It 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 with Jaccard similarity.

The important design choice is where determinism lives. The paper does not ask another model to supervise the config layer. It argues that install-time gates, blocklists, phase-state transitions, trace links, and drift checks should be tool-agnostic, auditable, and deterministic. The coding agent may remain probabilistic; the control plane around its definitions should not be.

Where the Evidence Stops

The paper is careful about limits. It says developer outcomes remain future work. It also states that the prevalence study measures a governance gap rather than proving that cloned agent configs cause incidents or that Rel(AI)Build improves real deployment outcomes. The permission-boundary result is explicitly fragile because it depends on a small parser-positive set.

Its supply-chain controls also have boundaries. The PDF says SHA-256 integrity, HMAC lockfiles, and audit logs protect against accidental corruption and automated tampering in a shared repository, but not against every adversarial signing scenario. The architecture governs process and configuration, not the semantic correctness of generated code. Jaccard drift thresholds are operational defaults pending calibration.

Those caveats make the paper more useful, not less. A governance artifact should show where its proof ends. Here the verified claim is narrow: coding-agent configuration is being copied across repositories, and there is a plausible deterministic control-plane design for making those definitions more traceable.

Why This Is Governance

The coding-agent config is easy to underestimate because it is ordinary text. But ordinary text can become the standing order for an autonomous developer. It can quietly change what counts as a valid test, which files are in scope, whether shell commands are allowed, and how the agent reasons about project priorities.

This connects to the site's earlier pages on the Codex workflow reorganization, coding-agent fingerprints, and AI coding agents. The pattern is the same: once the agent becomes part of software production, its local instructions are not just UX copy. They are organizational memory, access policy, and supply-chain input.

A repository should therefore treat agent instructions the way it treats build scripts and CI workflows. They need owners, diffs, review gates, source provenance, version locks, permission declarations, and rollback. Otherwise the software supply chain gains a new mutable layer that sounds like guidance but acts like authority.

Governance Standard

Every coding-agent definition should have a supply-chain receipt. The receipt should record the canonical source, hash, author, reviewer, target IDEs, inherited templates, allowed commands, denied paths, permission tier, effective lockfile, drift threshold, test obligations, and phase-state rule.

Changes to that definition should be reviewed like changes to build automation. A copied agent config should not enter a repository as an invisible convenience. It should arrive as a declared dependency whose authority, provenance, and rollback path are visible before the agent reads the next issue.

Sources

Return to Blog