Agent configurations for LLM-driven tooling are widely copied and under-governed: 10.1% of tracked paths are exact duplicates across independent repositories and under 1% declare permissions. The paper proposes Rel(AI)Build, a deterministic, content-addressed control plane to audit, lock, and enforce permission and supply-chain invariants before agent execution.

Main Finding

Agent configuration files that steer IDE-integrated LLM coding agents are a largely unmanaged supply chain and propagate widely across repositories. In a 10,008–repository snapshot (6,145 tracked agent config files), exact-duplicate propagation is common (10.1% fork‑adjusted, measured by SHA‑256), and most clone pairs cross organisational boundaries (75.5%). To address integrity, traceability, permission and portability gaps, the paper proposes a deterministic, tool‑agnostic control plane (Rel(AI)Build) that treats agent definitions as managed software artifacts and enforces pre‑execution, deterministic governance (content addressing, install‑time gates, tiered permissions, phase state machine, drift detection, and compile‑to‑many).

Key Points

• Prevalence evidence
  • 10.1% of tracked config paths are exact duplicates across independent repos (fork‑adjusted; SHA‑256 content hashing).
  • 75.5% of duplicate/clone pairs cross organisational boundaries.
  • 58% of agent config files appear in the corpus as single‑commit artifacts (shallow revision depth).
  • Age‑normalised commit rates show configs are revised less often than CI/CD workflows (0.4 vs 0.6 commits/month).
  • Declared permission boundaries are rare: <1% of agent config files declare permissions vs ~33% for GitHub Actions workflows (permission detection limited by a fragile parser; n=31 true positives used for calibration).
• Structural risks identified (the “thin governance surface”)
  • Gap 1: Configs are unmanaged software artifacts (no provenance, tamper evidence, or canonical approved version).
  • Gap 2: Execution can be unbounded (no enforced requirement→implementation→test trace, no hard caps on self‑correction loops). This is an architectural/process risk and not observable in static configs.
  • Gap 3: Expertise does not port across harness dialects (multiple config dialects, tool syntaxes).
  • Other concerns: prompt drift, dangerous commands, and lack of enforced traceability.
• Proposed deterministic control plane (Rel(AI)Build)
  • Treats agent definitions as a supply chain with SHA‑256 content addressing, HMAC‑stamped lockfiles, and append‑only hash‑chained audit logs.
  • Enforces deterministic pre‑execution guardrails: tiered permission model bound to the supply chain; attack‑derived command/path blocklists applied as install‑time and pre‑tool‑use hooks; post‑delegation scan/diff gate.
  • Provides a tokenisation‑normalisation pipeline and prompt‑drift detector (Jaccard similarity) to detect cosmetic prompt edits as an operational risk surface.
  • Implements a deterministic phase‑gated lifecycle (state machine) enforcing ordering and requirement→file→test traceability; blocks execution on invariant violations.
  • Implements define‑once / compile‑to‑many transformer to emit canonical definitions across seven IDE targets to port expertise.
  • Determinism scope: install‑time gates, blocklists, and phase transitions are deterministic code; linkage of trace artifacts is cooperative and auditable post‑hoc (not LLM‑enforced).
• Implementation & evaluation notes
  • Reference implementation in Node.js with modular, auditable components (hashing, HMAC, state machine, Jaccard drift calc).
  • Runtime artifacts: phase‑state.json, trace.json, lockfile, and hash‑chained audit logs.
  • Conformance tests: injected‑violation tests confirm mechanisms enforce stated invariants (N reported as 10/15/20 across test sets).
  • Empirical work includes prevalence measurement, conformance tests, and a DRIFT vignette; author notes outcomes for developer productivity are future work.

Data & Methods

• Corpus and measurement
  • Snapshot: 10,008 public GitHub repositories, yielding 6,145 tracked agent configuration files.
  • Duplicate detection: SHA‑256 content hashing (threshold‑independent), fork‑adjusted counts to remove obvious copy relationships; duplicate rate = 10.1%.
  • Cross‑organisation analysis: measured clone/duplicate pairs across organisational boundaries; 75.5% cross orgs.
  • Revision depth: commit counts per file; 58% single‑commit majority.
  • Age‑normalisation: compared commits/month for agent configs vs CI/CD workflows (0.4 vs 0.6 commits/month).
  • Permission declaration detection: fragile parser; results calibrated on n=31 true positives; observed <1% permission declarations for agent configs vs ~33% for Actions.
  • Credential patterns and dangerous command heuristics: a small % (3.18%) credential hits (not primary focus).
