01 Introduction to AI Security

Artificial Intelligence is changing how organizations build applications, automate business processes, analyze information and make decisions.

Enterprises are increasingly adopting:

Generative AI
Large Language Models
AI assistants
AI-powered applications
Retrieval-Augmented Generation
AI agents
Machine Learning platforms
AI APIs
AI-powered security tools
Cloud AI services

These technologies create enormous opportunities.

They also introduce new security questions.

What happens when an AI system can access sensitive enterprise data?

What happens when an attacker can manipulate the instructions given to an AI?

What happens when an AI agent can perform actions inside enterprise systems?

What happens when organizations cannot determine whether an AI-generated action should be trusted?

These questions form the foundation of AI Security.

Learning Objectives

By the end of this lesson, you should be able to:

Explain what AI Security means.
Understand why AI systems require specialized security controls.
Recognize the major components of an enterprise AI environment.
Understand how traditional cybersecurity and AI-specific security work together.
Identify major AI assets and attack surfaces.
Understand the AI security lifecycle.
Recognize common categories of AI security threats.
Understand the responsibilities of an AI Security Engineer.
Apply basic security thinking to an enterprise AI scenario.

What Is AI Security?

AI Security is the practice of protecting Artificial Intelligence systems, applications, models, data, infrastructure and business processes from security threats, misuse and unauthorized access.

It includes protecting:

AI Applications
       +
AI Models
       +
Training & Business Data
       +
LLM Applications
       +
RAG Systems
       +
Vector Databases
       +
AI Agents
       +
APIs
       +
Cloud Infrastructure
       +
Identity & Access
       +
AI Supply Chain
       +
Monitoring & Operations

AI Security therefore goes far beyond protecting the model itself.

A useful way to think about it is:

AI Security protects the entire system that allows AI to operate safely inside an organization.

Why Do We Need AI Security?

Consider a traditional application.

User
  │
  ▼
Web Application
  │
  ▼
Application Server
  │
  ▼
Database

Security teams already understand many risks in this architecture:

Authentication attacks
Authorization failures
SQL injection
API vulnerabilities
Credential theft
Data exposure
Server compromise
Cloud misconfiguration

Now consider a modern AI application.

User
  │
  ▼
AI Application
  │
  ▼
LLM
  │
  ├────► RAG
  │        │
  │        ▼
  │    Vector Database
  │
  ├────► Enterprise Data
  │
  ├────► External APIs
  │
  └────► AI Agent
           │
           ▼
      Enterprise Systems

The traditional risks still exist.

But additional security concerns appear.

For example:

Can an attacker manipulate the model using prompts?
Can malicious documents influence the AI?
Can sensitive information appear in model responses?
Can the model access information the user should not see?
Can an AI agent perform unauthorized actions?
Can attackers manipulate training or retrieval data?
Can an attacker steal or replace a model?
Can malicious dependencies compromise the AI environment?

This is why AI Security is becoming an important cybersecurity discipline.

Traditional Security Has Not Disappeared

One of the most important concepts in this learning path is:

AI does not replace traditional cybersecurity requirements.

An AI application is still an application.

It may still use:

APIs
Databases
Servers
Cloud infrastructure
Containers
Kubernetes
Identity systems
Networks
Secrets
Source code
CI/CD pipelines

Therefore traditional security controls still matter.

Enterprise AI Security
        │
        ├── Identity Security
        ├── Application Security
        ├── API Security
        ├── Cloud Security
        ├── Network Security
        ├── Data Security
        ├── Container Security
        ├── DevSecOps
        └── Security Operations

AI-specific security is added on top of these foundations.

Traditional Security + AI-Specific Security

Think of AI Security as two connected layers.

┌─────────────────────────────┐
│     AI-Specific Security    │
│                             │
│ Prompt Injection            │
│ RAG Security                │
│ Agent Security              │
│ Model Security              │
│ AI Data Manipulation        │
│ AI Safety Controls          │
└──────────────┬──────────────┘
               │
