Dependency Stewardship for agentic dependencies: the contract can change with no version bump (proposal + data)

[gautamgb]

I'd like to propose an extension to Dependency Management / Dependency Stewardship (4.5, 4.6), and I'm bringing measurement rather than opinion. Happy to draft it at whatever scope fits, or just leave this here as input.

The gap

Section 1.1 acknowledges generative AI as a code-creation force, but the framework doesn't yet address the other way AI enters a system: as a dependency. Agentic components - MCP servers are the concrete case, but any tool-calling integration qualifies - are dependencies in every sense Section 4.5 cares about. They differ from libraries in one respect that matters to the securable paradigm:

Their contract lives on someone else's server, so it can change with no version bump, no new artifact, and no checksum difference.

Section 4.5's Trustworthiness guidance (signed packages, checksums, trusted repositories) verifies the artifact you install. For an agentic tool, the artifact - if there is one at all - is a thin client. The behavior your merge review approved is described by a remote tool contract (names, descriptions, schemas, capabilities) that the provider can rewrite at any time. Pinning defends against drift that arrives through versions. This drift doesn't arrive through versions.

Section 2.1 lists the reasons a system declared secure today may be vulnerable tomorrow: a newly discovered exploit, a dependency update, a configuration change, a shift in the threat environment. All of those leave a trace somewhere you can see. Silent contract drift is a further cause that leaves no trace on your side of the boundary - which also makes it a direct violation of least astonishment (2.7): the tool no longer does what its reviewed description indicates.

This is measurable, and 4.6 predicts what the measurements show

I run a longitudinal panel across the public MCP registry ecosystem: roughly 19,000 distinct servers, 120 snapshots over ~89 days. What's striking is how closely the results track the stewardship questions 4.6 already asks, "re-asked against time":

• "Is this dependency acceptable today?" is not a stable answer. About 12% of servers change their registry descriptor (the machine-readable surface an integrator would have reviewed) within 30 days of first observation (95% CI 11.5-12.4%). By ~90 days it's about 19%.
• Analyzability - "has the dependency's scope grown beyond its recorded rationale?" Yes, and asymmetrically: among servers reporting tool counts, I observed 248 tool-addition events against 17 removals. Capability accretes silently.
• Authenticity and Integrity - "does the project still demonstrate trustworthy maintenance behavior?" That behavior turns out to be measurable and predictive: a server that drifted before has a 31% chance of drifting again in the next month, versus 4% for one with a stable history (a 7.1x lift). Drift is concentrated - three quarters of servers never changed in-window, while the top 10% of changers produced ~79% of all change events.
• Resilience - "is there a current answer, not a historical one, for what happens if the dependency is abandoned or unavailable?" 885 of the ~19,000 servers vanished from the registry at least once during the observation window.

The full measurement is written up and open: preprint "Registry Descriptions Go Stale Unevenly: An 89-Day Measurement of Model Context Protocol Drift, and Why Drift-Ranked Re-Auditing Under-Covers It" (arXiv:2608.00997; Zenodo concept DOI 10.5281/zenodo.21728369) with the panel dataset it reproduces from (10.5281/zenodo.21709945), both CC-BY. Earlier drift and source-liveness datasets: 10.5281/zenodo.21449149, 10.5281/zenodo.21501867.

What an extension might say

Nothing here needs new machinery. It's the existing stewardship lens applied to a dependency class the current text doesn't name:

1. At selection (4.5): capture the tool contract you evaluated - names, descriptions, schemas - into the dependency inventory alongside the documented rationale. For an agentic dependency, the contract is the artifact.
2. Over time (4.6): re-verify the live contract against the captured one as a standing stewardship question, on the same cadence as the others.
3. In merge reviews (5.2): divergence surfaces as advisory evidence for the humans reviewing, consistent with the advisory default (5.2.2). It's a securability signal, not a pipeline gate - I read 6.1 as a warning against exactly the gate-shaped version of this practice.
4. POLA (2.7) as the acceptance bar: an agentic dependency whose live behavior diverges from its reviewed description is astonishing by definition, whatever the content of the diff.

Scope and offer

I realize v1.1 is close and contributions are discussion-first right now. I'm glad to draft this as a subsection under 4.5/4.6, an appendix, or input to the coming SSEM Primer / practitioner guide - or treat it as v1.2 material. Entirely your call.

Disclosure: I founded mcpindex.ai, which operates in this space, and I contributed the tool-contract drift-verification pattern to the OWASP GenAI Data Security Best Practices v2 draft (currently in review). Nothing above depends on any product - the data is open and the proposal is about engineering discipline.

[Mayur021]

Good measurement, and the asymmetry is the part I would put in front of a reviewer: 248 tool additions against 17 removals means the common case is a dependency quietly gaining reach rather than losing it, which is the direction that matters for 4.6.

One thing worth naming in your stewardship recommendation, since it affects how much the re-verification buys. Comparing a live contract against the captured one detects that the description changed. It does not tell you whether the captured description was accurate when you accepted it. A tool can sit perfectly stable across all 120 of your snapshots and have understated its effects from day one, and that server never appears in your drift population at all.

So the captured contract is a baseline, not a ground truth, and the cadence check inherits whatever the original review got wrong. Not an argument against the proposal, it makes it stronger to say so, since it puts the weight on the selection review in 4.5 rather than assuming stewardship will catch what selection missed.

I have opened a separate thread on the runtime side of this, since the object there is the call rather than the dependency, and I did not want to hang it off yours.

[gautamgb]

You're right, and it's worth stating the boundary plainly - helps further sharpen the proposal. Comparing the live contract to the captured one detects change relative to acceptance. It says nothing about whether the description was accurate at acceptance. The measurement has the same blind spot: a server that understated its effects on day one and never touched its descriptor sits in the never-changed three quarters, and no number of snapshots will surface it.

Your point also has a size, and my data gives it: 75% of servers never changed in-window. For the majority population, the selection review in 4.5 is the entire defense - the stewardship cadence only adds protection for the quarter that moves. Which is why I'd land contract capture in 4.5 rather than 4.6: capture is the selection review committing to a record of what it actually evaluated, and every later re-verification inherits exactly what that review got right or wrong.

For what it's worth, in my own verification practice these ended up as separate legs for this reason - if a baseline fails its own acceptance check, later drift checks against it are inconclusive, not reassuring.

Read #22 before replying here - the split is the right one. Yours is whether the description was true. Mine is whether it stayed the description. They meet at the same object, the tool contract, which is maybe the strongest argument that 4.5/4.6 can carry agentic dependencies without a separate framework.