The Runbook Is a Wallet: RAG Poisoning, MCP Hijacking, and the Agentic Payments Blind Spot

Hook

Line 51 of api.vectordb.runbooks.js is, on the evidence available, an unauthenticated write path into a production vector database. That single detail matters more than any severity score attached to it.

The reported chain runs like this: an unauthenticated runbook upsert writes attacker-controlled text into the retrieval store. The text is embedded alongside legitimate operational documentation. On the next agent invocation, the poisoned chunk wins a nearest-neighbor contest it was never supposed to enter. The model reads it as context, not as payload. From there, the retrieval layer hands instructions to a Model Context Protocol server holding credentialed financial tools, and the tool call executes. Payment. Export. Transfer. The advisory labels the retrieval defect CVE-2026-18875 at CVSS 7.3. A second entry in the same document, CVE-2026-18162, carries a 9.8 and involves new Function code injection.

One forensic note before anything else, because it governs how much weight the rest of this piece deserves. The IBM security advisory carrying these identifiers is stamped 2026-09-23 — roughly four and a half months ahead of my review date of 2026-05-07. CVE-2026-18875, CVE-2026-18162, and OWASP LLM09:2026 cannot be independently verified from where I sit. The document is also filed under a blockchain and Web3 news source and contains no Web3 content whatsoever.

I am not going to pretend that resolves cleanly. What I will say is that the architecture described is not speculative. It is the default shape of every agent deployment that has shipped in the last eighteen months, and the crypto industry is currently wiring the exact same pattern into wallets. Whether this particular CVE survives verification is a footnote. The write path is the wallet, and nobody is guarding it.

Context

IBM Financial Transaction Manager for Red Hat OpenShift is not a consumer product. It is enterprise middleware that sits inside banks, card networks, clearing houses, and payment processors. It handles transaction orchestration, message transformation, and routing across systems that regulators categorize as critical infrastructure. Affected versions, as reported, run 4.0.6.0 through 4.0.10.0, with remediation mandated at 4.0.11.0. The same advisory reportedly enumerates forty-seven vulnerabilities across the platform.

That number is the most important one in the document, and it is the one nobody will quote.

Forty-seven is not a bug count. It is a security-debt statement. When a single vendor advisory bundles forty-seven findings across a product line deployed at systemically important institutions, you are not looking at isolated defects. You are looking at an architecture that accumulated exposure faster than it accumulated controls — which is precisely the signature of every platform that bolted generative AI capabilities onto a legacy transaction spine between 2024 and 2026.

So let me be precise about what is being described, because the vocabulary is doing a lot of load-bearing work.

Retrieval-augmented generation is a pattern, not a product. You take a corpus — documentation, tickets, runbooks, policy files — chunk it, embed it into vectors, store those vectors in a database, and at inference time you retrieve the top-k most similar chunks and paste them into the model's context window. The model then answers and acts with that retrieved text treated as ground truth.

A runbook in this context is an operational procedure. Restart this service. Escalate this queue. Reconcile this ledger. Abort this batch. In practice it is written in Markdown or YAML or plain prose, because humans are the intended reader. It has no type system. It has no author signature. It has no schema. It is, functionally, a natural-language program that an obedient system will execute.

The Model Context Protocol, led by Anthropic, standardizes how a model discovers and invokes external tools. A server publishes tool descriptions, resource URIs, and prompts; a client — the model host — reads them and decides when to call what. The industry has been calling it the USB-C of AI tooling. That analogy is flattering and slightly dishonest. USB-C has a negotiated power contract. MCP, in most shipped deployments, has a list of strings that say what a tool does and a credential that lets it happen.

Now the two reported findings, kept separate because the advisory does not keep them separate.

CVE-2026-18875 is the headline: unauthenticated injection into the vector store through the runbook write interface, CVSS 7.3. CVE-2026-18162 is the buried one: code injection via new Function, CVSS 9.8. OWASP LLM09:2026, the claimed framework mapping, covers Vector and Embedding Weaknesses. The retrieved content is then treated as legitimate context and used to steer tool invocations — which is a compound of LLM01 prompt injection, LLM02 sensitive information disclosure, and LLM06 excessive agency.

