05 AI Security Attack Surface

Before you can defend an AI system, you need to understand where it can be attacked.

This is the purpose of attack surface analysis.

An attack surface is the collection of all possible points where an attacker may:

Enter a system
Influence a system
Access data
Abuse permissions
Manipulate behavior
Exploit vulnerabilities
Trigger unauthorized actions

In traditional cybersecurity, the attack surface may include:

Internet-facing applications
APIs
Servers
User accounts
Cloud resources
Network services
Endpoints

In AI environments, the attack surface becomes broader because the system may also include:

Prompts
Models
RAG pipelines
Vector databases
AI agents
Tool integrations
Model repositories
Training datasets
Third-party AI services

As an AI Security Engineer, one of your key skills is learning to look at an AI architecture and identify:

Where can an attacker interact with this system, and what could happen if that interaction succeeds?

Learning Objectives

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

Explain what an AI attack surface is.
Identify major attack surfaces in an enterprise AI system.
Understand the difference between entry points and assets.
Recognize trust boundaries.
Identify attack paths.
Understand attack surfaces across prompts, RAG, agents and infrastructure.
Recognize how traditional and AI-specific attack surfaces combine.
Understand third-party and supply-chain attack surfaces.
Perform a basic AI attack surface assessment.
Build an attack surface inventory for later threat modeling.

What Is an Attack Surface?

An attack surface is everything an attacker may be able to interact with or influence.

A simple traditional example:

Internet
   │
   ▼
Web Application
   │
   ▼
API
   │
   ▼
Database

Possible attack surface:

Login Page
API Endpoint
Application Input
Database Interface
Administrator Portal

Now consider an AI application.

User
 │
 ▼
AI Application
 │
 ├── Prompt
 ├── LLM API
 ├── RAG
 ├── Vector Database
 └── AI Agent
       │
       └── Enterprise Tools

The attack surface is significantly larger.

AI Attack Surface = Traditional + AI-Specific

A useful model is:

Traditional Attack Surface
          +
AI-Specific Attack Surface
          =
Enterprise AI Attack Surface

Traditional attack surfaces include:

Authentication
APIs
Applications
Cloud infrastructure
Networks
Databases
Secrets
Software dependencies

AI-specific surfaces include:

Prompts
Context
Models
Embeddings
RAG
Vector databases
Agents
Tool execution
Model repositories
Training data

Both matter.

Attack Surface vs Vulnerability

These are not the same thing.

An attack surface is:

Where an attacker could interact.

A vulnerability is:

A weakness that may allow the attacker to succeed.

Example:

Public AI API

is an attack surface.

If the API does not require authentication:

Missing Authentication

is the vulnerability.

If an attacker accesses sensitive model functionality:

Unauthorized Access

is the security impact.

Attack Surface vs Asset

An asset is something valuable that needs protection.

Examples:

Customer data
Model weights
Credentials
Source code
Cloud resources

An attack surface is how an attacker may reach or influence those assets.

Example:

Asset:
Confidential Documents

Attack Surface:
RAG Retrieval API

Weakness:
Missing document-level authorization

Impact:
Unauthorized disclosure

This relationship is important.

The Attack Path Model

A useful way to analyze AI security is:

Entry Point
    ↓
Weakness
    ↓
Trust Boundary
    ↓
Privileged Component
    ↓
Asset
    ↓
Impact

For example:

User Prompt
    ↓
Prompt Injection
    ↓
LLM
    ↓
AI Agent
    ↓
Cloud Tool
    ↓
Unauthorized Cloud Action

This is an attack path.

Attack surface analysis helps identify where these paths may begin.

1 — User Attack Surface

Users are one of the first attack surfaces.

Users may include:

Employees
Customers
Administrators
Developers
Partners
Anonymous users

Questions include:

Who can access the system?
Can anyone create an account?
Is authentication required?
Is MFA required?
Are privileged users separated?
Can users access each other’s data?

Example

