Dependency Drift In Agent Stacks: When A Trusted Skill Updates Into An Untrusted One

TL;DR

A skill you reviewed and trusted at version 1.2 can become an untrusted, malicious, or compromised skill at version 1.3 without any visible change to your registration, your manifest, or your audit logs. This is the dependency drift problem, and it is the agent supply chain attack pattern most likely to compromise organizations that have done everything else right. The trust scope of a skill must always include a version range, with deliberate updates rather than passive drift. This post lays out the drift patterns, the architectural primitives that prevent silent updates, the operational discipline of update review, and a Skill Version Pin Policy that any team can adopt this week. The framework introduced here is the Trust Window: every approved skill version has a defined trust window beyond which the skill is considered untrusted regardless of past approval, forcing a deliberate re-review at version boundaries.

The Update That Changed Everything

The failure mode begins where most other supply chain controls end. A team imports a skill. The team reviews the skill carefully, runs it through the capability diff review described in the previous post, scopes its permissions, sets up the trust boundary, and watches it operate cleanly in production for several months. The team trusts the skill. The skill has earned that trust through observed behavior. Then, one morning, the skill behaves differently. It makes a network call to an unfamiliar host. It exfiltrates data. The team investigates. The skill, they discover, was updated overnight to a new version that introduces a malicious capability. The trust the team had built up was for version 1.2; the production system was running version 1.3, and version 1.3 was a different skill in every way that mattered.

This is dependency drift. It is the most underestimated attack vector in agent supply chains in 2026, and the reason is structural: most teams' trust models are version-blind. They register a skill by name, they reason about its behavior in general terms, and they accept whatever version happens to be loaded at runtime. Version pinning, which has been a basic discipline in conventional package management for fifteen years, is patchily implemented in agent skill platforms and is often disabled in the name of "keeping things up to date." The result is that skill updates can happen silently, in environments where the original review was specific to a particular version, and the trust the team built up applies to a skill that is no longer the skill running in production.

The specific incident that crystallized this for us involved a popular open-source MCP server, used by many teams, that was acquired by a different operator in mid-2026. The new operator inherited the server's npm namespace, the GitHub repository, the maintainer access, and the trust the open-source community had built up over more than a year. The new operator pushed an update to the server that included new code: legitimate new features and one undocumented tool that exfiltrated context to an attacker-controlled host. The update was signed, was attested, was published through normal channels. Every team that had the server installed with auto-update enabled, which was the default, picked up the new version within hours. The old skill that those teams trusted had ceased to exist. The new skill that they were now running had earned no trust at all, but inherited the prior version's trust by default.

The purpose of this post is to address this attack vector with the same seriousness it deserves. We will walk through the drift patterns, the architectural primitives that make drift visible and controllable, the discipline of version review, and the Skill Version Pin Policy that turns the discipline into a documented operational practice. The point is not to make updates impossible; it is to make them deliberate. The agent supply chain has to be at least as careful about version boundaries as conventional software supply chains have been since 2015, and most of it is not yet, which is precisely why the attack pattern works.

The Drift Patterns

Dependency drift takes several distinct shapes, and the operational responses depend on which shape you are facing. The Trust Window framework, introduced later in this post, is the architectural answer; before we get there, the drift patterns themselves are worth enumerating because they each represent a different category of attack and a different set of defensive opportunities.

The first pattern is acquisition drift. A skill is taken over by a new operator: through acquisition, through inheritance, through abandonment-and-reclaim. The operator changes; the skill's namespace, repository, and signing keys typically stay the same. The new operator publishes new versions under the same identity that the previous operator used, and consumers see the updates as continuations of the prior version line. This pattern is particularly dangerous because the visible signals (signing keys, registry namespace, GitHub repository) all look unchanged. The change is in the human or organization behind the signing key, which is invisible to most automated trust systems.

The second pattern is feature creep drift. The skill author, with no malicious intent, expands the skill's functionality over time. Each version adds capabilities that the previous version did not have. Individually, each addition seems modest. Cumulatively, the skill grows from a focused tool into a sprawling capability that bears little resemblance to what the importer originally reviewed. The drift is benign in motivation but the consequences for the importer are similar to malicious drift: the skill running in production is not the skill that was approved, and the difference accumulates capability surface that the importer never sanctioned.

