Context Construction for Foundation Models

Imagine two assistants receive the same question about a printer's speed. The first sees only the question. The second also sees the printer's technical specification sheet. Before reading on, decide which assistant is more likely to give a correct answer, and which is more likely to invent a number that sounds plausible.

This article follows three questions: what information the model is shown, where that information came from, and what the model is allowed to do after it reads it. Security concerns with foundation models do not come only from the model's wording. Each question points to a part of the context that a builder can choose deliberately.

A model needs two kinds of material to complete a task. The first is instructions, which describe how the task should be done. The second is context, which is the actual information needed to handle a particular request. For a given application, the instructions tend to be the same for every user and every question, while the context changes with each query. Context is where most of the variety, and most of the risk, lives.

When context is missing, the model is more likely to make mistakes and to produce confident statements that are not grounded in anything it was given. People behave the same way: someone asked a question without the relevant facts is more likely to guess wrongly. Careful context construction is therefore both a quality practice and a safety practice.

Retrieval-augmented generation, usually called RAG, uses a two-stage flow. A retriever searches a memory store and selects a small set of items that appear relevant to the query. Those items are placed into the model's input, and the model writes its response while reading them. The model does not have to memorize every fact in advance, and the store can be updated without retraining the model.

A useful way to think about RAG is as a method of building a different context for each query rather than reusing one large, fixed context everywhere. That design has a direct security benefit. Private data about one user can be retrieved only for queries that belong to that user, so it never enters the prompt for someone else's question.

RAG also has a history. An early system first pulled five Wikipedia pages most relevant to a question and then had a reader model generate an answer from them. The name retrieval-augmented generation was later introduced for a broader setting, one where the full body of knowledge is too large to place inside the model's input at once. In that setting, only the information the retriever judges most relevant is passed along.

The agentic pattern reaches the same goal of better context by a different route. Instead of retrieving from a fixed store, the model is allowed to call tools such as web search or news APIs to gather the information it needs. The model decides which tool to use, the tool returns results, and those results become part of the context the model uses to continue.

Tools do more than supply information. They are the means by which a model can act on the world, and this is what makes the pattern powerful. External tools can compensate for a model's shortcomings and widen what it can do, which is also why the agentic pattern is considered capable of automating many everyday tasks. The same reach that makes agents useful is what makes their security posture deserve close attention.

A common hope is that models with very long context windows will make retrieval unnecessary, since everything could simply be placed in the prompt. The source argues against that view on two grounds. First, however long a context window becomes, some applications will need more data than fits. The amount of available data keeps growing, and people add data far more often than they delete it.

Second, a model that accepts a long context does not necessarily use all of it well. The longer the input, the more likely the model is to focus on the wrong part. Every additional token also costs money and can add latency. RAG addresses this by letting the model see only the most relevant information for each query, which reduces the number of input tokens and can improve the quality of the answer at the same time.

The source points to practical testing of this behavior. It cites a 2024 writeup in which a practitioner tested a model on information embedded in long material about doctor visits. The lesson for security work is that a model's use of a long context should be tested, not assumed.

Two places deserve particular attention: what the model's output is allowed to trigger, and what tools the model can reach. One concrete risk named in the source is remote code execution. The source reports that such a risk was found in LangChain in 2023 and points to public GitHub issues describing it. The underlying danger is simple: if text produced by a model, or text that a model was influenced by, is passed to something that executes it as code, then the model's output can determine what runs on a machine.

The flowchart above is a general model of control flow, not a description of the specific LangChain issue. Its value is in the decision node. Whether the system displays a model's output or hands it to an interpreter is a choice the designer makes. That choice determines whether an unexpected output can cause an unexpected action.

Scoping means narrowing what enters the context for a query. The diagram compares a broadly loaded context with a narrowly scoped one. In the broad case, the model sees more information and more tools than the current query needs. In the scoped case, only the data that belongs to this user and the tools this task requires are present.

Narrowing the context does not only reduce risk. Because the model sees only the most relevant information, its answers can also become more accurate. Breadth is therefore a trade-off to design for, not a goal in itself.