Internet User
     │
     ▼
AI Chat Application

If the application is public, every user input becomes part of the attack surface.

2 — Authentication Attack Surface

Authentication mechanisms may include:

Passwords
SSO
OAuth
API keys
Tokens
Certificates
Service identities

Attackers may target:

Weak passwords
Stolen sessions
Exposed API keys
Misconfigured OAuth
Excessive service account privileges

AI applications do not remove traditional identity risks.

Example

Attacker
   │
   ▼
Stolen API Key
   │
   ▼
LLM API

This may provide unauthorized access without requiring any AI-specific technique.

3 — Authorization Attack Surface

Authentication answers:

Who are you?

Authorization answers:

What can you access?

This distinction is extremely important in AI applications.

Example:

Employee
   │
   ▼
AI Assistant
   │
   ▼
RAG
   │
   ▼
All Enterprise Documents

The employee may be authenticated correctly.

But if RAG retrieves all documents without enforcing permissions, authorization has failed.

Authorization Attack Surface Includes

Document permissions
API permissions
Agent tool permissions
Model access
Administrative functions
Cloud permissions
Tenant isolation

4 — Application Attack Surface

An AI application is still a software application.

Traditional application risks remain relevant.

Possible surfaces include:

Login pages
Forms
APIs
Session management
File uploads
Administrative interfaces
Webhooks

Potential vulnerabilities may include:

Injection
Broken access control
Cross-site scripting
Insecure file uploads
Insecure APIs
Session weaknesses

AI-specific security should never replace application security.

5 — API Attack Surface

AI architectures depend heavily on APIs.

Examples include:

Application → LLM API
Application → Vector Database
Agent → Cloud API
Agent → Email API
RAG → Search API

Each interface creates a potential attack surface.

Security questions include:

Is authentication required?
Is authorization enforced?
Are keys protected?
Are rate limits configured?
Is input validated?
Is activity logged?

Example

Internet
   │
   ▼
Public AI API
   │
   ▼
LLM

If API keys are weak or exposed, the attacker may gain direct access.

6 — Prompt Attack Surface

Prompts are one of the most recognizable AI-specific attack surfaces.

User prompts influence model behavior.

Example:

User Input
    ↓
LLM
    ↓
Response

Because user input is untrusted, it may contain:

Malicious instructions
Manipulative context
Obfuscated content
Attempts to bypass restrictions

This creates the foundation for prompt injection.

Prompt Security Question

Ask:

What happens if the user deliberately gives the model instructions that conflict with the application’s intended behavior?

That question will become central later.

7 — System Prompt Attack Surface

System prompts contain application-level instructions.

Example:

You are an internal security assistant.
Do not reveal confidential information.

Potential risks include:

Prompt exposure
Prompt manipulation
Overreliance on system instructions
Sensitive information embedded in prompts

Important principle:

Do not store secrets inside system prompts.

A system prompt should not contain:

API keys
Passwords
Sensitive credentials
Private tokens

Why?

If system instructions become visible through model behavior, embedded secrets could be exposed.

8 — Conversation History Attack Surface

Many AI applications retain previous messages.

Example:

User Message
   ↓
Assistant Response
   ↓
User Message
   ↓
Full History Sent to Model

Potential security risks include:

Sensitive information retention
Cross-session data leakage
Shared conversation exposure
Manipulated historical context

Security engineers should understand how conversation memory works.

9 — Context Attack Surface

Model context may include much more than the user’s message.

For example:

System Prompt
+
User Prompt
+
Conversation History
+
RAG Documents
+
Tool Results
+
Application Metadata

Every element that enters context may influence model behavior.

This creates a powerful security principle:

Every context source should have a defined trust level.

Example

Trusted:
System Configuration

Semi-Trusted:
Enterprise Documents

Untrusted:
User Input
External Web Content

These should not all be treated equally.

10 — RAG Attack Surface

Retrieval-Augmented Generation introduces several new attack surfaces.