The third pattern is dependency drift in the literal sense: the skill itself does not change much, but its dependencies change, and the dependencies introduce new behaviors. A skill might pin its first-order dependencies but accept whatever version happens to be available for transitive dependencies. A new version of a transitive dependency, perhaps with new behaviors, perhaps compromised, becomes part of the running skill without the skill author or the importer being aware. The damage here can be invisible from the perspective of the skill itself, because the skill's own code is unchanged; only the code it loads at runtime is different.

The fourth pattern is build drift. The skill's source is unchanged, the dependencies are unchanged, but the build environment is different from the previous version. New compiler versions, new build flags, new optimization passes, new injected telemetry libraries, new code-signing intermediaries can all introduce changes to the artifact that are invisible at the source level. Build drift is rare and usually benign, but it is the pattern that can hide deliberate compromise of the build infrastructure, which is one of the highest-leverage attack vectors in the conventional software supply chain.

The fifth pattern is reconfiguration drift. The skill itself is unchanged, the dependencies are unchanged, the build is unchanged, but the runtime configuration that drives the skill's behavior changes. New default values, new feature flags, new configuration files shipped alongside the skill can change what the skill does without changing what the skill is. This pattern is particularly subtle because the version number can be presented as identical between two configurations whose runtime behaviors are meaningfully different.

The drift patterns are not mutually exclusive; a single update can exhibit several patterns simultaneously. A skill that has been acquired by a new operator (acquisition drift), expanded with new capabilities (feature creep drift), and shipped with new transitive dependencies (dependency drift) is a triple-drift event, and the cumulative effect on the importer's trust model is much larger than any one pattern alone. The defensive response has to address all five patterns, because attackers can choose whichever pattern best suits their goals and your defensive gaps.

The Trust Window Framework

The central framework this post introduces is the Trust Window. The principle is that every approved skill version has a defined window of trust, beyond which the skill is considered untrusted regardless of past approval. The window is bounded in two ways: by version (trust does not automatically extend to new versions) and by time (trust expires after a defined duration even if no new version has been published). The combination forces deliberate re-review at version boundaries and at time boundaries, which closes the silent-update attack vector at its root.

The version bound of the trust window is straightforward. When a team approves a skill at version 1.2.3, the approval is for that exact version, not for the version line. Version 1.2.4, 1.3.0, or 2.0.0 are different artifacts that have not been reviewed. The trust does not extend automatically. The runtime, when it sees a request to use a version that has not been approved, blocks the request and surfaces an alert. This requires the runtime to track approved versions explicitly, to verify the running version against the approved set, and to default to deny for unapproved versions. Each of these is a small engineering investment with large operational payoff.

The time bound of the trust window is more subtle but equally important. Even if a skill has not been updated, the world around it changes. New vulnerabilities are discovered in its dependencies. New attack patterns become relevant. The team's own context changes: new data classes flow through the agent, new downstream systems are connected, new operational requirements emerge. A skill version approved a year ago is not necessarily safe to keep running today, even if its code is byte-for-byte unchanged. The time bound forces periodic re-review, with the review duration calibrated to the team's operational tempo and risk tolerance: typically quarterly for high-risk skills, semi-annually for medium-risk skills, annually for low-risk skills.

The operational shape of the Trust Window is a record per (skill, version) pair, with the approval status, the approval date, the expiration date, the conditions of approval (any scope reductions or guardrails), and the named approver. The runtime checks the record on every load: is this version approved, is the approval still valid, are the conditions in place. Versions outside the window cannot run; expired approvals cannot run; conditional approvals running without their conditions cannot run. The result is a fleet where every running skill at every moment has a current, valid, version-specific approval record, and any deviation from this state is visible immediately.

The Trust Window is not free. It requires version-aware infrastructure (registries, runtimes, policies) that not all current platforms support natively. It requires operational discipline (periodic review, deliberate updates) that has cost in human time. It requires acceptance that the agent fleet's capability surface will not always be "the latest version of everything," which is a cultural shift for teams used to the assumption that newer is always better. The cost is real, and the benefit is the elimination of an entire category of attack that is otherwise hard to defend against.

