Lesson 1 of 8 · 5 min read
How LLM Applications Work
In this lesson
TL;DR: An LLM application selects context, invokes a model and uses the result in other systems. Review who can supply each input, which data the processor may receive, and what readers or operations the output can reach. Include stored history and provider-managed state in that map.
Before you read
Pick an answer before you read further. The lesson below explains it, and guessing first, right or wrong, helps the explanation stay with you.
1A booking assistant recalls yesterday’s conversation after a fresh API request. Does this prove its model weights changed?
What you should be able to do
Draw a request from authenticated user to actual recipient. Distinguish a model generation from an application action, identify where context comes from, and explain why a remembered conversation does not establish that model weights changed. Use this map before choosing an injection filter or evaluating a model.
Follow a concrete request
In this original fictional example, a community makerspace offers a booking assistant. A member can ask about their own workshop booking and read public equipment manuals. Staff-only maintenance notes must remain unavailable to members. Members may write booking comments, so some text the assistant reads has an author who is not trusted to change application rules.
A request crosses several services. The application authenticates the member, resolves the current task, loads permitted booking information and selects relevant manual passages. It sends the allowed context to an approved model service. The response may be displayed, saved as a draft or interpreted as a proposed scheduling operation.
The language model is one component in that path. A text-generating model produces outputs conditioned on its parameters and supplied input. Multimodal models may also process images, audio or other supported representations. Neither description tells you which database credentials, renderer capabilities or tool permissions surround the model.
Request identity
Authenticated member and current task
Context assembly
Permitted records and attributed sources
Model service
Returns content or proposed actions
Application effects
Actual readers, tools and saved state
Decide what may be read
The assembly service checks the member, task and source permissions before supplying private records to the approved processor. A model instruction cannot undo an unauthorized read.
The security review therefore cannot stop at the visible chat box. A private record might enter context before the final answer, a saved draft might have a wider audience, or a queued operation might finish after the response. Name the actual observation and enforcement points.
Inspect context assembly as a data-access operation
A typical context can contain application instructions, the current message, selected history, retrieved records, tool definitions and tool results. Those sources do not have equal provenance or permission. A public manual is useful task data; its author cannot grant access to a staff note.
For each source, record its author, audience, selection rule and relevant version. Obtain identity and resource permissions from trusted application state. Do not accept a member identifier in model-generated text as proof of whose booking is being accessed.
Retrieval relevance is a separate question from access. A staff note may be the closest semantic match and still be ineligible for this member’s task. Check eligibility before including it in the allowed context. If the model service is a separate processor, review whether sending the data there is itself permitted; a later output filter does not reverse that disclosure.
History needs the same attention. A message marked as an earlier assistant reply may contain a wrong claim or a summary of member-authored text. Its role does not establish truth, current permission or approval. Preserve the source facts needed to interpret it rather than allowing a summary to become an unexplained instruction.
Distinguish the kinds of memory
A running product can remember information in several ways: an application database, a provider conversation object, retrieved documents, a generated file or other retained state. The current inference uses whichever of those records the integration supplies or makes available. It is misleading to describe every API as stateless or every remembered fact as training.
- 1
1 · Trained parameters
What the model learned before this inference
- Ordinary inference uses the current parameters; it does not itself retrain them.
- Later training or adaptation is a separate data lifecycle to review.
- 2
2 · Current model input
Selected messages and other supported inputs
- The application or service supplies the context used for this generation.
- Compaction, selection and truncation can change what is supplied.
- 3
3 · Persistent state
History, files, caches and provider objects
- A new request can reconstruct context from stored records.
- Access, retention and reuse rules belong to the actual stores.
Identify the memory mechanism
A later answer can recall a booking because the application retrieved history or the provider retained conversation items. That does not demonstrate that the model weights learned the booking.
Ordinary generation does not itself update trained parameters. That statement says nothing about separate logging, later training, explicit fine-tuning or adaptation features. Conversely, deleting one stored conversation is not a general method for removing information that was used in training. Those are different assets and workflows.
A dated provider example makes the distinction concrete. OpenAI’s conversation-state guide, checked November 2026, documents both manually supplied history and API-managed continuation or persistent conversation objects. The design question is which mechanism this application uses and who can access its objects. No provider account is needed for this lesson’s exercises.
Inspect every output destination
The same generated string has different consequences depending on its consumer. Rendering it as plain text, interpreting it as markup, storing it as a shared note and using it as a tool argument are different operations.
| Destination | Review question for the makerspace |
|---|---|
| Member response | Does the content fit this reader’s permissions, and does the renderer constrain active or remote content? |
| Scheduling handler | Does the service independently check the authenticated member, target booking and allowed change? |
| Saved draft | Who can read the saved revision, including previews and history? |
| Later model context | Does the stored text retain provenance and remain task data rather than acquiring authority? |
| Logs and evaluation records | Is each retained field necessary, protected and available only to the intended reviewers? |
A syntactically valid tool request is still a proposal. The execution service must decide whether it may run. A model statement that a booking changed is not evidence of completion; use the service outcome and retain an unresolved state when observation is missing. For provider-hosted tools, locate the equivalent controls in that service rather than assuming your application receives a callback for every operation.
Review a changed design
The team adds a “continue last conversation” feature. A member supplies a saved conversation identifier and the application loads its contents with a broad service credential. The model receives the right role labels and produces a fluent answer.
What must be checked first? The application must establish that the current member and task may access that conversation and its included records. Guess-resistant identifiers, correct role formatting and a polite answer do not establish that permission. If access has changed since the conversation was saved, the design needs an explicit reuse rule rather than automatically restoring old authority.
Next, trace derived copies: a summary, draft or cached response may have its own reader policy. This is an application-state review, not a test of whether the model remembers well. The authorization guidance from OWASP provides the underlying principle of checking permission at the resource boundary.
Check your map
Draw the fictional request with the member, booking service, manual store, context assembler, model processor and response recipient. Add one saved conversation and one scheduling operation. Mark who controls each input and where permission is enforced.
Now remove scheduling tools. Identify what risk disappears and what remains. A sound answer removes that execution path while retaining possible disclosure through responses, saved drafts, history and rendering. “No tools” describes one capability choice; it is not a complete security result.
Use context windows and chat templates to inspect the input representation, tool calling to trace execution, and RAG security for retrieval-specific boundaries. The evaluation course turns a chosen requirement into observable evidence.
Key takeaways
- Context selection is a data-access decision with source and processor permissions.
- Model parameters, current input and persistent application state have different lifecycles.
- Review the actual consumer of each generated output.
- Trusted identity, resource permissions and effect receipts come from application services.
Check yourself
Say or write your answer first, then reveal. Explaining it from memory, in your own words, is the skill an interviewer is checking.
1A member’s task retrieves a staff-only maintenance note because it is the closest match. Where should the first prevention check occur?
2A saved draft is visible to members even though the final response hides staff details. Which path belongs in the review?
3The team removes all scheduling tools. Which parts of your security map remain?