Understanding Foundation Models, LLM Applications, Assistants, and Autonomous Agents

Hello, and welcome to the first lesson in AI/Agentic Security. This opening module establishes the vocabulary needed to analyze how an AI system actually operates before judging whether it is secure.

Terms such as LLM, assistant, and agent are often used interchangeably in product descriptions. For security work, that is not precise enough. A reusable model, an application built around that model, a user-facing assistant, and an autonomous agent are related concepts—but they refer to different layers of a system and imply very different risks.

By the end of this lesson, you will be able to distinguish all four and describe what the distinction means for security review.

---

Start with the layers, not the labels

A useful first principle is:

A foundation model is a trained capability. An LLM application is software that uses that capability. An assistant describes a user-facing support role. An autonomous agent describes delegated decision-making and action authority.

These categories overlap rather than forming a strict ladder. One deployed system might simultaneously be:

• an LLM application, because it combines an LLM with prompts, code, and a user interface;
• an assistant, because it helps a person perform work interactively;
• an agent, because it can select tools and complete steps toward a goal; and
• only partly autonomous, because a human must approve consequential actions.

Conversely, a foundation model by itself is none of those deployed systems. It is the computational component they may use.

A foundation model is a large model trained on very large and varied datasets. During training, it learns statistical patterns useful across many future tasks. It can then be adapted through prompting, fine-tuning, retrieval, or other application-layer techniques.

An LLM, or large language model, is a foundation model focused principally on language: it accepts and produces text, although modern systems may also accept other forms of input. The important relation is:

$$\text{LLM}\subseteq \text{foundation model}$$

Not every foundation model is an LLM. A model designed to understand images, generate video, or process speech may be a foundation model without being primarily a language model.

For security purposes, a foundation model has no inherent access to your files, customer database, email account, or payment system. Those capabilities arise only when an application gives it access through surrounding software and credentials. This distinction is central: a model can generate risky suggestions, but an application can expose data or carry out an action.

---

From model to LLM application

An LLM application is the software system built around a model to accomplish a particular user or business purpose. The model is one component; the application supplies the rest of the operational context.

At its smallest, an LLM application combines:

1. a user input or other trigger;
2. instructions, usually a prompt;
3. a call to a model; and
4. a way to present or use the output.

A production application commonly adds authentication, a user interface or API, logging, policies, data stores, output checks, and sometimes retrieval or tool integrations.

Consider a simple internal policy chatbot. An employee asks, “What is the expense limit for client meals?” The application may retrieve relevant policy documents, insert selected passages and instructions into a prompt, ask the model to draft an answer, then display citations.

That system is an LLM application even if its path is fully predetermined:

• retrieve the relevant documents;
• construct a prompt using the documents and the question;
• call the model;
• return a response with citations.

Retrieval does not automatically make a system an agent. Nor does tool use. The key question is who or what chooses the next step.

A conventional LLM application can have fixed control logic written by engineers. For example, it might always search a designated knowledge base before answering. This is often called retrieval-augmented generation, or RAG. It can make answers more current and better grounded, but it remains an application with a predefined workflow if the software, rather than the model, determines each step.

This distinction is highly practical in a security assessment. Instead of asking vaguely, “Does it use AI?”, ask:

• What data does the application send to the model?
• What instructions shape the model’s behavior?
• Which data sources can it retrieve from?
• Which tools can it call?
• Does deterministic application code select the next step, or can the model select it?
• Which outputs are merely shown to a person, and which can cause an external action?

The answers reveal the system’s actual attack surface.

---

What makes something an assistant?

An assistant is primarily a description of the system’s interaction role. It assists a human user: answering questions, drafting material, organizing information, suggesting options, or helping complete a task.

An assistant normally has these characteristics:

• it is invoked or directed by a person;
• it communicates in an understandable, usually conversational form;
• it is intended to support the user’s judgment rather than replace it;
• important actions are commonly presented for review or confirmation.

For example, an HR assistant might retrieve leave-policy information, explain it to an employee, and draft a leave request. It may even fill in a form. If the employee reviews and submits that request, the system is acting as an assistant: the human remains the decision-maker for the consequential action.

“Assistant” does not imply that the system lacks tools. A calendar assistant might read schedules, draft an invitation, and prepare an email. Nor does it guarantee safety. An assistant that can read confidential calendars, access emails, or summarize sensitive documents still creates privacy and security concerns.

The term also does not prove that the system is non-agentic. A user-facing assistant can contain an agentic workflow behind its interface. The operational question is whether it stays within a human-directed interaction or can independently decide, execute, and continue actions in pursuit of a goal.

A helpful comparison is:

