Harness Config as Supply-Chain Artifact

The agent harness configuration tree — ~/.claude/ and analogous directories for OpenCode, Codex, Gemini, dmux, and similar agentic developer environments — is itself a software-supply-chain artifact. Hooks, MCP server manifests, subagents, slash commands, skill .md files, and CLAUDE.md instructions compose a runtime that takes attacker-influenced inputs (community skills, public MCP servers, retrieved documents, repository templates) and exposes sensitive primitives (shell, filesystem, network, model API tokens). Treating that tree as out-of-scope of conventional supply-chain assurance leaves a category of attacks undetectable at build time.

The Argument

Three observations compose the position:

  1. Composition without provenance. Developers install community skills, connect MCP servers, and configure hooks without any automated way to audit the security of their setup. The composition step is identical in structure to npm install or pip install — third-party code becomes runtime behavior — but the artifacts in question (skill manifests, MCP server definitions, hook scripts) are not covered by the existing AI-BOM / SBOM / SLSA primitives, which target model artifacts and library dependencies rather than harness configuration.
  2. Static-analyzable risk surface. The same risks that classical SAST detects in application code (hardcoded secrets, command injection via interpolation, wildcard permissions, dangerous network primitives, container-escape primitives, reverse shells, credential-store reads, log tampering) reproduce verbatim inside hook scripts and Bash(...) permission rules. The risks that classical SAST cannot detect (prompt injection, hidden Unicode instructions, time-bombs in CLAUDE.md) are detectable by analogous rule families when applied to the harness-config tree.
  3. Provenance-aware confidence is required. A naive scanner treating every .claude/-shaped file as live runtime drowns in noise from template catalogs (mcp-configs/), docs examples (docs/, commands/), plugin manifests (hooks/hooks.json), and manifest-referenced hook implementations. The scanner must distinguish source kinds and weight findings accordingly, because “the repo ships this risky template” is a fundamentally different finding from “this is enabled right now” and ought to grade differently. Real secrets stay critical regardless of source kind.

The structural conclusion: the agent harness configuration tree belongs in the same supply-chain assurance flow as the rest of the build, with a SAST-style scanner, CI gating, baseline-drift comparison, SARIF integration with code-scanning UIs, and evidence packs suitable for audit handoff.

Worked Example

AgentShield is the first sourced open-source implementation of this position. 102 rules across five categories (Secrets / Permissions / Hooks / MCP Servers / Agents) with provenance-aware runtimeConfidence labels operate over the Claude Code .claude/ tree, with optional layered analyses (--injection for active prompt-injection probing, --sandbox for hook sandbox execution, --taint for data-flow tracking, and a three-agent Claude Opus 4.6 adversarial pipeline). The scanner produces SARIF output for GitHub code-scanning UIs, baseline-drift comparison for regression gates, deterministic redacted evidence packs for audit handoff, and stable-fingerprint remediation plans for CI ticketing. See the source page for the full instrument.

Scope Limit

The position is general; the AgentShield rule corpus is harness-specific. The rules are tuned for the .claude/ shape, and other harnesses (OpenCode, Codex, Gemini, dmux, terminal-agent wrappers) currently surface only as local adapter-evidence markers rather than first-class rule targets. The generalizable contribution from the AgentShield ingest is the design discipline — config tree as artifact, provenance-aware confidence weighting, cross-file manifest awareness — not the specific 102-rule corpus. A peer non-Claude-Code instrument is the precondition for treating the position as standard rather than vendor-specific.

Relationship to Existing Wiki Coverage

  • Supply Chain Security for Agents has historically covered skill-marketplace controls (Aguara Watch, SecureClaw), MCP server provenance, and incident anchors (ClawHavoc, SANDWORM_MODE, LiteLLM). This concept extends the practice’s scope: not just the content (skills, MCP packages) but the composition manifest (hooks, permissions, CLAUDE.md) is a supply-chain artifact.
  • AI-SPM tracks AI asset inventory and misconfiguration detection at the enterprise control-plane level (Microsoft Agent 365, Wiz AI-SPM, Knostic Kirin). Harness-config scanners are a narrower per-harness instance of the same pattern, added to the AI-SPM tooling categories.
  • AI-BOM covers build-time and runtime bills of materials for model and skill artifacts. Harness configuration sits adjacent to AI-BOM but is not currently part of any AI-BOM spec (CycloneDX 1.6 ML-BOM, SPDX 3.0 AI extension).
  • MCP Security covers the threat surface of MCP itself. Harness-config audit is the static-analysis layer over MCP server definitions inside the host harness — complementary to the gateway / runtime / IAM controls MCP Security focuses on.
  • CMM D8 (Supply Chain & AI-BOM) is the closest current home; harness-config audit is a candidate evidence dimension to add when a second sourced peer instrument lands.

See Also

  • Control-Efficacy Gate — sibling generalization from the same AgentShield ingest; corpus-gate and time-bound exception lifecycle as continuous-efficacy primitives that operate over the scanner this concept names.
  • AgentShield · AgentShield README — concrete worked example.
  • Lethal Trifecta — the structural composition that harness-config rules catch at static-analysis time (Bash(*) + curl ${file} + remote MCP transports as configuration-time signal of trifecta exposure).