Update Review As A Discipline

The operational discipline that matches the Trust Window is update review. When a new version of an approved skill is published, the team reviews the new version with the same care that the original import received. The review may be lighter than the original (for minor updates from trusted authors that introduce no new capabilities) or heavier (for major updates, for updates that introduce new capabilities, for updates from authors whose trust profile has changed). The point is that the review happens deliberately, and the new version becomes part of the trust window only after the review concludes positively.

The shape of update review is the four-dimension diff from the previous post (permissions, network destinations, action types, identity claims) applied to the difference between the approved version and the candidate update. Most of the diff is usually empty: minor updates rarely introduce new permissions or new destinations or new action types. The diff that is not empty is the focus of the review. New permissions in version N+1 require justification. New destinations require investigation. New action types require analysis. Updates that introduce zero new capabilities (purely bug fixes, performance improvements, internal refactoring) move quickly through review; updates that expand capability move slowly.

The second component of update review is dependency review. Even if the skill's own capabilities have not changed, its dependencies may have. Update review should include a check on the dependency tree: which transitive dependencies have changed version, which dependencies have been added or removed, what is the cumulative drift in the dependency graph. Modern tooling makes this much easier than it used to be: dependency lockfiles, software bill of materials (SBOM) artifacts, and dependency-tracking services can produce the diff automatically and surface the changes that warrant attention. The reviewer's job is to look at the surfaced changes and decide whether they are acceptable for this skill in this environment.

The third component is provenance review. The previous post in this cluster covered the Three-Anchor Provenance model: source, build, identity. Update review should verify that the new version's provenance is intact: same source repository, signed by acceptable keys; same build pipeline, signed by acceptable keys; same identity (or an acceptable change in identity) signing the release. A new version whose provenance has weakened (different source, different build, different signing identity) is suspicious even if the code looks fine, because the weakening of provenance is itself a signal that the skill's trust profile has changed.

The fourth component is operational review. Has the skill author's behavior changed in ways that warrant attention? Have they had recent security incidents? Have they been acquired by a new operator? Have their public communications about the skill changed in tone or in priorities? These signals do not always indicate problems, but they are worth surfacing in update review because they change the prior probability of trustworthy behavior. A skill author who has just suffered a public security incident is, all else equal, a higher-risk source for new versions in the immediate aftermath, regardless of how clean the version looks on inspection.

Update review takes time. For a fleet with many skills, the cumulative review burden can be substantial. Teams that adopt the discipline find that a few specific patterns help manage the burden: trusted authors get faster review (with the trust earned over time and revocable on incident), skills with stable APIs get faster review (because the diff is usually small), critical skills get heavier review regardless of size (because the consequences of bad updates are larger). The pattern is to spend more review effort where the consequences are larger and less where the consequences are smaller, with explicit policies that codify the calibration.

The Architectural Primitives Of Pin Discipline

The Trust Window and update review require architectural support to be enforceable. Without the architecture, the policy is wishes; with the architecture, the policy is code. The primitives that matter are version-pinned manifests, version-aware runtimes, deny-by-default unapproved-version handling, and tamper-evident approval records.

Version-pinned manifests mean that every reference to a skill in your configuration is to a specific version, not a version range. Modern package managers support this through lockfiles or pin files; the same pattern applies to agent skill manifests. The skill is referenced by the (name, version, hash) tuple, with all three required to load. A reference to a name without a version is rejected by the registration system. A reference to a (name, version) pair without a hash is accepted but flagged for upgrade to include the hash. The hash provides verification that the artifact loaded matches the artifact approved, even if the registry is somehow compromised or the version metadata is wrong.

Version-aware runtimes mean that the runtime checks the version of every skill it loads against the approved set, not just at registration time but at every invocation. The check is fast (a hash comparison) and frequent (every load). When a runtime is asked to load a skill version that is not in the approved set, it refuses, logs the attempt, and surfaces an alert. The alert pattern matters: silent refusal is a debugging hazard, while loud refusal lets operators see when something has gone wrong. The right pattern is loud refusal with clear error messages that explain what version was requested, what version is approved, and how to reconcile the difference.