┌──────────────▼──────────────┐
│ Traditional Cybersecurity   │
│                             │
│ IAM                         │
│ Application Security        │
│ API Security                │
│ Cloud Security              │
│ Network Security            │
│ Data Security               │
│ Logging & Monitoring        │
└─────────────────────────────┘

Both layers must work together.

Example

Imagine an AI assistant has excellent prompt injection defenses.

However, its API key is exposed in a public source-code repository.

The AI-specific controls may be strong, but traditional credential security has failed.

Now imagine the opposite.

The infrastructure has:

Strong IAM
Encryption
Secure APIs
Network segmentation
Centralized logging

But the AI agent accepts untrusted instructions and can perform sensitive actions without sufficient authorization.

Traditional security may be strong, but the AI-specific control has failed.

Therefore:

Secure infrastructure does not automatically mean secure AI.

and:

Secure AI behavior does not automatically mean secure infrastructure.

AI Security Engineers must consider both.

Understanding the AI System

Before securing an AI system, understand what actually exists.

A typical enterprise AI environment may contain several layers.

Layer 1 — Users

Users interact with the AI system.

They may include:

Employees
Customers
Developers
Administrators
Partners
Applications
Automated services

Security questions include:

Who is the user?

How are they authenticated?

What are they authorized to access?

Layer 2 — AI Application

This is the application the user interacts with.

Examples include:

Chatbots
AI assistants
Security copilots
Coding assistants
Customer support applications
Document analysis platforms

The application may contain traditional security weaknesses.

Layer 3 — AI Model

The application communicates with an AI model.

The model may be:

Hosted internally
Hosted by a cloud provider
Accessed through an API
Running locally
Provided by a third party

The security architecture changes depending on where the model operates.

Layer 4 — Enterprise Knowledge

Many AI systems require additional organizational information.

This may include:

Documents
Policies
Customer records
Security procedures
Source code
Knowledge bases
Technical documentation

RAG is commonly used to provide this information to AI applications.

Layer 5 — Tools and Agents

Modern AI systems may be able to perform actions.

An AI agent might:

Read Email
    ↓
Search Documents
    ↓
Query Database
    ↓
Create Ticket
    ↓
Call API
    ↓
Modify Cloud Resource

This introduces significant security considerations.

Layer 6 — Infrastructure

Everything must run somewhere.

Infrastructure may include:

Cloud platforms
Virtual machines
Containers
Kubernetes
Databases
Storage
Networking
Identity services
Secrets management

Layer 7 — Security Operations

Organizations also need visibility.

This may include:

Application logs
AI interaction logs
Authentication logs
API logs
Cloud audit logs
Agent activity
Security alerts
SIEM
Incident response

All these layers form the AI security environment.

The Enterprise AI Attack Surface

An attack surface is the collection of places where an attacker could potentially interact with or compromise a system.

For an AI environment, this may include:

                  ENTERPRISE AI SYSTEM

                         User
                          │
                          ▼
                    AI Application
                     /     |      \
                    /      |       \
                   ▼       ▼        ▼
                 API     LLM      Agent
                  │       │         │
                  │       │         ├── Tools
                  │       │         ├── APIs
                  │       │         └── Systems
                  │       │
                  │       ├── RAG
                  │       │    │
                  │       │    ▼
                  │       │ Vector DB
                  │       │
                  ▼       ▼
              Infrastructure
                    │
                    ▼
               Enterprise Data

Each connection creates questions about:

Trust
Authentication
Authorization
Data exposure
Input validation
Monitoring

What Are We Protecting?

Security begins by identifying assets.

An AI environment may contain assets such as:

Models

AI and Machine Learning models.

Data

Training, business and customer information.

Prompts

System instructions and application context.

Credentials

API keys, tokens and service credentials.

Infrastructure

Cloud resources, servers and containers.

Applications

AI-enabled business applications.

APIs

Interfaces connecting services.

Vector Databases

Stores containing embeddings and retrieved information.

AI Agents

Systems capable of performing actions.

Business Processes

Workflows that depend on AI decisions or automation.