System description	Primary meaning	Typical decision-maker	Typical external effect
Foundation model	Trained reusable capability	No deployed decision-maker by itself	Generates an output
LLM application	Software product built around a model	Developers define at least some control logic	Varies with connected data and tools
Assistant	Human-support interaction pattern	Human generally retains task ownership	Advises, drafts, prepares, may request approval
Autonomous agent	Goal-seeking action system	System selects some steps and executes within delegated scope	May retrieve, call tools, alter records, or initiate transactions

The same product may occupy several rows. A foundation model is normally a component inside the other three; an autonomous agent is usually implemented as an LLM application; and an assistant may have agentic capabilities while operating under human approval.

---

What makes an agent autonomous?

An AI agent is an application that works toward a goal by interpreting input, reasoning about possible steps, using available information or tools, and acting based on its decisions.

The crucial difference from a fixed workflow is not simply that the system has several steps. It is that the system can select among steps at runtime. Given the goal “resolve a customer’s billing discrepancy,” it might decide whether to search the order system, retrieve policy guidance, ask for clarification, issue a permitted credit, or escalate to a human.

Agents commonly combine three kinds of components:

• Model: interprets the goal, information, and available choices.
• Tools: functions, APIs, databases, services, or actions the system may invoke.
• Orchestration: maintains state, applies policies, manages plans and tool calls, and determines when the task is complete or must stop.

An autonomous agent is an agent that has been delegated authority to take some actions without asking a human for approval each time. Autonomy is therefore not a binary label. It is a spectrum defined by scope and consequence.

For example:

Delegated capability	Autonomy level	Security significance
Draft a customer reply but never send it	Low	Incorrect content can still mislead, but no external action occurs
Send low-risk replies using approved templates	Limited	Requires controls over recipients, content, and escalation
Update a CRM record when evidence meets fixed policy	Bounded	Integrity of records and policy enforcement become critical
Issue refunds below a strict monetary limit	Bounded but consequential	Requires strong authorization, fraud controls, auditability, and rate limits
Negotiate contracts, move funds, or change access rights without approval	High	Error, manipulation, and privilege abuse can create severe impact

A scheduled job is not automatically autonomous. If it follows a rigid, predetermined sequence, it is an automated workflow. A system becomes agentic when it is entrusted to determine at least some of its own route toward an objective. It becomes autonomous when it can execute actions within that route without a human confirmation gate for each one.

This gives a precise way to describe a system:

“This is an LLM application presented as an employee assistant. It can retrieve HR policy and draft requests, but it cannot submit or modify records without employee approval.”

Or:

“This is a bounded autonomous support agent. It can inspect ticket history, select approved knowledge sources, create a draft response, and send it only for low-risk ticket categories under a defined policy.”

These descriptions are more useful than calling both systems “an AI chatbot.”

---

Why these distinctions matter for security

Each layer changes the security problem.

A foundation model raises questions about model behavior: unreliable output, unsafe completions, training-data concerns, and limits of probabilistic reasoning. However, it has no direct enterprise authority on its own.

An LLM application creates application-security concerns: prompt handling, authentication, data exposure, logs, retrieval access, output validation, and the credentials attached to integrations.

An assistant introduces human-factor questions: can users understand what it did, verify its claims, recognize uncertainty, and retain control over consequential decisions?

An autonomous agent adds the largest concern: delegated authority. The system may take action at machine speed using real credentials. A malicious instruction hidden in a document, a faulty tool response, or a mistaken model decision can become more than a bad answer if the agent can send, purchase, delete, change, or disclose.

The security label should therefore be based on capabilities, not branding. When reviewing an AI system, record:

1. Its model: Which foundation model or models generate or interpret content?
2. Its application boundaries: What code, prompts, data paths, and interfaces surround the model?
3. Its user role: Is it advising a user, preparing work, or representing the user?
4. Its authority: Which actions can it take, using whose identity, under what limits, and with what approvals?
5. Its controls: What prevents untrusted input or model output from causing an unauthorized action?

That last set of questions will recur throughout the course.

---

Key takeaways

A foundation model is broadly trained, reusable model capability. An LLM is the language-focused subset of foundation models.

An LLM application is a deployed system that combines a model with prompts and surrounding software. It may include retrieval, memory, tools, and fixed workflows without necessarily being an autonomous agent.

An assistant is a human-support role. It often keeps a person in the loop, but it can still access sensitive information and may contain agentic features.

An autonomous agent is an agent that can choose steps and execute some actions under delegated authority without case-by-case human approval. Its security risk depends less on the word agent than on its tools, credentials, data access, action limits, and approval gates.

Next, we will examine the operational heart of an agent: the perceive, reason, act, and observe loop. That loop will make it possible to trace how an agent turns an input into real-world actions—and where security controls must interrupt unsafe behavior.