Zero to Agent in 30 Minutes: Build a Supply Chain for Agent Context with Maxim Salnikov
Michelle Smith · rss · 2026-09-08 source ↗ Reader 🖥️
Agent Governance (Internal)Agent HarnessAgent SkillsSoftware Supply-Chain SecurityTool Manifest Integrity (Rug-Pull Defense)
Because agent skills, instructions, hooks, and other customizations now spread across machines, harnesses, and codebases with no record of their origin or whether they've changed, teams should manage agent context the way modern software already manages code dependencies — versioned, pinned, sourced from a vetted registry, and audited for drift in CI — using a purpose-built package-manager tool (APM) rather than ad hoc installation.
practical · expository — A syndicated recap/write-up of a live webinar demo, opening with a short problem framing (agent customizations spread with no record of provenance) before reporting a numbered six-step method as it was demonstrated by Microsoft's Maxim Salnikov. Reports what Maxim did and said rather than arguing a contested thesis, and closes with a promotional pointer to a follow-on episode and event.
Structure
| Part | Role |
|---|---|
| Opening problem framing: agent customizations are installed from public repos by the dozens and scattered across profiles, folders, and codebases with no record of provenance or change. | context |
| Introduction of Agent Package Manager (APM) as an npm-like tool for agent context, framed as bringing decades of software-supply-chain discipline to a domain that hasn't caught up. | thesis statement |
| Six numbered steps demoed live: (1) keep customizations in the codebase, (2) install APM and init a project, (3) pin to a version/commit hash, (4) reproduce exact setups with a lock file, (5) source from a vetted registry with a policy, (6) audit for drift and enforce in CI. | evidence / procedure |
| Closing pointer to the next episode (a shared-knowledge-base guest) and to APM's GitHub repo/quickstart, plus podcast/event promotion. | promotional coda |
Key terms
- supply chain for agent context
The set of practices (storage, versioning, pinning, vetting, auditing) applied to everything an agent is customized with — skills, instructions, hooks — treated as a chain of dependencies with provenance, the same way code libraries are. - pinning
Locking an installed skill/customization to a specific version or commit hash so that a later, differently-authored update under the same name cannot silently take effect. - frozen install / lock file
A log of every file and hash APM installed; `apm install --frozen` rebuilds that exact environment from the log rather than re-resolving from apm.yaml, guaranteeing a teammate's machine matches exactly. - policy file (APM)
A configuration that enforces which sources of customizations are approved for an organization, flagging anything pulled from an unvetted location. - audit for drift
The `apm audit` command comparing installed customizations against policy, catching unauthorized sources or content that has changed since installation; intended to run as a CI/CD gate.
Propositions
- explicitDevelopers now install agent skills, instructions, and other customizations from public repositories by the dozens, and the resulting files are scattered across user profiles, application folders, and codebases with no record of where they came from or whether they've changed since installation.conf: high
- explicitdevelopedAgent context should be treated the way modern software already treats its dependencies: versioned, pinned, and checked before it ships.conf: highextends ←The Claude Code active attack didn't stop. 294,842 secrets stolen from 6,943 machines. It evolved and now spreads through Python too and uses Claude Code itself to steal your secrets. The risk to your credentials just got bigger. · p16 — Agent context/config needs not only dependency-style versioning and pinning but protection and auditing as a security-sensitive asset, since it is an observed persistence target.
- explicitEvery customization should be kept in the codebase rather than scattered across a developer's machine, a harness's install folder, or enterprise-level defaults, so anyone on a new machine or using a new harness ends up with the same setup as everyone else.conf: high
- explicitCustomizations should be vetted for security before being added to a codebase, ideally sourced from an organization's own repository of skills already identified as safe to use.conf: high
- explicitAn installed skill should be pinned to a specific version or commit hash, because a legitimate skill can later be compromised and have malicious content slipped into a new version published under the same name.conf: highextendsArticle: Securing MCP in Production: Defense-in-Depth Beyond the Gateway · p3 — Extends manifest/version pinning from MCP tool definitions specifically to the broader category of installed agent skills and instructions, adding version-or-commit-hash pinning plus a lock file for whole-environment reproduction on top of the hash-and-diff-review pattern.
- explicitA tool managing agent customizations should scan installed files for hidden Unicode characters that may contain malicious instructions.conf: high
- explicitRebuilding an environment exactly from a logged file-and-hash history (a frozen/locked install) is more reliable for team consistency than re-resolving a manifest from scratch each time.conf: high
- explicitcontestedEnterprises should source customizations from a private, vetted registry rather than relying on public repositories alone, and enforce which sources are approved through policy files.conf: highcontradictsLessons from building Claude Code: How we use skills · p13 — Recommends the opposite governance model from Anthropic's own internal practice: a private registry gated by enforced approval policies, versus Anthropic's organic, bottom-up curation with no centralized gatekeeping team. A real tension in the corpus between two vendors' prescriptions for the same problem.extendsIncident 1368: Malicious OpenClaw Skills Reportedly Delivered AMOS Stealer and Exfiltrated Credentials via ClawHub · p5 — Proposes the missing governance mechanism — a vetted registry gated by policy, plus CI-enforced drift audits — for exactly the vetting failure the OpenClaw incident documents in an unvetted public skills marketplace.
- explicitAuditing installed customizations for policy compliance and drift should run as an automated CI/CD gate, not a one-off manual check, in order to protect the whole organization.conf: high
- implicitThe discipline the software industry already built for code dependencies (versioning, pinning, provenance tracking) transfers cleanly onto agent-context artifacts — skills, instructions, and hooks — without needing to be substantially reinvented.conf: mediumextendsFighting Tool Sprawl: The Case for AI Tool Registries · p4 — Both treat the AI-agent tool/context coordination problem as structurally identical to what package managers already solved for code libraries; this document extends that same analogy from tool registries specifically to the broader class of agent-context artifacts (skills, instructions, hooks), with APM as a concrete implementation.
- implicitAgent-context governance is currently an unmet need across the industry — teams presently lack any comparable discipline for their agent customizations, which is why a dedicated tool is needed to "close the gap."conf: medium
Arguments
Agent context (skills, instructions, hooks) should be managed with a dedicated package-manager-style tool (APM) rather than through ad hoc copying and manual installation. strength: medium
Explicit premises:
- Customizations currently spread across machines, harnesses, and folders with no record of origin or change (the stated problem).
- Software supply-chain discipline (versioning, pinning, checking) already exists and is proven for code dependencies.
Implicit premises:
- The failure modes of ungoverned code dependencies (silent compromise, environment drift, inconsistent setups) apply just as much to agent skills and instructions as to compiled libraries.
- A generic package-manager abstraction (init/install/audit, files-plus-hashes) can represent something as semantically fuzzy as "instructions and hooks" as cleanly and completely as it represents versioned code artifacts.
Inferences:
- Because APM logs a resolution history and hash per installed file, an agent's exact "context state" at any point in time becomes forensically reconstructable — giving agent customizations the same after-the-fact traceability a lockfile gives code, though the article never states this explicitly.
Customizations should be checked into the codebase, even though doing so makes the codebase bigger, rather than left at the machine or harness level.
Explicit premises:
- Storing customizations centrally in the codebase means anyone on a new machine or using a new harness ends up with the same setup as everyone else.
Implicit premises:
- Consistency of setup across environments is worth more than the cost (and review burden) of a larger codebase.
- "Same setup for everyone" achieved by checking files into one codebase doesn't just relocate the original scattering problem to the organization level — which is why the article layers steps 3–6 (pinning, lock files, vetted registry, CI audit) on top rather than treating step 1 alone as sufficient.
Inferences:
- Checking customizations into a codebase without also applying pinning and audit (steps 3 and 6) would solve consistency of the copy but not its security or staleness — an implication the article's own layered structure tacitly concedes by not stopping at step 1.
Narratives
- Maxim Salnikov's live, step-by-step demo of setting up an APM project (`apm init`), installing and pinning a skill, running a frozen install, and running `apm audit`.
→ Functions as an implicit feasibility proof — showing the workflow working end-to-end substitutes for an explicit argument that the approach is practical, rather than merely theoretically sound.
Questions addressed
- ✅ How can teams keep track of which customizations (skills, instructions, hooks) are installed into their agents, and where each one came from?
APM's manifest (apm.yaml), per-install resolution log, and file hashes give a queryable record of provenance for every installed customization. - ✅ How can teams prevent a previously-trusted skill from being silently swapped for malicious content under the same name (a rug-pull / tool-drift attack)?
Pinning to a version or commit hash, combined with hidden-Unicode scanning and CI-gated drift audits, is offered as the answer. - ⭕ How does an organization actually determine that a given skill is "safe to use" before adding it to a private, vetted registry?
- ⭕ Does pinning/hashing protect against a skill's meaning or behavior degrading within a single, unchanged, correctly-hashed version — as opposed to protecting only against the file itself being swapped?
Gaps
- incompleteThe article assumes step 5's vetting process — building "your very own enterprise repository of the customizations you've identified as safe to use" — is tractable, but never describes what that review actually checks or who performs it, unlike the fully mechanical steps (pin, lock, audit) that get concrete commands and behaviors. The hardest step in the whole pipeline is also the least specified.
Read next: The OpenClaw malicious-skills incident data (extract-openclaw-malicious-skills-incident-1368) for what a real-world skill-review process would need to catch; emerging agent-skill security-scanning services for candidate criteria. - incompletePinning and hashing protect against a skill's files changing after installation, but nothing in the described workflow addresses semantic or behavioral drift within a single, unchanged, correctly-hashed version — a skill's prose can mislead or underperform an agent even when its hash exactly matches what was originally reviewed. Hash-based integrity is necessary but not sufficient for trusting what a pinned skill actually gets an agent to do.
Read next: extract-kale-securing-mcp-production-defense-in-depth's argument (p9) that behavioral monitoring paired with static manifest pinning is more powerful than either alone applies just as directly to agent skills as to MCP tool manifests. - incompleteAs with the rest of this promotional recap series, no quantitative evidence, case study, or named enterprise adopter is offered for APM — no incident-prevention numbers, adoption figures, or comparison of how many organizations currently have zero versioning discipline for agent context versus how many have adopted something like this.
Read next: A follow-up piece profiling an actual enterprise APM rollout, or independent security-research coverage of agent-skill supply-chain incidents, to test whether the proposed discipline measurably reduces them.
Closes gaps elsewhere
- With Android CLI, Google is Making the Android Toolchain Agent-Friendly · g6 — Answers that gap's question of who curates skills and how they version against changes over time with a concrete mechanism: codebase-checked-in storage, version/commit-hash pinning, a private vetted registry gated by policy files, and CI-enforced drift audits — though it still leaves the vetting criteria themselves unspecified (see this document's own first gap).
Related documents
- Lessons from building Claude Code: How we use skills
- Fighting Tool Sprawl: The Case for AI Tool Registries
- How Claude Code works in large codebases: Best practices and where to start
- AI as an Enterprise Operating System
- Agent Skills
- Alex Wang's Post
- Audit your Agent files
- Building AI Agents For The Enterprise
- Claude Code Source Leak Megathread
- The Claude Code active attack didn't stop. 294,842 secrets stolen from 6,943 machines. It evolved and now spreads through Python too and uses Claude Code itself to steal your secrets. The risk to your credentials just got bigger.