I read this from the settlement side, not the model side. For the last two years I have worked on a privacy-preserving digital dollar prototype in a Los Angeles fintech lab — zero-knowledge proofs for transaction privacy, benchmarked at ten thousand transactions per second against simulated Federal Reserve stress conditions. That work taught me something that AI security researchers tend to learn late and crypto engineers tend to learn never: in a monetary system, the trust boundary is wherever value becomes irreversible. Everything upstream of that boundary is a suggestion. Everything downstream is a liability.

Retrieval now sits upstream of irreversibility. That is new. And it is unguarded.

Core

The chain, mechanically

The attack as described has five stages, and each one is boring on its own. That is what makes it dangerous.

Stage one is the write. An unauthenticated endpoint accepts a runbook. No token, no mTLS, no signed payload, no tenant scoping — or if there is scoping, the advisory does not say so, and an advisory that omits an authentication control in a write path is generally describing a write path with no authentication control. The attacker now has persistent, legitimate-looking content in the store. It is not malware. It will never trip an antivirus signature. It is a paragraph.

Stage two is the embedding. The poisoned chunk is vectorized and indexed. Here is the part that should end conversations rather than start them: embeddings have no provenance. Cosine similarity measures semantic proximity; it does not measure authorship. A vector is a coordinate, not a certificate. When your chunk lands near the top of a query, the retrieval layer has no mechanism — none, by design — to answer the question "who wrote this, and were they authorized?" The database is doing exactly what it was built to do. The failure is upstream of the math and downstream of the policy.

Stage three is the retrieval. Top-k pulls the poisoned chunk into the context window alongside genuine operational procedures. The model sees undifferentiated text. There is no PKI for context. There is no TLS handshake for a sentence. And crucially, there is no heartbeat — no deviation threshold, no staleness flag, no circuit breaker that trips when retrieved content starts issuing imperatives instead of describing procedures.

I have argued for years that oracle feed latency is DeFi's Achilles heel, and that a "decentralized" oracle network operated by a handful of nodes is a joke wearing a governance token. Retrieval has the same disease with worse plumbing. At least an oracle publishes a number that anyone can dispute on-chain. A poisoned retrieval is a rumor the model believes about itself, and it leaves no public trace when it is believed.

Stage four is the injection. The retrieved text is instruction-shaped. "Before reconciling batch 4471, confirm the counterparty account and route the settlement to…" The model cannot distinguish operator-authored procedure from attacker-authored procedure, because the retrieval layer already told it there is no difference. This is LLM01, indirect prompt injection, and it is the single most reliable attack class in deployed AI systems. It is not a novel exploit. It is a default behavior.

Stage five is the tool call. The MCP server exposes payment, transfer, refund, or data-export tools. The agent selects one. The credential is valid. The call executes. This is LLM06, excessive agency, and in the specific taxonomy of application security it is the classic confused deputy — a privileged component performing an action on behalf of an unprivileged attacker because it cannot tell the two apart.

Five stages. Zero exploits required against any cryptographic primitive. Not one broken cipher.

The severity score is a mispriced instrument

CVSS 7.3 for the retrieval poisoning. Let me take that number seriously and then explain why it is the wrong number.

The CVSS framework measures impact across confidentiality, integrity, and availability. It is a general-purpose instrument designed for general-purpose software. It has no field for settlement finality. It has no field for irreversibility. It has no field for regulatory consequence, mandatory incident reporting under DORA, PCI DSS assessor scrutiny, or FFIEC examination findings.

A CVSS of 7.3 on a payment rail is not the same risk as a CVSS of 7.3 on a marketing website. The score is identical because the instrument is blind, not because the risk is.