• Implementation & testing
  • Rel(AI)Build modules implemented in Node.js; CLI and optional MCP server interface.
  • Deterministic mechanisms implemented as testable modules: content hashing, HMAC lockfiles, append‑only hash‑chained audit logs, phase state machine, tokenisation normaliser, Jaccard similarity drift detector, compile‑to‑many transformer.
  • Conformance testing: injected violations to verify each deterministic invariant (reported test counts N=10/15/20).
  • DRIFT vignette and examples provided (single‑case illustrative; not a behavioural validation).
• Limitations called out by authors
  • Static repo analysis cannot observe runtime process governance or enforceability of human‑in‑the‑loop constraints (Gap 2).
  • Permission detection relies on a fragile parser; permission absence finding is indicative, not definitive.
  • Evidence is preliminary and characteristic of early‑stage SE work; no controlled developer productivity study yet; deployment‑level impacts unmeasured.
  • Corpus limited to public GitHub snapshot (June 2026) — harness formats and practices evolve quickly.

Implications for AI Economics

• Systemic risk and externalities
  • High duplication and cross‑org sharing of agent configs imply correlated exposure: a malicious or erroneous config template can propagate widely and rapidly, increasing systemic vulnerability and potential expected losses from supply‑chain attacks (typosquatting, malicious hooks).
  • Standardised, content‑addressed registries and lockfile practices reduce uncertainty about provenance and tamper risk, lowering expected incident frequency and severity — this is a positive externality for adopting organisations and their supply networks.
• Costs and adoption tradeoffs
  • Implementing a deterministic control plane introduces direct compliance and engineering costs (writing/maintaining canonical definitions, running install‑time gates, CI validators, audits). Firms will weigh these against reduced risk and possible regulatory/compliance requirements.
  • For regulated industries (finance, healthcare, critical infra), deterministic governance is likely to produce net economic benefits by enabling safer LLM tooling use and reducing audit/compliance overheads; for small teams, upfront costs may deter adoption unless third‑party tooling or managed registries emerge.
• Productivity and labour economics
  • The define‑once / compile‑to‑many approach can reduce duplication of effort across IDEs and teams, lowering maintenance costs and friction from multi‑tool environments — potential long‑term productivity gains.
  • The net effect on developer productivity is undetermined: phase gates and mandatory traceability can increase process overhead (slower iteration) but could prevent costly debugging/security incidents downstream. A controlled developer study (recommended) is needed to quantify this tradeoff and inform ROI calculations.
• Market structure and incentives
  • The architecture creates a new product category (canonical registries, governance toolchains, compile‑to‑many transformers) with positive network effects: widely adopted canonical definitions and registries improve trust and interop, potentially concentrating market power among registry providers or tool vendors.
  • Deterministic governance could become a compliance differentiator; firms may pay premiums for certified control‑plane providers or audited registries, creating monetisation pathways for vendor tooling.
• Regulatory and policy alignment
  • Deterministic, auditable governance maps well to emerging standards (NIST, SLSA, OWASP) and could lower regulatory compliance costs by providing deterministic evidence trails (HMAC lockfiles, hash‑chained logs).
  • Policymakers may incentivise or mandate such supply‑chain controls for agentic systems in sensitive sectors, shifting market demand toward control‑plane solutions.
• Measurement and further research needs
  • Economic value estimates require quantifying: (a) frequency and cost distribution of config‑driven incidents today, (b) overheads of adopting deterministic governance, and (c) productivity impacts of phase gating vs incident avoidance.
  • Recommended next steps for economic analysis: controlled field/developer studies measuring cycle time, error rates, incident remediation costs; cost‑benefit models for small vs large orgs; simulations of propagation and expected loss under different registry/adoption scenarios.

Summary conclusion: The paper documents empirically that agent configuration files are commonly duplicated and unmanaged across repositories, creating correlated supply‑chain risk. Rel(AI)Build proposes a deterministic, testable control plane that treats these configurations as managed software artifacts and enforces pre‑execution governance, traceability, and cross‑IDE portability. Economic consequences include reduced systemic risk and potential productivity gains from standardisation, balanced against upfront compliance and engineering costs; exact welfare and adoption impacts require further empirical economic and developer‑study research.