Deny-by-default unapproved-version handling means exactly what it sounds like. The runtime's default response to a version it has not seen approved is no. There is no inheritance of trust from previous versions. There is no shrug-and-load behavior for minor version differences. The default is deny, and approval has to be explicit. This is the inverse of the default in most current platforms, where the default is to load whatever version is requested and to surface only the most obvious anomalies. Inverting the default is a one-time engineering change with permanent operational benefits.

Tamper-evident approval records mean that the approval history is stored in a way that adversaries cannot retroactively modify. The records include the (skill, version, hash) tuple, the approval date, the named approver, the conditions of approval, and a signature from the approver. The records are stored in a tamper-evident store: an append-only log, a Merkle tree, or a similar structure that allows verification that the records have not been altered after the fact. The point is that, when an incident requires forensic investigation, the approval history can be trusted as a starting point for the investigation. If the approval records can be altered by anyone with sufficient privileges in your registry, then the records cannot be relied on, and the entire pin discipline becomes harder to defend after the fact.

The primitives compose into a stack: pin manifests at the top, version-aware runtime in the middle, tamper-evident records as the foundation. Implementing the stack requires real engineering work, but the work is well-understood: the primitives have been built and refined for conventional software supply chains for over a decade, and porting them to agent skill platforms is engineering, not research.

The Subtle Case Of Auto-Update

A specific architectural choice deserves its own section: auto-update. Most current agent skill platforms default to auto-update for installed skills, and many platforms make turning off auto-update difficult. The operational rationale is that updates often include security fixes, and that auto-update is the only way to ensure those fixes are applied promptly across a fleet. The security rationale is real but it is in tension with the version pin discipline, and the resolution requires care.

The naive answer is to turn off auto-update. This forces every update to go through review, which honors the version pin discipline. The cost is that security fixes also have to go through review, which slows their deployment and creates windows where known vulnerabilities are present in production. For some classes of vulnerabilities, the window is unacceptable: a remote code execution in a widely-used skill needs to be patched in hours, not days, and a review process that takes a week is the wrong tool for the urgency.

The better answer is selective auto-update: distinguish between security-only updates and general updates, and allow auto-update for the former while requiring review for the latter. This requires the skill author to publish security updates in a separate channel from general updates, with clear labeling. It requires the runtime to know how to consume the security channel and apply security updates without other changes. It requires the team to trust the skill author's classification of which updates are security-only, which is a non-trivial trust ask. The pattern works when the surrounding ecosystem supports it, which requires real coordination between skill authors and platform operators.

The pragmatic compromise that most teams adopt today is auto-update with rollback capability. Updates are applied automatically, but the runtime keeps the previous approved version and can revert to it if the new version is found to misbehave. The rollback path is exercised regularly to ensure it works under stress. The detection of misbehavior is based on monitoring: anomalies in the runtime behavior of the updated skill trigger automatic rollback to the prior version, with operator notification. This is not as strong as full pin discipline (a malicious update can do damage in the window between deploy and rollback), but it is much stronger than auto-update without rollback (where the damage continues until manual intervention).

The choice between these patterns depends on the team's threat model, the skill's risk profile, and the operational tempo. For high-risk skills in environments where the consequences of compromise are severe, full pin discipline with manual updates is the right answer, accepting the slower patching as the cost of stronger control. For lower-risk skills where the consequences of compromise are bounded, selective auto-update or auto-update-with-rollback can be acceptable. The decision should be made deliberately per skill, captured in the skill's pin policy record, and revisited periodically as the threat landscape evolves.

The Skill Version Pin Policy

The artifact this post promised is the Skill Version Pin Policy, the document that codifies your team's approach to skill versions across the fleet. The policy is short (typically two or three pages) and is referenced by every skill registration. It establishes the defaults, the categories, the review processes, and the operational expectations that govern how versions are managed across the fleet.

Section one of the policy establishes the default. The default for any skill in the fleet is exact-version pinning: skills are referenced by (name, version, hash), the runtime enforces the pin, deviations from the pin are rejected. Auto-update is off by default and can only be turned on per skill with explicit documented rationale.

