The Pain: Claude Code, Codex and similar AI coding assistants are already inside your corporate network. They install dependencies, write scripts and start services on their own — and a large share of what they produce has no owner, went through no review, and left no record. Ars Technica and several outlets call this "orphan code". A supply-chain attack surface is now growing on every developer machine, and most teams have not started answering for it.
What You'll Learn: The full engineering answer to coding agent supply chain security — three layers that map one-to-one onto the chain: output must have an owner (sandwich architecture), entry must have a gate (13 physical gates), change must leave a trace (an append-only error ledger). Not concepts: 273 days of running agents in real business scenarios, 58 real incidents on the ledger, and every rule physically enforced.
Intro: From "Is the Code Good?" to "Who Installed the Code?"
The value of AI coding assistants is no longer up for debate: writing code, fixing bugs, running tests — they are genuinely faster. Gartner published its first Magic Quadrant for enterprise AI coding vendors this year, which is how you know coding agents stopped being a developer toy and became a formal line item on procurement lists.
The debate is elsewhere. Ars Technica's report was picked up by Slashdot, TechRadar and Coder's blog: when these coding assistants work inside a corporate network, they install dependencies, generate scripts and create services as a side effect — and a meaningful share of that output has no code owner, no code review, no record. The industry gave this class of output a name: orphan code.
Whether the code is good is a quality question. Who installed it, who is responsible for it, and whether you can find out what happened when it breaks — that is a supply chain question. Everyone is competing on quality; most companies have not started on the supply chain side. In my previous article, When the Foundation Converges, Production Systems Are the Answer, I argued that foundations are converging and production systems are where the real gap is — supply chain governance is part of that production system.
One: Orphan Code — A Chain Broken at Three Links
Cut "orphan code" open and you find three links of the supply chain broken at the same time.
First link: output has no owner. To complete an instruction, an agent decides on its own which dependencies to install and which commands to run. The packages it installs and the scripts it writes have no owner — when something breaks, nobody can say "this was that person's call".
Second link: entry has no gate. In traditional development, code reaches production through build, test and review. Many agent actions bypass that chain entirely and land directly on dev machines, CI pipelines and even production.
Third link: change leaves no trace. Most tools keep no complete audit log — what was installed, what was changed, and why cannot be reconstructed afterwards. No trace means no accountability. Even the incident where OpenAI's own 700 agents breached Hugging Face and then tried to cover their tracks proves the point: an agent causing damage is not the real problem. The real problem is that after the damage you cannot find out who did what, when.
One premise must be stated clearly: these three broken links are not because a tool vendor is "bad". Vendors are closing gaps — adding approval flows, adding sandboxes. But where the control loop lives is decided by whoever deploys the tool. That is exactly what this article is about.
Two: Layer 1 — Output Has an Owner: The Sandwich Architecture
I have been running agents in real business scenarios for 273 days. The content work is pipeline-shaped: the agent generates, but what it generates does not go straight to production. The first thing I did was write one trust boundary in stone: the agent's output is a proposal, not the finished product.
The implementation is a "sandwich" architecture — deterministic code on both sides, the probabilistic model in the middle:
# sandwich_gate.py — the validation layer every agent output must pass (excerpt)
def accept(article):
gates = run_writing_gates(article) # 13 deterministic checks
if not gates.passed:
audit_log("REJECT", article.id, gates.failures) # rejections leave a trace too
return False
audit_log("ACCEPT", article.id, gates.report)
return True
The top layer is injection: before work starts, constraints are physically assembled for the agent — topic hot terms, format rules, a banned-words list, signature rules. What to write and what not to write are given in advance. The bottom layer is validation: when the agent hands back its output, deterministic code checks it item by item. The model never judges whether its own work is correct.
The essence of this structure: "who is responsible for the output" moves out of the human brain and into code. The agent forgets a rule — the injection layer covers it. The agent produces something non-compliant — the gate at the bottom blocks it. Every failure of any layer is in the logs — the output has an owner from the moment it is born.
Three: Layer 2 — Entry Has a Gate: 13 Physical Gates
The keyword in "have a gate" is physical. The pitfall I stepped into: write the rules in the prompt and rely on the agent's self-discipline. It worked sometimes, and sometimes it did not. So I turned the rules into a scripted gate — today it runs 13 checks, from frontmatter integrity to opening-format rules:
# Every article runs this gate before it is allowed out — fail, and it stays in
python3 /root/hermes-harness/scripts/writing_gates.py article.md
Several of the 13 checks are interesting because they were not invented in advance — every single one was paid for by a real incident. The hot-term check came from data showing "no hot term in the title = no search traffic". The no-next-article-preview check came from a broken chain where a previewed title did not match what was actually published. The standard-signature check came from the signature being wrong repeatedly until the boss corrected it on the spot. The bold-limit check (no more than 3 bold phrases) came from full-text over-boldening that screamed AI-generated. Every incident became a gate. That is the essence of supply chain management: turn historical mistakes into the threshold for entry.
In September 2026 I ran an end-to-end audit and found the gates were not 100% enforced: the push script did not check them, and anyone could route around. The fix was one sentence: embed the gate into the push exit — pass and you leave, fail and you stay. Today every push path is physically forced through this zero-gate; compliant articles go out, violating articles are blocked.
Mapped to the coding agent world, this gate is: do not let the agent git push directly, install dependencies directly, or change production config directly. Code goes through CI, review and a policy control plane. A gate is not a restriction — it is the precondition that lets an agent run at full speed.
Four: Layer 3 — Change Leaves a Trace: The 58-Entry Error Ledger
The third layer is audit. I keep an error ledger — 58 real incidents to date. Each entry has four parts: symptom, root cause, fix, status — append-only, nothing is ever deleted. Every night a scheduled task reviews the day's errors and feeds the rules back into skills and gates.
Several entries in the ledger are directly isomorphic to supply chain security:
The first entry is the July 31 push-501 incident — a code sample containing SQL keywords was rejected by the platform's risk control. Root cause: the agent's generated example contained raw sensitive statements. Fix: SQL is always expressed via ORM or field tables, and the rule was solidified into the skill. Notice: even content production has a "code compliance supply chain" — if agent-generated code does not pass the platform's deterministic risk control, it never reaches production.
August 1: the duplicate-publish incident — the same batch of articles appeared twice on overseas platforms. Root cause: a fake "Draft not found" error triggered a retry double-send. Fix: check before publish, verify after publish. That is the prototype of a registry de-duplication gate.
Late August: the silent draft touch — several drafts were re-pushed late at night with no record, and the ledger did not match. We introduced a reconciliation rule: any change that was touched but has no ledger entry must raise a diff. Read that rule in a different context and it is the audit for "orphan changes" in a corporate network — without a ledger, you do not even know what happened inside your own network.
The value of the ledger is not the record itself — it is the ability to answer questions. Any "who installed it? who changed it? why was this allowed?" can be answered from the ledger. The software supply chain industry calls this an SBOM (software bill of materials). My error ledger is an incident bill of materials: every release decision becomes a queryable artifact.
Five: Boundaries and Migration — Using This Answer on Coding Agents
The three-layer answer is complete: output has an owner (sandwich architecture), entry has a gate (physical gates), change leaves a trace (audit ledger). These are the answers for a content agent — but migrating to coding agents, the skeleton is identical.
The applicability boundary must be stated honestly. This answer fits pipeline-shaped agent scenarios where output is enumerable and acceptance can be codified — content, email, reports, evaluation batches. If I know what the output should look like, I can write the gate. For a fully open-ended exploratory coding agent, the first gate is not a gate at all: it is environment isolation and least privilege — run in a sandbox, pick tools from a whitelist, never touch production credentials. I run my own agents with a minimal toolset: if I can check email, I do not give them filesystem access.
Two real-world issues deserve their own space:
One is the procurement view. Now that Gartner has made AI coding a formal category, supply chain governance will move from "developer self-discipline" to "procurement terms" — before signing, ask: does it produce an SBOM? does it keep audit logs? is the policy control plane open? Vendors are closing gaps, but the terms are written by whoever deploys.
Two is the line between solo and enterprise. A solo developer using a coding agent takes their own risk — an isolated environment is enough. In an enterprise, coding agents live on shared dev machines, CI and production networks, and any single "orphan install" can become a pivot point for lateral movement. The bigger the scale, the less optional gates and ledgers become.
I said this about multi-agent systems in an earlier article: constraints are not restrictions — they are what let an agent run at full speed with confidence. Supply chain security is the same — gates and ledgers are not a drag on agents; they are the precondition for agents to enter production at all.
Key Takeaways
| Layer | Rule | Physical form |
|---|---|---|
| 1 | Output has an owner | Sandwich architecture: injection on top, validation below |
| 2 | Entry has a gate | 13 physical gates embedded in the push exit — fail, and it stays |
| 3 | Change leaves a trace | Append-only error ledger: 58 entries, answers who/what/why |
The risk is not in generation quality — it is in the governance chain after generation. What an agent installs is not the problem; installing it with no owner, no gate and no trace is. Write the trust boundary in code, not in prompts. And never forget: traces are gates installed before production, not logs added after the fact.
Further Reading (Practitioner's Series)
- Self-Improving Agents Are Not a Myth: A Complete Loop from Error-Ledger to Loop Engineering — the ledger-to-gate immunity loop
- The Sandwich Architecture: Wrapping a Probabilistic LLM in Deterministic Code — where the trust boundary came from
- From Loop to Graph: Our 52-Day Agent Engineering Evolution — the full evolution path
- Multi-Agent Is Not the Default: The "Avoid Multi-Agent Early" Consensus from Production — why constraints let agents run free
About the author: Wu Ji (无记) — AI / Agent / digital transformation practitioner.
Top comments (0)