This slide introduces a critical shift in how we must think about security in AI powered applications.
Large language models do not simply extend traditional software systems.
They fundamentally change the threat landscape.
As shown in the visual security is no longer just about protecting servers and APIs, but about safeguarding
reasoning, context, and behavior.
The subtitle emphasizes an important reality.
Llms introduce unprecedented security challenges that require a new mindset.
Traditional application security assumes inputs are structured and validated against strict schemas.
Llms, however, operate on natural language, which blurs the boundary between instructions and data.
This section focuses on understanding the threats before attempting to solve them.
Without a clear threat model defenses are incomplete and often ineffective.
By the end of this section, you'll understand why LLM systems must be designed with security as a foundational
requirement, not a feature added later.
This slide explains why LM security requires a fundamentally different approach from traditional application
security.
Unlike conventional systems where inputs are parsed and validated against predefined formats, LMS accept
free form language, making it difficult to distinguish legitimate requests from malicious manipulation.
The diagram highlights four critical layers of risk the prompt layer, context layer, tool layer,
and output layer.
Each of these represents a unique attack surface.
User prompts can contain hidden instructions.
Documents may embed malicious content.
Tools can be exploited through trusted responses, and outputs themselves may leak sensitive information.
The most important takeaway is the principle stated clearly on this slide LMS must be treated as untrusted
components.
You cannot assume the model will follow instructions Functions correctly or reject malicious input on
its own.
Security controls must therefore exist outside the model, validating inputs, isolating context, and
sanitizing outputs at every step.
This slide provides a structured overview of the major categories of threats facing LM systems.
Unlike traditional vulnerabilities that exploit code or memory, LM attacks exploit behavior.
How models interpret and respond to language.
The first category is prompt based attacks which manipulate model behavior using carefully crafted inputs.
The second is data exfiltration, where attackers attempt to extract sensitive information from prompts,
context, or training data.
The third is abuse and misuse, or systems are repurposed for malicious activities such as scams or
malware generation.
Finally, supply chain risks arise from dependencies on third party models, tools and plugins.
The reality check at the bottom is critical Attackers don't hack LMS in the traditional sense.
They influence outcomes by speaking the model's language.
Effective defences must therefore focus on controlling behaviour, not just infrastructure.
This slide introduces prompt injection, one of the most serious threats in LMS systems.
Prompt injection occurs when an attacker embeds malicious instructions into user controlled input,
causing the model to override system rules or perform unsafe actions.
Unlike SQL injection or XSS, prompt injection does not exploit parsing bugs.
It exploits the fact that LMS process all instructions, system prompts, and user input as natural
language within the same context window.
The attack example shown illustrates how simple and powerful this can be.
A single sentence asking the model to ignore previous instructions can expose system prompts, internal
logic, or safety constraints.
The danger lies in how difficult prompt injection is to fully eliminate.
Defending against it often requires trade offs between usability and security.
This makes prompt injection a first class threat that must be addressed explicitly in system design.
This slide breaks prompt injection into three distinct forms, each requiring different defenses.
Direct injection involves malicious instructions entered directly by users.
These attacks are easy to execute and often used to probe system boundaries, but they are also easier
to detect.
Indirect injection is more subtle and dangerous.
Here, malicious instructions are embedded inside documents, web pages, or emails that the LM later
processes.
This is especially problematic for rack systems where untrusted documents are ingested automatically.
Tool based injection exploits trusted tool outputs or API responses.
Because the system assumes tool responses are safe, attackers can chain tools together to escalate
attacks.
The core challenge is stated clearly.
Models cannot reliably distinguish instructions from data.
This is not a flaw.
It is a fundamental property of how llms work.
Security must therefore be layered and external to the model.
This slide focuses on data leakage.
One of the most subtle and damaging risks in LLM systems.
Data leakage often occurs quietly without triggering traditional security alerts.
The slide highlights high risk scenarios such as Rag systems, multi-user applications, and enterprise
tools with access to sensitive documents.
Leakage can occur through overly verbose outputs, where models include more information than necessary,
or through prompt logging where sensitive data is stored in logs.
Another serious risk is training data memorization, where models reproduce sensitive content when prompted
correctly.
Context crossover is especially Dangerous in multi-user systems, where one user's information contaminates
another session.
These risks make it clear that protecting data in LM systems requires more than encryption.
It requires strict isolation, filtering, and disciplined system design.
This slide outlines a defense in depth strategy for preventing data leakage.
No single mitigation is sufficient on its own.
Effective protection comes from layering controls.
Strict input and output filtering ensures sensitive data patterns are detected before and after model
interaction.
Output redaction adds an additional safety net by removing sensitive entities before responses are delivered.
User and session isolation is critical.
Context must never be shared across users, and permissions must be validated on every access.
Minimal prompt logging reduces exposure by storing only what is necessary with encryption and automatic
deletion policies.
The golden rule at the bottom is essential.
Never trust model outputs blindly.
Validation, sanitization and verification must happen outside the model, especially in security sensitive
workflows.
This slide addresses a reality.
Many teams underestimate even well-intentioned LLM systems can be weaponized.
Attackers may use your system to generate malware, phishing content, or large scale disinformation.
Social engineering attacks can manipulate customer service bots or impersonate users.
Policy circumvention allows attackers to bypass content filters through creative prompt engineering.
Automated disinformation enables misuse at unprecedented scale.
The defense techniques listed provide a practical response.
Clear usage policies and technical guardrails define acceptable behavior.
Content moderation filters both inputs and outputs.
Rate limiting prevents automated abuse.
Continuous monitoring enables detection and escalation.
The best practice at the bottom is critical.
Designed for misuse, not just intended use.
Security planning must assume adversarial creativity.
The final slide summarizes the core lessons of this section.
First, llms expand the attack surface beyond anything traditional security models were designed for.
Second, prompt injection must be treated with the same seriousness as SQL injection.
It cannot be ignored or fully eliminated.
Third, data leakage is subtle but dangerous, requiring multiple layers of defense.
Finally, preventing misuse is not a one time task.
It demands continuous monitoring, policy enforcement, and adaptation.
The final insight captures the mindset required to build secure systems.
Assume hostile inputs by default.
Security is not a feature you add.
It is a foundational requirement embedded into architecture workflows and monitoring.