Different assets require different controls.

The Three Security Objectives

Traditional cybersecurity commonly begins with:

Confidentiality

Information should only be accessible to authorized users and systems.

AI example:

An employee should not retrieve another department’s confidential documents through an AI assistant.

Integrity

Information and systems should not be modified improperly.

AI example:

An attacker should not be able to manipulate retrieved documents to influence AI behavior.

Availability

Systems should remain accessible when required.

AI example:

An attacker should not be able to exhaust AI resources and prevent legitimate users from accessing the service.

These principles remain relevant to AI.

Additional AI Security Concerns

AI systems introduce additional considerations.

Model Behavior

Can users manipulate the model into violating intended restrictions?

Data Provenance

Can the organization trust the data used by the system?

Agent Actions

Can AI perform actions beyond its intended authority?

Explainability and Traceability

Can important AI actions be investigated?

Human Oversight

Do high-risk actions require human approval?

AI Supply Chain

Can models, datasets or dependencies be trusted?

AI Security therefore extends traditional security thinking.

Major AI Security Threat Categories

You will study these areas in much greater detail later.

For now, understand the major categories.

Prompt Injection

An attacker attempts to manipulate the instructions processed by an AI system.

Conceptually:

Trusted Instructions
       +
Untrusted Input
       ↓
      LLM
       ↓
Unexpected Behavior

Prompt injection becomes especially important when AI systems interact with external content or tools.

Indirect Prompt Injection

The malicious instruction does not necessarily come directly from the user.

It might exist inside:

Documents
Websites
Emails
Database records
Retrieved knowledge

For example:

Malicious Document
        ↓
RAG Retrieval
        ↓
LLM Processes Content
        ↓
Unexpected Behavior

This creates new trust-boundary challenges.

Sensitive Information Disclosure

An AI system may expose information that should remain confidential.

Examples include:

Internal documents
Customer information
Credentials
System instructions
Proprietary data
Security configurations

Data access controls remain critical.

RAG Security Risks

Retrieval-Augmented Generation connects AI models to external knowledge.

User Question
      ↓
Retriever
      ↓
Knowledge Source
      ↓
Relevant Content
      ↓
LLM
      ↓
Response

Security questions include:

Who can access the source documents?
Can users retrieve unauthorized content?
Can malicious documents influence the model?
Is sensitive metadata exposed?
Are permissions preserved during retrieval?

AI Agent Security

AI agents may interact with tools and systems.

For example:

User
 │
 ▼
AI Agent
 │
 ├── Email
 ├── Database
 ├── Cloud
 ├── Files
 └── APIs

This introduces a major question:

What happens if the AI agent is manipulated?

The impact may no longer be limited to incorrect text.

It could involve real actions.

Excessive Agency

An AI system may be given more authority than required.

For example:

AI Assistant Requirement:
Read cloud configuration.

Actual Permission:
Full cloud administrator.

This violates least privilege.

If the AI system is compromised or manipulated, excessive permissions increase the potential impact.

Model and Data Manipulation

Attackers may attempt to influence:

Training data
Fine-tuning data
Retrieved documents
Model behavior
Model files

Security teams must therefore consider the integrity of the AI lifecycle.

AI Supply Chain Risk

AI applications rely on many external components.

AI Application
     │
     ├── Model
     ├── Dataset
     ├── Python Packages
     ├── Container Images
     ├── APIs
     ├── Libraries
     └── External Services

A weakness in any dependency may affect the overall system.

Insecure Output Handling

AI-generated output should not automatically be trusted.

Suppose an AI system generates:

SQL
Code
HTML
Shell Commands
API Requests
Cloud Configuration

If another system automatically executes or processes that output, security problems may occur.

AI output should be treated according to its trust level and context.

The AI Security Lifecycle

AI Security should not begin after deployment.

Security should be considered throughout the lifecycle.

Plan
  ↓
Design
  ↓
Develop
  ↓
Test
  ↓
Deploy
  ↓
Monitor
  ↓
Respond
  ↓
Improve

Plan

Understand:

Business purpose
Data requirements
AI use case
Risk classification
Security requirements

Design

Perform:

Architecture review
Threat modeling
Trust-boundary analysis
Identity design
Data security design

Develop

Apply:

Secure coding
Dependency management
Secrets management
Access controls
Secure AI development practices

Test

Perform:

Application security testing
AI security testing
Prompt security testing
Authorization testing
RAG testing
Agent security testing

Deploy

Ensure:

Secure configuration
Least privilege
Secrets protection
Logging
Monitoring

Monitor

Observe:

Authentication
API activity
Model interactions
Data access
Agent actions
Security alerts

Respond

Prepare for:

AI-related incidents
Data exposure
Credential compromise
Agent misuse
Model or data manipulation

Improve

Use findings and incidents to improve:

Architecture
Security controls
Monitoring
Policies
Testing
Training

Security Should Shift Left

A weak approach is:

Build AI Application
        ↓
Deploy to Production
        ↓
Ask Security to Check It

A stronger approach is:

Business Idea
     ↓
Security Requirements
     ↓
Architecture
     ↓
Threat Modeling
     ↓
Development
     ↓
Security Testing
     ↓
Deployment
     ↓
Monitoring

Security becomes part of engineering rather than a final checkpoint.

Example Enterprise Scenario

Imagine an organization wants to create an internal AI assistant for its security team.

The assistant can:

Search security documentation
Summarize incidents
Query security alerts
Explain cloud configurations
Create investigation notes

The architecture is:

Security Analyst
      │
      ▼
AI Security Assistant
      │
      ▼
Enterprise LLM
      │
      ├── Security Knowledge Base
      ├── SIEM
      ├── Cloud Logs
      └── Ticketing System

At first glance, this looks useful.

Now think like an AI Security Engineer.

Question 1 — Identity

Who can access the AI assistant?

Are users authenticated?

Question 2 — Authorization

Can every analyst access every incident?

Question 3 — Data

Does the system process:

Credentials?
Customer data?
Incident evidence?
Internal infrastructure information?

Question 4 — LLM

Can prompts manipulate the assistant?

Question 5 — RAG

Can retrieved content contain malicious instructions?

Question 6 — Integrations

Can the assistant query the SIEM with excessive privileges?

Question 7 — Actions

Can the AI modify tickets or only read them?

Question 8 — Logging

Are important AI actions recorded?

Question 9 — Monitoring

Would suspicious behavior generate an alert?

Question 10 — Incident Response

Could investigators reconstruct what the AI did?

You have just performed the beginning of an AI security review.

The AI Security Engineer’s Core Questions

When you encounter an AI system, develop the habit of asking:

1. What does this AI system do?

2. What assets does it use?

3. What data can it access?

4. Who can access the system?

5. What permissions does it have?

6. What external systems does it trust?

7. What untrusted input can reach it?

8. What actions can it perform?

9. What could go wrong?

10. What controls prevent it?

11. How would we detect misuse?

12. How would we investigate an incident?

These questions will follow you throughout the learning path.

Defense in Depth

AI Security should not depend on one control.

Suppose an organization tries to solve AI security entirely using a system prompt:

"Never reveal confidential information."

That is not sufficient.

A stronger architecture may use:

Authentication
      +
Authorization
      +
Data Access Controls
      +
Prompt Controls
      +
RAG Permissions
      +
Agent Least Privilege
      +
Output Validation
      +
Logging
      +
Monitoring

This is defense in depth.

If one control fails, additional controls still reduce risk.

Least Privilege

Least privilege is especially important for AI systems.

An AI agent should receive only the permissions required for its task.

Bad design:

AI Agent
   │
   ▼
Administrator Access

Better:

AI Agent
   │
   ▼
Specific Required Permission

For example:

Requirement:
Read security alerts.

Permission:
Read security alerts.

not:

Requirement:
Read security alerts.

Permission:
Full SIEM administrator.

Zero Trust Thinking

AI systems should not automatically trust:

Users
Prompts
Retrieved documents
Model output
APIs
Agents
External services

