Why RAG, LoRA and MCP are not the right approach for organizations

Retrieval-augmented generation, low-rank adaptation, and the Model Context Protocol solve real problems well. Our objection is not to any of them individually — it is to treating them as sufficient architecture for a system that has to make organizational decisions, because each one, used as the whole design, dissolves a boundary that governance depends on.

RAG concatenates a retrieved passage into the prompt, where it becomes indistinguishable from instruction. The model cannot tell evidence from injected text once both are just tokens in a window, which is the root cause of indirect prompt injection. Our position, worked out in the fourth paper of this series, is that a retrieved item should arrive as a *proposal* — attributed, provenanced, and subject to the same promotion gate as anything else a system asserts — rather than as text quietly spliced into context. The fix costs almost nothing and changes what the retrieved passage is allowed to become.

LoRA and other lightweight fine-tuning methods adapt a model's weights to a domain, and in doing so they move a decision *into* the model — which means the decision stops being visible, replayable, or attributable to a specific policy. A fine-tuned model that has learned "always approve requests like this" cannot be asked why on any specific instance; the answer is baked into a weight matrix, not written anywhere a person or an audit can read. Our engine's determinism proof depends on the gate — not the model — being the place authority is decided, and a system that lets adaptation quietly absorb policy has moved the decision out of the part of the system that can explain it.

MCP standardizes how a model calls tools, and a tool call is exactly the place where "the model suggested it" and "the organization did it" get confused. A well-designed protocol for invoking a tool says nothing, by itself, about whether that invocation should have been *permitted* — that is a separate question, answered by a policy evaluating a proposal, not by the protocol that carried the request. Used as if it were the whole architecture, a tool-calling layer becomes the place unauthorized actions happen fluently.

The common failure is the same in all three: each pattern is excellent at getting information or capability *into* a model's working context, and none of them was designed to answer *who is allowed to act on this, and how would we know if they shouldn't have*. That is a governance question, and it needs a governance answer — a gate the model cannot bypass, sitting outside the model rather than folded into it.