Section two of the policy establishes the categories. Skills are classified into risk tiers based on their action authority, data sensitivity, and trust profile. Each tier has a defined update review process: the high-risk tier requires full review per update, the medium tier allows expedited review for updates with no capability changes, the low tier allows light-touch review for updates from established authors. The categorization is captured at registration and revisited annually.

Section three of the policy establishes the trust window durations. Each tier has a defined trust window: high-risk skills have a 90-day window, medium-risk a 180-day window, low-risk a 365-day window. Approvals expire automatically at the end of the window, requiring re-review even if no new version has been published. The runtime enforces the expiration by refusing to load expired approvals.

Section four of the policy establishes the update review process. The four-dimension diff is required for every update review. The diff outputs are compared against the original approval. Updates that introduce new capabilities require the same conversation pattern and 24-hour cooling-off as new imports. Updates that introduce no new capabilities can move through expedited review with documented rationale.

Section five of the policy establishes the operational responses. When a skill is found to be running an unapproved version, the runtime refuses the load and surfaces an alert. When a skill's approval expires, the runtime refuses subsequent loads and surfaces an alert. When a skill is found to be exhibiting drift patterns (new capabilities, new destinations, new identities), the runtime alerts the operations team for investigation. The alerts have defined response paths and named owners.

Section six of the policy establishes the exceptions. Genuine emergencies (urgent security patches that must deploy faster than review allows) can override the policy through a documented exception process with senior approval. Exceptions are tracked and reviewed quarterly to ensure they remain rare. Frequent exceptions indicate that the policy thresholds are misaligned with operational reality, which is a signal to revisit the policy itself.

The policy fits on a few pages, is signed by the security and engineering leads, and is referenced by every skill registration. The discipline of having an explicit policy beats the alternative of having implicit norms that drift over time and that no one can articulate when asked. The policy is the answer to the question "how do you handle skill updates," and the answer should be specific, repeatable, and defensible.

Counter-Argument: This Will Stop Us Patching Vulnerabilities Quickly

The sharpest counter-argument is that strict pin discipline will slow down vulnerability patching, leaving the fleet exposed to known issues for longer than necessary. The argument is that the time spent on update review is time during which a known vulnerability is present in production, and that the security cost of slow patching outweighs the security benefit of pin discipline.

The argument has real weight, but it is overstated. The first observation is that most updates are not security patches. The fraction of updates that address known vulnerabilities is typically small, with the rest being feature additions, bug fixes, and refactoring. Pin discipline applies the friction primarily to the non-security updates, where the friction is well-spent. Security updates can flow through expedited paths (selective auto-update, fast-track review, exception processes) that preserve the speed where speed matters and add friction where friction matters.

The second observation is that the relevant comparison is not pin discipline versus zero friction. It is pin discipline versus the alternative attack vectors that pin discipline closes. A team without pin discipline is faster on patching but is also exposed to the dependency drift attack vector, which is much harder to detect or recover from. The integrated security posture, accounting for both vulnerability windows and drift attack vectors, is usually better with pin discipline than without.

The third observation is that pin discipline forces the security organization to be honest about its update review capacity. If the review capacity is inadequate to keep up with the rate of legitimate updates, then the policy will produce visible backlog that demands attention, which leads to investment in tooling, in staffing, or in tier reclassification. This is a healthier dynamic than the alternative, where the inadequacy of review capacity is hidden by the absence of any review at all, and the backlog manifests not as visible queue but as silent exposure to drift attacks.

The fourth observation is that the worst-case scenario for pin discipline (a critical vulnerability that needs urgent patching but is held up in review) is exactly what the exception process is for. Genuine emergencies override the policy, with senior approval and documented rationale. The exception process exists for the cases where the cost-benefit of urgent action favors the quick patch. The discipline of having to invoke the exception process, with the documentation it requires, ensures that the urgency is real rather than imagined.

What Armalo Does

Armalo's skill registry treats version as a first-class element of identity. Every skill registration is for a specific (name, version, hash) tuple. The Trust Window framework is built into the certification flow: certifications expire on a tier-dependent schedule, and the runtime refuses to load expired certifications. Updates to certified skills go through update review with the four-dimension diff applied to the version difference. The behavioral pacts that govern skill behavior reference the version pin: a pact violation can be traced to the exact version of the skill that caused it. The composite score that drives certification tier includes pin discipline as a measured dimension; skills with strong pin policies, clear update communication, and consistent provenance across versions score higher. The Trust Oracle at /api/v1/trust/ exposes the current approved version set, the trust window status, and the version history, so any consumer can verify that the version they are running is the version they think they are running.