A useful mindset is:

Verify explicitly and minimize implicit trust.

AI-generated output should also not automatically be considered trustworthy simply because it came from a model.

Logging and Monitoring

Security teams cannot protect systems they cannot observe.

Useful AI security telemetry may include:

User Identity
      +
Prompt / Request Context
      +
Application Activity
      +
Data Access
      +
Model Interaction
      +
Tool Invocation
      +
Agent Action
      +
Security Decision
      +
Timestamp

The exact information logged must also consider privacy and data-protection requirements.

Logging everything without considering sensitive information can itself create risk.

AI Security and Privacy

AI systems may process large amounts of information.

Security engineers should ask:

What data enters the AI?
Where is it stored?
Is it retained?
Who can access it?
Is it sent to a third party?
Is sensitive data required?
Can data be minimized?
Are prompts logged?
Are responses logged?

AI Security and privacy frequently overlap.

AI Security and Governance

Technical controls alone are not enough.

Organizations also need:

AI policies
Risk classification
Approved use cases
Security requirements
Vendor assessment
Data governance
Model governance
Incident procedures
Accountability

This is why AI Security Engineers often work with:

Security
   +
Engineering
   +
Cloud
   +
Data
   +
Privacy
   +
Risk
   +
Compliance
   +
Legal
   +
Business

AI Security is a cross-functional discipline.

Security Frameworks You Will Encounter

Throughout this learning path, you will encounter established security guidance and frameworks relevant to AI.

These may include:

OWASP guidance for LLM and Generative AI applications
MITRE ATLAS
NIST AI Risk Management Framework
Secure development practices
Cloud security frameworks
Enterprise security architecture principles

Do not try to memorize frameworks immediately.

Learn what problem each framework helps solve.

OWASP Perspective

OWASP guidance helps security professionals understand common security risks affecting modern AI and LLM applications.

You will later study these risks in greater detail.

Use OWASP guidance to help answer:

What common application-level AI security weaknesses should we consider?

MITRE ATLAS Perspective

MITRE ATLAS provides knowledge about adversarial tactics and techniques involving AI-enabled systems.

It helps security professionals think from an attacker perspective.

Use it to help answer:

How might adversaries target AI systems?

NIST AI Risk Management Perspective

AI security is also part of broader AI risk management.

Organizations need to consider:

Governance
Risk
Trustworthiness
Security
Privacy
Reliability

You will explore these concepts later in the AI Governance module.

What AI Security Is Not

AI Security is not simply:

Prompt Engineering

It is not simply:

Jailbreaking Chatbots

It is not simply:

Using AI Security Tools

And it is not simply:

Machine Learning Security

AI Security is the broader discipline of protecting the entire AI-enabled system.

AI Security Engineer vs AI Red Teamer

These roles overlap but are not identical.

AI Security Engineer

Focuses broadly on:

Secure architecture
Security controls
Infrastructure
IAM
Data protection
LLM security
Monitoring
Incident response
Risk reduction

AI Red Teamer

Focuses more heavily on:

Adversarial testing
Attack scenarios
Control validation
Abuse cases
Security weaknesses
Exploitability

An AI Security Engineer should understand red teaming, but the engineering role is broader.

AI Security Engineer vs Cloud Security Engineer

A Cloud Security Engineer primarily protects cloud environments.

An AI Security Engineer protects AI-enabled systems.

However, the two roles frequently overlap.

Cloud Security
      │
      └────► Infrastructure Supporting AI

AI Security
      │
      └────► AI Applications, Models, RAG & Agents

This is why cloud security knowledge is valuable for AI Security Engineers.

AI Security Engineer vs GRC

GRC professionals typically focus more heavily on:

Governance
Risk
Compliance
Policies
Controls
Audits

AI Security Engineers focus more heavily on technical implementation and security engineering.

Both may collaborate on AI governance and risk.

Real-World AI Security Workflow

An AI Security Engineer may work through a process such as:

New AI Project
      ↓
Understand Business Use Case
      ↓