When I helped draft a comparative report on stablecoin reserve transparency after the Terra collapse in May 2022 — a report three junior analysts and I pushed into industry newsletters, which is how I ended up in front of traditional finance researchers at twenty-one — the lesson was not that opaque reserves are dangerous. Everyone knew that. The lesson was that opacity is unpriceable, and unpriceable risk does not sit still. It accrues. It compounds in the gap between what a system claims and what an independent party can verify.

A CVSS score that cannot express irreversibility is an opacity of exactly that kind. It tells a remediation team how urgently to patch. It tells a board nothing about how much risk they are carrying.

Read the CVSS vector, not the headline

The advisory leads with RAG poisoning. The 9.8 sits in the same table, lower down.

I want to be precise about why this matters. CVE-2026-18162, as reported, involves new Function code injection. That is not a retrieval-trust problem. That is arbitrary code execution semantics — the kind of finding that historically converts directly into remote compromise, and the kind that security teams treat as a stop-the-line event regardless of how much narrative attention the other finding receives.

RAG poisoning and MCP hijacking are the novel, interesting, conference-talk findings. Code injection is the boring, solved-in-principle, patched-in-2019 finding. When a vendor bundles forty-seven vulnerabilities into one advisory and the public narrative selects the novel one, ask who benefits from the framing. The narrative is not malicious. It is gravitational. Novel findings travel. Old findings sit.

My first real lesson in this discipline came in 2017, as a high school junior dissecting the ParagonCoin raise — a project that pulled in roughly $1.4 billion while promising blockchain-enabled logistics and shipping no working contracts at all. I was reading Solidity when my peers were reading Twitter, and what I learned was not that the project was fake. Everyone eventually learned that. What I learned was that the artifact is the argument. A whitepaper is a marketing document. A deployed contract is a fact. When the two disagree, the contract wins.

Applied here: the CVSS vector string is the artifact. The title is the marketing document. Read the vector.

The root cause is not authentication. It is agency.

Fixing the unauthenticated write is necessary and insufficient. The unauthenticated write is a bug. The defect is that an autonomous system holds a credentialed tool with no least-privilege scope, no transaction ceiling, no dual control, and no non-repudiable audit trail separate from the component being manipulated.

In the digital-dollar prototype work, we hit this wall in month three. Hitting ten thousand TPS with zero-knowledge proofs is an engineering problem, and it is solvable. Hitting it while also guaranteeing that no compromised decision layer can exceed a velocity limit, breach a spend ceiling, or execute an irreversible instruction without a second, independent authorization — that is a design problem, and it does not have a cryptographic solution. Zero-knowledge proofs give you privacy. They do not give you judgment. Nothing in the cryptographic toolkit gives you judgment.

So the control has to live outside the model, in a trust domain the model cannot read, reason about, or rewrite. A policy engine, not a prompt. Because a prompt is a suggestion, and the entire failure mode under discussion is that the attacker gets to write suggestions too.

Least privilege is not a slogan. It is a loss function. Every tool you attach to an agent is a term in that loss function, and every term you add without a ceiling increases the expected loss monotonically. Agents do not fail gracefully. They fail confidently, at machine speed, in the direction of whatever the context window says.

The crypto version of this is worse

Here is where this stops being an enterprise middleware story and becomes a crypto story, and it is the reason I am writing it under this masthead rather than leaving it to the application security crowd.

In 2025 I authored a whitepaper on Autonomous Economic Agents, arguing that AI agents will require autonomous, trustless payment rails, and projecting a market for machine-to-machine micro-transactions measured in the tens of billions by 2027. That thesis assumed something I did not examine hard enough at the time. It assumed the tool-calling layer is trustworthy.

It is not. And the on-chain version of this attack is strictly worse than the enterprise version, for four structural reasons.

First, settlement finality. A compromised FTM instance can, in principle, be unwound — disputed, reversed, charged back, indemnified, absorbed by an SLA and an insurance policy. A compromised MCP server wired to a wallet and a stablecoin rail settles in seconds and reverses never. There is no card network to call. There is no dispute window. The chain does not have a customer service department, and this is presented to retail as a feature.