FAQ

Should I pin transitive dependencies as well as direct ones? Yes. The dependency drift pattern operates at the transitive level just as much as at the direct level, and many of the highest-impact supply chain incidents in conventional software have been transitive. Modern lockfiles produce full transitive dependency trees that you can pin and verify; the discipline is the same as for direct dependencies, just applied to a broader surface.

What happens if my skill author publishes urgent security patches that I want to take quickly? That is what the exception process is for. The pin discipline does not mean updates are impossible; it means updates are deliberate. An urgent security patch can be reviewed and approved in hours rather than days through the exception process, with documented rationale and senior approval. The discipline of the exception process ensures that you are deliberately deciding to fast-track an update, rather than absent-mindedly accepting whatever shows up.

Is the Trust Window framework specific to agent skills, or does it apply to other dependencies? The framework is most acute for agent skills because of how directly skills affect the agent's authority, but the principles apply to any dependency where the trust profile changes meaningfully across versions. We recommend applying it most strictly to skills, with looser variants for other dependencies (libraries, container base images, infrastructure components) calibrated to the trust profile of each.

How do I handle skills whose authors do not publish version metadata reliably? You stop using those skills. Skills that cannot be pinned and verified across versions cannot participate in pin discipline, and the alternative of running them without pin discipline is worse than not running them at all. The agent skill ecosystem is broad enough that there are usually alternatives; if a specific capability is only available from skills with poor versioning practices, the right move is to build the capability in-house with the version discipline you control.

Can pin discipline apply to LLM models too, since those are also dependencies? Yes, with adaptations. Models change behaviorally with versions, sometimes in ways that affect agent reliability and security. Pinning to specific model versions, reviewing model updates before adoption, and maintaining trust windows on model approvals are all appropriate disciplines. The challenge is that model providers do not always publish version-stable APIs, so the implementation can be more complex than for code-level dependencies.

What is the right cadence for trust window expiration? It depends on tier. We use 90 days for high-risk skills, 180 days for medium-risk, 365 days for low-risk. Other reasonable schedules exist; the principle is that no approval is permanent, and that re-review happens at intervals calibrated to the consequences of trust being misplaced. Quarterly is the most aggressive that is operationally sustainable for most teams; annual is the most relaxed that still meaningfully closes the drift attack vector.

Doesn't this create a lot of work for the security team? Initially, yes. The first quarter or two of pin discipline produces visible workload that did not exist before. The workload tapers as the team gets faster at update review and as the fleet stabilizes around well-understood skills. The steady state is a few hours per week of update review for a medium-sized fleet, which is well within the cost-benefit envelope for a security organization, and is much less than the cost of incidents the discipline prevents.

What if a skill author refuses to support pin discipline? Then the skill is not a fit for your fleet. There is enough choice in the skill ecosystem that you can find alternatives, and the operational discipline of refusing to use skills whose authors cannot work within your version policies is itself a market signal that pushes the ecosystem toward better practices. The teams that hold this line consistently end up with better-curated fleets and better-aligned skill authors as collaborators.

Bottom Line

Dependency drift is the agent supply chain attack vector that exploits the gap between how teams reason about trust (in general terms, by name) and how skills actually exist in production (in specific versions, with specific behaviors). The Trust Window framework closes the gap by tying every approval to a specific version and a specific time bound. The Skill Version Pin Policy turns the framework into operational practice. The architectural primitives (pinned manifests, version-aware runtimes, deny-by-default, tamper-evident records) make the practice enforceable. The cost is real: more update review, slower patching for non-security changes, occasional friction when an urgent update meets a deliberate process. The benefit is the elimination of an attack vector that is otherwise nearly impossible to defend against, and that is going to grow rapidly as the agent skill ecosystem becomes a target worth attacking. Pin discipline is the conventional supply chain wisdom your industry already knows, applied to the new substrate where you have not yet applied it. Adopt it before the incident that forces you to.