This week the embargoed Black Hat USA 2026 material stopped being a hallway rumor and became operational triage. Researcher write-ups, slides, and vendor advisories on Model Context Protocol tool poisoning and rug-pull tool-server swaps are moving through platform and security channels. A connected tool can change what a production LLM application does with zero commit in the customer's repo.
Most coverage will treat this as an MCP CVE story. Pin versions. Patch the server. Add allowlists. Necessary work. Not the control. A patched tool can be legitimately updated tomorrow and change side effects, data flows, or permissions without touching application source. Release governance still equates "no diff" with "no change." That equation is now false.
Your Git history is a partial ledger
You signed off on a conversational product. The merge was clean. CODEOWNERS signed. The model card is still current. Prompt files have not moved. None of that describes the capability graph.
The capability graph is the live set of what the system can reach: which tools it can call, which data those tools can see, which side effects they can trigger, and which vendor defaults sit between your prompt and the action. MCP made that graph a runtime object, not a compile-time one. Git records the application. It does not record the tool server's current description, the model's latest default tool-use policy, or a vendor's silent change to a hosted connector.
Rug-pull write-ups from this cycle make the split concrete. Approval is granted against a tool schema at time T. At time T+1 the same endpoint, name, and version pin serve a different description or a different implementation. Your repo is quiet. Production is not. The merge that never happened still shipped.
npm, PyPI, and container registries already taught us remote artifacts can move under a tag. The new problem is the artifact: a permissioned action surface inside a conversational product, while change control still treats a missing pull request as evidence of runtime integrity.
Scanners are looking at the wrong artifact
If you are scoring vendors this week, watch what they certify. Prompt files. Golden datasets. Repo diffs. Model cards. Those are source artifacts. They answer "did we scan the prompt files?" They do not answer the buyer's question: who owns independent evidence of observed runtime behavior across models, tools, and vendor defaults after the repo went quiet?
A pin is a wish. An allowlist is a wish with a ticket. Neither is evidence that the live capability graph matches last quarter's risk review.
Three contradictions belong on the risk register now:
- Change control is git-shaped. If it does not produce a diff, it is not treated as a release. MCP tool servers, hosted connectors, and model-provider defaults change behavior without a diff.
- Assurance is pre-merge. You gate on what developers submit. Drift happens after merge, continuously, often outside your organization.
- Ownership is split. Application owners own the repo. Security owns CVEs. Platform owns the MCP client. Nobody owns observed behavior of the composed system once all three go quiet.
We argued in 5 Reasons Why AI Agents Fail (And How to Prevent Them) that production failure is often a composition problem, not a single-model defect. The failure is not that a model said something odd. The failure is that the graph of what it could do moved, and your evidence pipeline never looked at the graph.
The Secret Shopper Methodology for AI Testing looks at the product as a customer sees it. Capability-graph drift looks at the product as production actually is after everyone stopped looking.
What most people will get wrong before September
By next month this will be digested into generic MCP hygiene roundups. Three wrong answers will fill the gap.
"We don't use MCP." GitHub, VS Code, Slack, and a long tail of SaaS connectors already expose tool surfaces into LLM applications. If a knowledge worker can attach a server, you have a capability graph you did not inventory. Scope is whether a model can invoke a remote action missing from the last signed-off threat model.
"We pinned and patched, so we are done." Pinning is correct and perishable. A legitimate vendor update, a rotated hosted endpoint, a model-provider change to tool-calling defaults, or a new OAuth scope can move side effects without a CVE and without your patch ticket. The disclosure is a CVE this week. The standing problem is ungoverned legitimate change.
"We'll add it to the SBOM." SBOMs describe packages. They do not describe live tool descriptions, runtime permission grants, or data flows that appear only when a model calls a tool. You can have a complete SBOM and an incomplete capability graph. If your vendor conversation still certifies prompts and diffs, you are buying a photograph of the repo. You need a photograph of production.
Change the questions, not the policy PDF
Do not wait for a new standard. Put four questions in the next review cycle.
What is in the capability graph, named, not implied? Inventory every model, connected tool, vendor default that can alter tool use, and permission those tools hold.
What is allowed to change without a human-visible release? Remote schemas, hosted connectors, model defaults, and plugin marketplaces need an explicit answer: freeze, notify, or treat as a production change. "It was a vendor patch" is not a control.
Who produces independent evidence of observed behavior when Git is silent? Not the model vendor, the tool vendor, or the prompt owners. Evidence that the live system still matches the signed-off graph has to come from a party that is not the thing being observed, on a cadence that does not wait for a commit.
What is the freeze trigger? If observed behavior diverges from the last approved graph (new tool, new side effect, new data class, new permission), that is a release event. Stop promotion. Reopen the risk file. Silence in Git is not a freeze. Divergence in behavior is a thaw you did not authorize.
Velocity moved the work into systems Git never owned, and the control plane did not follow. GitHub Actions became invisible infrastructure. Model defaults became invisible infrastructure. MCP servers are now invisible infrastructure. Invisible infrastructure does not appear in the diff. It still ships.
Own the no-diff release
Name the problem class internally: capability-graph drift, or the no-diff release. If a platform cannot surface behavioral change when nothing merged, it is measuring the wrong artifact. That is a procurement filter, not a slogan.
UndercoverAgent exists to hold independent evidence of observed runtime behavior after the repo goes quiet. Use that record, or an equivalent from someone else; Git is not a proxy for production.
Ask your vendor, this week, one question: show us the last time production behavior changed and Git did not. If they cannot produce that record, you do not have runtime integrity. You have a green history.