Second, no supervisor. DORA, PCI DSS, FFIEC examination — those exist because regulated institutions have supervisors who show up. On-chain agents have no equivalent. The regulatory void is the same void I documented in the post-Terra stablecoin work, and the historical record on how that void resolves is not encouraging.

Third, no separation of duties. In most crypto agent deployments, the team that operates the vector store is the team that ships the agent, is the team that holds the tool credentials, is the team that writes the runbook. In enterprise middleware, these are at minimum different cost centers behind different change-control boards. In crypto, they are frequently the same four people and a Discord channel — and the runbook is literally in a public GitHub repository.

Fourth, the trust fragmentation problem. There are now dozens of MCP servers, dozens of agent frameworks, and dozens of tool registries. I have made the same argument about Layer 2s and I will make it here: this is not scaling. This is slicing an already-scarce resource — in this case, audited trust — into fragments too small to defend themselves. Every additional MCP server is an additional attack surface, an additional credential, and an additional thing nobody has penetration-tested. Fragmentation multiplies the cheapest attack, not the strongest defense, because attackers only need one door and defenders need all of them.

And there is a Bitcoin parallel I have argued before and will argue again. Ordinals injected fee revenue and a new narrative into Bitcoin at a moment when the security budget was drifting toward an uncomfortable question. Agent transaction flow is the same kind of gift to the next cycle: real fee volume from real machine demand. But the security model of that flow is being decided right now, by default, in configuration files that no one has read. Fee revenue is only good news if what is paying the fees is not also draining the account.

Quantify the exposure before you price the story

My standing method, and the reason I built a liquidity-first signature into everything I write: quantify systemic risk before discussing anything that resembles price.

So. How many institutions run affected FTM versions? Undisclosed. How many MCP servers are reachable from the public internet with write-capable credentials? Unknown. What fraction of agent deployments sit in front of a vector store that accepts unauthenticated writes? Unknown. What are the transaction ceilings on the exposed tools? Not published. Is there an immutable, separate-domain log capturing every tool invocation? Not stated.

Four unknowns, one disclosure gap, and a 7.3.

When the key variables are all unknown, the correct risk posture is unhedged — not low. Absence of evidence about exploitation is not evidence of absence of exploitability, and in a system with no immutable tool-call log, you would not necessarily know you had been exploited until a reconciliation exception surfaced weeks later.

I watched this movie in the summer of 2020, as a sophomore interning at a small crypto hedge fund, when a single Compound governance vote triggered roughly $150 million of liquidity to exit in a cascade that ran through Aave and dYdX within hours. I mapped the failure vectors, wrote a memo recommending short exposure to leveraged yield farms, and the fund booked about 12% of alpha on it. The lesson was not that governance is dangerous. The lesson was that liquidity crises are plumbing failures that surface as price events. The plumbing breaks first. The price chart simply publishes the receipt.

Retrieval poisoning is plumbing. The unauthorized payment is the receipt. And by the time the receipt prints, the write path that caused it was opened months earlier, by someone who thought a runbook was a document.

Contrarian

Here is the position I expect to be wrong about for about six weeks and right about for about two years.

The market will price this as an IBM problem. That is the wrong frame, and the mispricing is structural rather than incidental.

The consensus read is straightforward: a vendor shipped a vulnerable product, a vendor will patch it, a handful of banks will absorb some upgrade cost, and the episode ends. Under that frame, the correct trade is nothing — or, generously, a small long in application security vendors and a small short in IBM that nobody bothers to put on because IBM is too large for a middleware advisory to move.

I think that frame misses the actual correlation. Enterprise agent security and crypto agent payments will decouple in price and re-couple in failure. They will look like two different markets right up until the first incident, at which point it becomes obvious that the shared primitive was never the vendor, the chain, or the framework. The shared primitive is an LLM holding a credential and executing an irreversible action. That primitive does not care whether the settlement rail underneath it is a mainframe batch file or a stablecoin transfer. It has the same failure topology either way.