User
 │
 ▼
Retriever
 │
 ▼
Vector Database
 │
 ▼
Documents
 │
 ▼
LLM

Potential attack surfaces include:

Document ingestion
Retrieval query
Embeddings
Vector database
Document authorization
Retrieved content

RAG Risk Areas

Attackers may attempt to:

Upload malicious documents
Manipulate indexed content
Retrieve unauthorized information
Influence model behavior through documents
Access sensitive metadata

11 — Document Ingestion Attack Surface

Enterprise RAG systems may ingest documents from:

SharePoint
Cloud storage
File uploads
Websites
Knowledge platforms
Email
Databases

The ingestion pipeline may look like:

Document Source
      ↓
Parser
      ↓
Chunking
      ↓
Embedding
      ↓
Vector Database

Security questions:

Who can add documents?
Are sources trusted?
Are uploads scanned?
Can content contain malicious instructions?
Is source provenance recorded?

This is a major AI supply-chain boundary.

12 — Vector Database Attack Surface

Vector databases can contain valuable information.

Potential risks include:

Public exposure
Weak authentication
Missing tenant isolation
Excessive permissions
Sensitive metadata leakage
Unauthorized queries

Example:

Attacker
   │
   ▼
Exposed Vector Database
   │
   ▼
Enterprise Embeddings / Metadata

The vector store should be treated as a sensitive enterprise database.

13 — Embedding Attack Surface

Embeddings represent data numerically.

Security concerns may include:

Unauthorized access
Incorrect tenant isolation
Malicious embedding generation
Manipulated indexing
Information inference

Embeddings should not automatically be treated as non-sensitive simply because they are numerical.

14 — Model API Attack Surface

The interface to the model creates another surface.

Potential issues include:

Exposed API keys
Unauthorized requests
Excessive rate usage
Cost abuse
Sensitive prompt leakage
Weak access control

Example:

Compromised API Key
        ↓
Model API
        ↓
Unauthorized Usage
        ↓
Financial / Data Impact

15 — Model Attack Surface

The model itself may be targeted.

Possible attacks include:

Model extraction
Model theft
Model tampering
Adversarial inputs
Backdoors
Malicious fine-tuning

If the organization hosts models internally, the model files may represent valuable intellectual property.

16 — Model Repository Attack Surface

Models may be stored in:

Model registries
Cloud storage
Artifact repositories
Public model repositories

Attackers may attempt to:

Replace models
Upload malicious artifacts
Modify versions
Gain unauthorized access

Example:

Compromised Model Registry
        ↓
Modified Model
        ↓
Production Deployment

This resembles software supply-chain compromise.

17 — Training Data Attack Surface

Training data may be targeted through:

Data poisoning
Unauthorized changes
Manipulated labels
Malicious samples
Data corruption

Example:

Legitimate Dataset
       +
Manipulated Records
       ↓
Training
       ↓
Compromised Model Behavior

Training data integrity is a major AI security concern.

18 — Training Infrastructure Attack Surface

Training environments may contain:

GPUs
Cloud compute
Development notebooks
Data stores
Credentials
Source code
Models

Potential threats include:

Credential theft
Notebook compromise
Unauthorized compute usage
Data theft
Model theft

Traditional cloud and infrastructure security applies strongly here.

19 — Fine-Tuning Attack Surface

Organizations may fine-tune models using internal datasets.

Security concerns include:

Sensitive training data
Unauthorized fine-tuning
Poisoned fine-tuning datasets
Incorrect access control
Model behavior changes

Organizations should track:

Base Model
   ↓
Fine-Tuning Dataset
   ↓
Fine-Tuning Process
   ↓
New Model Version

Each step should be auditable.

20 — AI Agent Attack Surface

Agents significantly increase the attack surface.

A basic LLM may generate text.

An AI agent may:

Read
Write
Modify
Delete
Execute
Send
Create

This changes security impact.

Example

User Prompt
     ↓