Review Architecture
      ↓
Identify Data
      ↓
Identify Identities & Permissions
      ↓
Threat Model
      ↓
Define Security Requirements
      ↓
Review Implementation
      ↓
Perform Security Testing
      ↓
Remediate Findings
      ↓
Approve / Accept Risk
      ↓
Deploy
      ↓
Monitor

This is much broader than running security tools.

Common Beginner Mistakes

Mistake 1 — Focusing Only on Prompt Injection

Prompt injection is important, but it is only one part of AI Security.

Mistake 2 — Ignoring Traditional Security

AI applications still require secure IAM, APIs, infrastructure and data.

Mistake 3 — Giving AI Agents Too Much Access

Agent permissions should follow least privilege.

Mistake 4 — Trusting AI Output

Model output should be treated according to context and risk.

Mistake 5 — Ignoring RAG Permissions

Connecting an AI system to documents does not remove the need for authorization.

Mistake 6 — Security After Deployment

Security should begin during design.

Mistake 7 — Testing Without Understanding Architecture

You cannot effectively secure what you do not understand.

AI Security Engineer Checklist

When reviewing an AI system, start with:

Business

What is the AI system supposed to do?
What business process does it support?
What happens if it fails or is manipulated?

Architecture

What components exist?
Where are the trust boundaries?
What external services are used?

Identity

Who can access the system?
How are users authenticated?
What permissions exist?

Data

What data does the system process?
Is sensitive information involved?
Where is data stored?

AI

Which models are used?
Is RAG used?
Are AI agents used?
Can untrusted input reach the model?

Infrastructure

Where does the system run?
How are secrets protected?
Are cloud permissions restricted?

Security

Has threat modeling been performed?
Have security controls been tested?
Are dependencies trusted?

Operations

What activity is logged?
What security alerts exist?
Can incidents be investigated?

This checklist will become more sophisticated as you progress.

Interview Perspective

You may eventually encounter a question such as:

What is AI Security?

A strong answer would not simply say:

“AI Security protects AI models.”

A stronger explanation would be:

AI Security is the practice of protecting the complete AI ecosystem, including models, applications, data, APIs, RAG systems, agents, infrastructure and supporting business processes. It combines traditional cybersecurity controls such as IAM, application security, cloud security and monitoring with AI-specific controls addressing risks such as prompt injection, unsafe agent behavior, data manipulation and model-related threats.

Another common question may be:

What is the first thing you would do when reviewing an AI application?

A strong starting point is:

Understand the business use case and architecture before attempting to assess individual controls.

That allows you to identify assets, identities, data flows, trust boundaries, integrations and potential attack surfaces.

Key Takeaways

AI Security is not limited to protecting AI models.

It protects the complete ecosystem:

Applications
+
Models
+
Data
+
RAG
+
Agents
+
APIs
+
Identity
+
Infrastructure
+
Supply Chain
+
Operations

Traditional cybersecurity remains essential.

AI introduces additional security concerns that must be addressed alongside existing controls.

Always begin by understanding:

Business Purpose
      ↓
Architecture
      ↓
Assets
      ↓
Data
      ↓
Identities
      ↓
Trust Boundaries
      ↓
Attack Surface
      ↓
Security Controls

The most important mindset from this lesson is:

Understand the system before trying to secure the system.

What’s Next?

➡️ 02 — How AI and Machine Learning Systems Work

You now understand why AI Security exists and what needs to be protected.

The next step is understanding the technology itself.

In the next lesson, you will learn:

What Artificial Intelligence actually means
How AI, Machine Learning and Deep Learning relate
How Machine Learning systems learn from data
Training vs inference
Models and datasets
Supervised and unsupervised learning
Neural networks at a practical level
Where security risks enter the ML lifecycle
Why AI Security Engineers need to understand how models are built and used
How these concepts connect to Generative AI and Large Language Models

You do not need to become a data scientist.

The objective is to understand AI and Machine Learning from a Security Engineer’s perspective.

➡️ Next: 02 — How AI and Machine Learning Systems Work