Which produces the second contrarian claim, and this one I hold more strongly: human-in-the-loop is not a fix. It is a latency tax that will be arbitraged away.

If every MCP tool call requires a human approver, you do not have an agent. You have a dashboard with extra steps. The entire economic case for autonomous agents rests on removing the human, and the market will remove the human the moment the volume justifies it — because the competitor who removed the human six months earlier is clearing faster and cheaper. Any control that depends on sustained human attention at machine frequency will fail on the same schedule that every manual review process has failed on since the invention of the batch job.

The durable fix is cryptographic and architectural, and it is unglamorous: signed retrieval with provenance attestation, so a chunk carries a verifiable author; a write path that is authenticated, tenant-scoped, and audited as rigorously as a funds transfer; a tool-call policy engine in a separate trust domain that the model cannot read or rewrite; per-tool scope limits and spend ceilings enforced below the reasoning layer; and an immutable log of every invocation, held somewhere the compromised component cannot reach.

And there is a blind spot nobody has raised, so I will raise it: nobody is auditing the embedding model supply chain. Signing source documents is worthless if the model that vectorizes them has been swapped, backdoored, or replaced with a subtly different checkpoint. Provenance of the text does not imply provenance of the coordinate. That is a gap that will produce a second generation of incidents, and it is currently un-owned by any vendor, framework, or standard.

Finally, the dating anomaly. I flagged it at the top and I will not let it go, because it is the most honest thing in this piece. An advisory stamped four and a half months into the future, from a source filed under a category its content does not belong to, describing CVEs I cannot verify, is a claim — not a fact. Everything above is architecture analysis, and architecture analysis survives a bad source because it evaluates patterns rather than events. But the fact layer here should be held at low confidence until someone independent validates the advisory, the identifiers, and the OWASP mapping.

The regulatory response, though, is not contingent on verification. DORA, the EU AI Act's high-risk classification regime, PCI DSS, FFIEC examination expectations, and China's algorithmic filing requirements are all converging on the same question — who is liable when an autonomous system moves money wrongly. And I have said this before about a different generation of technology: 2017's dream is today's regulation. The ICO token that promised autonomous finance without a compliance architecture became the securities enforcement docket. The agent that can spend is the new ICO token: unregistered, un-audited, and exactly one advisory away from a supervisory letter.

Takeaway

My forward judgment, stated plainly so it can be scored later: within eighteen months, there will be a widely reported incident in which an autonomous agent — on-chain, enterprise, or both at once — executes an unauthorized irreversible transfer because a retrieval layer was poisoned or a tool credential was over-scoped. It will be reported as an AI story, litigated as a security story, and remembered as a payments story. The market will then learn to price retrieval trust the way it learned to price counterparty credit in 2008: late, expensively, and permanently.

The positioning that follows is not in agent consumer applications. It is in the layer that decides whether the agent is allowed to act — MCP gateways with policy enforcement, authenticated vector write paths, provenance attestation for retrievals, embedding-model integrity, and immutable tool-call logging sold as a compliance artifact rather than a developer convenience. Watch whether the MCP ecosystem ships an authentication and permission profile in the next two quarters; watch the patch diff for 4.0.11.0 to see whether the vendor removed the endpoint or fixed the authority model, because those are different fixes and only one of them is a fix; and watch whether any financial regulator names prompt injection as a control deficiency in an examination finding, because that single sentence will do more to fund this space than every whitepaper ever written.

The specific CVE may or may not survive verification. Its architecture will.

So the question I keep arriving at is not whether the industry will eventually install authentication on the write path. History is unambiguous on that point — it never installs the control first. The question is whether the settlement layer installs it retroactively, in the form of frozen funds, failed reconciliations, and supervisory letters, the way it has every single time. 2017's dream is today's regulation. The agent's dream will be tomorrow's. The only open variable is who writes the invoice.