AI Agent
     ↓
Cloud Tool
     ↓
Production Environment

If the agent is manipulated, it may perform a real-world action.

21 — Tool Attack Surface

Agents may connect to:

Email
Databases
Cloud services
Browsers
Code execution
Ticketing
SIEM
Endpoint tools

Each tool should be treated as an attack surface.

Security questions:

What can the tool do?
What credentials does it use?
What permissions exist?
Can actions be reversed?
Are actions logged?

22 — Tool Permission Attack Surface

Permissions are especially important.

Bad:

AI Agent
   ↓
Cloud Administrator

Better:

AI Agent
   ↓
Read Security Alerts

The attacker may not need to compromise the cloud account directly.

They may only need to manipulate an overprivileged AI agent.

23 — Code Execution Attack Surface

Some AI systems can execute code.

For example:

User
 │
 ▼
AI Agent
 │
 ▼
Code Interpreter
 │
 ▼
Execution Environment

Potential risks include:

Unauthorized file access
Network access
Command execution
Resource abuse
Data exposure

Code execution environments require strong isolation.

24 — Plugin and Integration Attack Surface

AI applications may use plugins or integrations.

Examples:

Search plugins
Productivity integrations
CRM integrations
Security tools
Cloud services

Potential risks include:

Malicious plugins
Excessive permissions
Insecure authentication
Supply-chain compromise

Third-party integrations should be reviewed before approval.

25 — Cloud Infrastructure Attack Surface

Enterprise AI commonly runs in cloud environments.

Potential surfaces include:

Public endpoints
IAM
Storage
Compute
Kubernetes
Serverless functions
Security groups
Network policies

A cloud misconfiguration may expose the AI platform regardless of model security.

26 — Container Attack Surface

AI services may run in containers.

Potential risks include:

Vulnerable images
Running as root
Excessive capabilities
Exposed secrets
Container escape
Outdated dependencies

Container security remains relevant to AI workloads.

27 — Kubernetes Attack Surface

AI workloads may run on Kubernetes.

Potential surfaces include:

Kubernetes API
Service accounts
Secrets
Pods
Container images
Network policies
Admission controls

An attacker compromising the Kubernetes platform may gain access to models, data and credentials.

28 — Secrets Attack Surface

AI applications frequently rely on secrets.

Examples:

API keys
Cloud credentials
Database passwords
Service tokens
Certificates

Attackers may search for secrets in:

Source code
Environment variables
Logs
Container images
CI/CD systems

Secret protection is critical.

29 — CI/CD Attack Surface

AI applications may use CI/CD pipelines for deployment.

A pipeline might:

Source Code
    ↓
Build
    ↓
Test
    ↓
Container Image
    ↓
Deploy

Potential risks include:

Compromised source code
Malicious dependencies
Stolen pipeline credentials
Artifact tampering
Unauthorized deployment

AI security includes software supply-chain security.

30 — MLOps Attack Surface

Machine Learning operations, or MLOps, may include:

Data pipelines
Training
Model registries
Evaluation
Deployment
Monitoring

Attackers may target any stage.

Dataset
   ↓
Training Pipeline
   ↓
Model Registry
   ↓
Deployment Pipeline
   ↓
Production

Security should protect the complete flow.

31 — Third-Party AI Attack Surface

Organizations often depend on external AI providers.

Examples include:

Model APIs
AI SaaS
Data platforms
Model repositories
AI development tools

Potential concerns include:

Data exposure
Provider compromise
Vendor access
Unknown retention
Supply-chain risk
Service availability

Third-party trust becomes part of enterprise AI security.

32 — Vendor Management Attack Surface

Organizations should understand:

Which AI vendors are approved?
What data is sent to them?
What security controls exist?
Where is data stored?
Who can access it?
What happens if the service is breached?

Vendor assessment is an important part of AI security architecture.

33 — Logging Attack Surface

Logs can help defenders.

But logs can also expose sensitive information.

Possible sensitive content includes:

Prompts
Responses
API keys
Customer data
User identifiers

Therefore:

Logging
   =
Security Visibility
   +
Potential Data Exposure

Logging design must consider both.

34 — Monitoring Interface Attack Surface

Security dashboards and management consoles may expose privileged functions.

Examples:

AI management console
Model administration
RAG administration
Prompt management
Logging dashboards

These interfaces require strong access control.

35 — Administrative Attack Surface

Administrative functions may allow users to:

Change prompts
Change models
Add data sources
Modify tool permissions
View logs
Create users

Compromise of these functions can affect the entire AI system.

36 — Developer Attack Surface

Developers may have powerful access to:

Source code
Models
test environments
API keys
prompt configuration
deployment pipelines

Developer identities should also follow least privilege.

37 — Shadow AI Attack Surface

Employees may use unapproved AI platforms.

Example:

Employee
   ↓
Copies Internal Source Code
   ↓
External AI Tool

Potential risks include:

Data leakage
Compliance violations
Unknown retention
Loss of intellectual property

Shadow AI becomes an organizational attack surface.

38 — Human Attack Surface

AI security is not only technical.

Attackers may target:

Developers
Administrators
AI users
Security teams

Techniques may include:

Phishing
Credential theft
Social engineering
Malicious file sharing

Traditional human security remains important.

39 — Physical and Endpoint Attack Surface

AI engineers may access models and data from laptops or workstations.

Compromised endpoints may expose:

API keys
Cloud credentials
source code
proprietary models
datasets

Endpoint security remains part of the architecture.

AI Attack Surface Map

A complete enterprise AI attack surface may look like:

                         External Users
                              │
                              ▼
                       AI Application
                              │
        ┌─────────────────────┼─────────────────────┐
        │                     │                     │
        ▼                     ▼                     ▼
      APIs                  Prompts                RAG
        │                     │                     │
        │                     │                     ▼
        │                     │              Vector Database
        │                     │                     │
        │                     │                     ▼
        │                     │                 Documents
        │                     │
        ▼                     ▼
      Model ◄────────── Model Context
        │
        ▼
     AI Agent
        │
        ├── Cloud Tools
        ├── Databases
        ├── Email
        ├── Code Execution
        └── Security Tools
        │
        ▼
Infrastructure
        │
        ├── Cloud
        ├── Containers
        ├── Kubernetes
        ├── CI/CD
        ├── Secrets
        └── MLOps

Attack surface analysis evaluates every connection.

How to Map an AI Attack Surface

Use a repeatable process.

Step 1 — Understand the Business Use Case

Ask:

What does the system do?
Who uses it?
What business process does it support?
What happens if it is compromised?

Step 2 — Identify Assets

List valuable components.

Example:

Customer Data
Model
API Credentials
Vector Database
Cloud Resources
Source Code

Step 3 — Identify Entry Points

Ask:

Where can someone interact with the system?

Possible entry points:

Web Interface
API
Prompt
File Upload
Document Ingestion
Agent Tool
Admin Interface

Step 4 — Identify Trust Boundaries

Examples:

Internet → Application

Application → LLM Provider

RAG → External Document

Agent → Cloud Account

Step 5 — Identify Privileges

Ask:

Which identities exist?
What can they access?
What privileges does the AI agent have?
What can service accounts do?

Step 6 — Identify Data Flows

Map:

Source
  ↓
Processing
  ↓
Storage
  ↓
Model
  ↓
Output

Sensitive data flows reveal important attack paths.

Step 7 — Identify External Dependencies

List:

AI providers
Cloud services
Third-party APIs
Open-source packages
Models
Plugins

Step 8 — Identify Potential Attack Paths

Example:

Malicious Document
      ↓
RAG
      ↓
Indirect Prompt Injection
      ↓
Agent
      ↓
External Tool

Now you have something to investigate further.

Enterprise Scenario

Consider an enterprise security assistant.

Security Analyst
       │
       ▼
AI Security Assistant
       │
       ├── LLM
       ├── RAG
       │     └── Security Runbooks
       │
       └── Agent
             ├── SIEM
             ├── Cloud Logs
             └── Ticketing

Let’s map the attack surface.

Entry Point 1 — User Prompt

Possible risk:

Prompt manipulation

Entry Point 2 — RAG Documents

Possible risk:

Malicious document instructions

Entry Point 3 — Vector Database

Possible risk:

Unauthorized retrieval

Entry Point 4 — Agent Tools

Possible risk:

Excessive permissions

Entry Point 5 — LLM API

Possible risk:

Credential compromise

Entry Point 6 — Application API

Possible risk:

Broken access control

Entry Point 7 — Cloud Infrastructure

Possible risk:

Misconfiguration

Entry Point 8 — Logs

Possible risk:

Sensitive prompt exposure

The attack surface is much broader than the chatbot interface.

Attack Surface Inventory

A useful inventory might look like:

Component	Entry Point	Asset	Potential Risk
AI Application	Web UI	User Session	Account compromise
LLM API	API	Model Access	Credential misuse
RAG	Search Query	Enterprise Data	Unauthorized retrieval
Vector DB	Database API	Embeddings	Data exposure
AI Agent	Prompt	Tools	Unauthorized action
Cloud	Management API	Infrastructure	Resource compromise
CI/CD	Pipeline	Deployment	Supply-chain compromise

This table becomes useful during threat modeling.

Attack Surface Prioritization

Not every attack surface has equal risk.

Prioritize areas based on:

Exposure
   +
Privilege
   +
Data Sensitivity
   +
Business Impact

For example:

Public Chatbot
   +
No Sensitive Data
   +
No Tools

may present lower impact than:

Internal AI Agent
   +
Production Cloud Access
   +
Administrator Permissions

Privilege significantly changes risk.

High-Risk AI Attack Surfaces

Pay particular attention to systems with:

Sensitive enterprise data
High-privilege agent permissions
Production access
Code execution
External connectivity
Automated actions
Weak human oversight

A useful principle is:

The more authority the AI has, the more carefully its attack surface must be controlled.

Reduce the Attack Surface

Security architecture should reduce unnecessary exposure.

For example:

Bad:

Internet
   ↓
Public Vector Database

Better:

Application
   ↓
Private Network
   ↓
Vector Database

Bad:

AI Agent
   ↓
Administrator Access

Better:

AI Agent
   ↓
Specific Required Permission

Attack surface reduction is one of the strongest security strategies.

Defense in Depth

Attack surfaces cannot always be eliminated.

Instead, apply multiple controls.

Example:

User Input
    ↓
Authentication
    ↓
Authorization
    ↓
Input Controls
    ↓
LLM
    ↓
Output Validation
    ↓
Restricted Tool
    ↓
Human Approval
    ↓
Logging

Each layer reduces potential impact.

Common Beginner Mistakes

Mistake 1 — Looking Only at the Chat Interface

The application backend, APIs, RAG and infrastructure are equally important.

Mistake 2 — Looking Only for AI-Specific Attacks

Traditional vulnerabilities remain relevant.

Mistake 3 — Ignoring Data Ingestion

Malicious content may enter before the user ever interacts with the AI.

Mistake 4 — Ignoring Agent Permissions

Permissions often determine real-world impact.

Mistake 5 — Ignoring Third Parties

External AI services become part of the trust model.

Mistake 6 — Treating Vector Databases as Non-Sensitive

They may contain sensitive information or references to it.

Mistake 7 — Ignoring Administrative Interfaces

AI administration functions can provide high privilege.

Mistake 8 — Ignoring the Supply Chain

Models, libraries and pipelines can introduce compromise before deployment.

AI Security Engineer Attack Surface Checklist

Users

Who can access the system?
Are anonymous users allowed?
Are privileged users separated?

Authentication

How are users authenticated?
Is MFA used?
How are service identities managed?

Authorization

What can each user access?
Are permissions enforced throughout the architecture?
Are agent permissions limited?

Application

What interfaces are exposed?
Are administrative functions protected?
Are file uploads allowed?

APIs

Which APIs exist?
Are they publicly accessible?
Are authentication and rate limits enforced?

Prompts

What untrusted input reaches the model?
Are system prompts protected?
Are secrets stored in prompts?

RAG

What data sources are indexed?
Who can add content?
Is authorization enforced during retrieval?

Vector Database

Is it privately accessible?
Are users or tenants isolated?
Is access logged?

Models

Where are models stored?
Who can modify them?
Are external models trusted?

Training

Who controls the dataset?
Can data be modified?
Is the training environment protected?

Agents

Which tools exist?
What permissions do they have?
Can the AI execute sensitive actions?

Infrastructure

What cloud resources exist?
Are public endpoints necessary?
Are containers and Kubernetes secured?

Secrets

Where are API keys stored?
Are credentials rotated?
Can secrets appear in logs?

Supply Chain

Which dependencies are used?
Where do models come from?
Is CI/CD protected?

Third Parties

Which external AI services are used?
What data is sent externally?
Are vendor risks understood?

Monitoring

Are important activities logged?
Are agent actions visible?
Can suspicious behavior be detected?

Interview Perspective

You may be asked:

What is the attack surface of an AI application?

A strong answer is:

The AI attack surface includes both traditional application and infrastructure entry points and AI-specific components such as prompts, model APIs, RAG pipelines, vector databases, models, agents, tool integrations, training data and model repositories. I would map users, assets, data flows, trust boundaries and privileges to understand how an attacker could move from an entry point to a valuable asset or high-impact action.

Another common question is:

Why are AI agents particularly important during attack surface analysis?

A strong answer is:

AI agents can perform actions using external tools, so their attack surface includes both the model interaction and every system the agent can access. Excessive tool permissions can turn a prompt manipulation issue into a high-impact cloud, database or business-system compromise.

Another question may be:

What is the difference between an attack surface and an attack path?

A strong answer is:

The attack surface is the collection of potential entry and interaction points in the system. An attack path is the sequence an attacker may follow from one of those entry points through weaknesses and trust boundaries to reach an asset or create an impact.

Key Takeaways

An AI system has a much broader attack surface than the LLM alone.

The attack surface can include:

Users
+
Authentication
+
Applications
+
APIs
+
Prompts
+
Context
+
Models
+
RAG
+
Vector Databases
+
Agents
+
Tools
+
Data
+
Cloud Infrastructure
+
Containers
+
Kubernetes
+
CI/CD
+
MLOps
+
Third-Party Services

Attack surface analysis should identify:

Assets
    ↓
Entry Points
    ↓
Trust Boundaries
    ↓
Privileges
    ↓
Attack Paths
    ↓
Potential Impact

The most important mindset is:

Do not ask only how the model can be attacked. Ask how the entire AI ecosystem can be influenced, accessed, manipulated or abused.

What’s Next?

➡️ 06 — AI Security Threat Landscape

You now know where attackers may interact with an AI system.

The next step is understanding who may attack it, why they may attack it and what types of threats they may use.

In the next lesson, you will explore:

AI threat actors
Cybercriminals
Nation-state actors
Malicious insiders
Supply-chain attackers
AI abuse
Data theft
Model theft
Data poisoning
Prompt-based attacks
Agent abuse
Infrastructure attacks
AI-enabled cyberattacks
Emerging enterprise AI threats
Threat likelihood and business impact

You will begin moving from:

Where Can We Be Attacked?
          ↓
Who Might Attack Us?
          ↓
Why?
          ↓
How?
          ↓
What Could the Impact Be?

This will prepare you for OWASP, MITRE ATLAS and formal AI threat modeling.

➡️ Next: 06 — AI Security Threat Landscape