03 AI Assets, Data Classification and Security Objectives

Once you understand the architecture and data flows of an AI system, the next question is:

What are we actually trying to protect?

Threat modeling becomes meaningful only when the organization understands the value and sensitivity of its assets.

In AI environments, those assets may include more than traditional servers, databases and user accounts.

They may also include:

• Models
• Prompts
• System instructions
• Embeddings
• Vector databases
• Training data
• Fine-tuning data
• RAG knowledge sources
• AI agent identities
• Tool permissions
• Model configurations
• Inference outputs
• AI logs

The AI Security Engineer must identify these assets, classify them appropriately and define the security objectives that apply to each one.

Learning Objectives

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

• Explain what an asset is in AI security.
• Identify traditional and AI-specific assets.
• Classify data based on sensitivity.
• Understand why model and prompt assets matter.
• Identify RAG and vector database assets.
• Identify AI agent and credential assets.
• Apply confidentiality, integrity and availability objectives.
• Understand privacy, authenticity, accountability and safety objectives.
• Prioritize critical assets.
• Build an AI Asset Register.
• Connect assets to threat scenarios and later risk assessment.

1. What Is an Asset?

An asset is anything that has value to the organization and therefore requires protection.

Traditional security assets may include:

• Servers
• Databases
• User accounts
• Credentials
• Applications
• Networks
• Business data

AI systems add additional assets.

For example:

AI Application
     │
     ├── Model
     ├── System Prompt
     ├── RAG Data
     ├── Embeddings
     ├── Vector Database
     ├── Agent Identity
     ├── API Credentials
     ├── Model Configuration
     └── Logs

Not all assets have the same value or sensitivity.

That is why classification is important.

2. Why Asset Identification Matters

Consider two different AI applications.

Application A

Public FAQ chatbot using only public information.

Application B

Internal enterprise assistant connected to:

• HR documents

• Customer data

• Security documentation

• Cloud APIs

• Administrative tools

Both may use the same underlying LLM.

But the security risk is very different.

The difference comes largely from:

Assets
+
Data
+
Permissions
+
Business Impact

Threat modeling must therefore begin by understanding what the system can affect.

3. Asset Categories in AI Systems

A useful approach is to group assets into categories.

Business Assets

Examples:

• Customer trust

• Business operations

• Financial processes

• Intellectual property

• Business decisions

• Regulatory obligations

Data Assets

Examples:

• Customer records

• Employee information

• Source code

• Security documentation

• RAG documents

• Training datasets

AI Assets

Examples:

• Models

• Model weights

• System prompts

• Embeddings

• Fine-tuned models

• Model configurations

Identity Assets

Examples:

• User accounts

• Service identities

• AI agent identities

• Administrative identities

Credential Assets

Examples:

• API keys

• Access tokens

• Cloud credentials

• Certificates

• Database passwords

Infrastructure Assets

Examples:

• Cloud accounts

• Containers

• Kubernetes clusters

• Storage

• Databases

• Networks

Security Assets

Examples:

• Logs

• Audit trails

• Security policies

• Detection rules

• Incident evidence

4. Business Assets

Security teams sometimes focus too heavily on technical components.

But ultimately the organization is protecting business outcomes.

Examples include:

Customer Data
     ↓
Customer Trust

Business Systems
     ↓
Business Continuity

Source Code
     ↓
Intellectual Property

AI Decisions
     ↓
Business Reputation

For every technical asset ask:

What business value depends on this asset?

This helps later when evaluating impact.

5. Data Assets

Data is one of the most important asset classes in AI security.

AI systems may process:

• User prompts

• Conversation history

• Customer data

• Employee data

• Source code

• Security findings

• Financial information

• Product information

• Legal documents

• RAG knowledge

• Training data

You should identify both:

Data at Rest
+
Data in Transit
+
Data in Processing

6. User Prompt Data

Prompts may contain sensitive information.

For example:

"Summarize this customer incident."

The user may paste:

• Customer names

• Ticket numbers

• Credentials

• Logs

• Internal architecture

• Security findings

That means user prompts themselves may become sensitive assets.

Questions to ask:

• Are prompts stored?

• Are they logged?

• Are they sent to third parties?

• How long are they retained?

• Who can access them?

7. Conversation History

Many AI applications maintain conversation history.

That history may contain:

User Questions
+
Sensitive Context
+
Model Responses
+
Retrieved Documents

Over time, conversation history can become a valuable collection of sensitive information.

Security considerations include:

• Storage

• Retention

• Access

• Deletion

• Encryption

• Privacy

8. System Prompts

System prompts may contain:

• Application instructions

• Business logic

• Internal policies

• Tool instructions

• Workflow rules

Example:

You are the internal security assistant.
Only respond using approved internal documentation.

System prompts are often treated as sensitive.

However:

Do not treat system-prompt secrecy as a primary security control.

A stronger design assumes system instructions may eventually become known and relies on proper:

• Authorization

• Access control

• Policy enforcement

• Least privilege

9. Models as Assets

Models themselves can be valuable.

Examples:

• Proprietary models

• Fine-tuned models

• Internal models

• Specialized security models

Potential concerns include:

• Model theft

• Unauthorized modification

• Replacement

• Corruption

• Malicious model insertion

If a model contains proprietary training or fine-tuning, its business value may be significant.

10. Model Weights

Model weights may be highly valuable intellectual property.

For an organization operating proprietary models:

Model Weights
     ↓
Restricted Asset

Possible security objectives:

• Prevent unauthorized download.

• Prevent unauthorized modification.

• Maintain integrity.

• Maintain provenance.

• Restrict administrative access.

11. Training Data

Training data influences model behavior.

Potential risks include:

• Unauthorized disclosure

• Poisoning

• Privacy violations

• Incorrect labeling

• Malicious manipulation

For training data, both:

Confidentiality
+
Integrity

can be extremely important.

12. Fine-Tuning Data

Fine-tuning data may contain:

• Internal documents

• Customer conversations

• Support tickets

• Specialized knowledge

• Security procedures

Ask:

• Who selected the data?

• Is sensitive information included?

• Who can modify the dataset?

• Is provenance known?

• Is approval required?

13. RAG Knowledge Sources

RAG systems frequently connect to enterprise data.

Examples:

SharePoint
Knowledge Base
File Storage
Object Storage
Databases
Ticketing Systems
Documentation Repositories

These underlying sources remain assets even after their information is represented in the AI system.

A critical principle is:

AI does not remove the original data classification.

If a source document is confidential, retrieving it through an AI assistant does not make it less confidential.

14. Embeddings

Embeddings are numerical representations of information.

They should not automatically be treated as harmless.

Depending on the implementation and data, embeddings may still require protection.

Questions include:

• What data produced them?

• Where are they stored?

• Who can query them?

• Can they be exported?

• Can metadata reveal sensitive information?

15. Vector Databases

Vector databases may contain:

• Embeddings

• Metadata

• Document references

• Access labels

• Source information

Security objectives may include:

Confidentiality
Integrity
Availability
Authorization

If the vector store is compromised, attackers may:

• Retrieve sensitive knowledge

• Modify embeddings

• Insert malicious content

• Disrupt retrieval

16. AI Agent Identities

An AI agent identity can be one of the most sensitive assets in an AI environment.

Consider:

AI Agent
   ↓
Cloud Service Identity
   ↓
Production APIs

If the identity is compromised or excessively privileged, the attacker may gain access to everything the agent can access.

Therefore the agent identity should be treated similarly to other privileged workload identities.

17. AI Agent Permissions

Permissions themselves should be documented as part of asset and security analysis.

For example:

Agent A
  ├── Read Tickets
  ├── Create Tickets
  └── Read Knowledge Base

versus:

Agent B
  ├── Modify Cloud Infrastructure
  ├── Delete Resources
  └── Change IAM Permissions

The second agent has a much higher security impact.

18. API Credentials

AI applications commonly rely on:

• LLM API keys

• OAuth tokens

• Database credentials

• Cloud access tokens

• Service credentials

These should usually be classified as:

Restricted

Security objectives include:

• Confidentiality

• Rotation

• Least privilege

• Limited lifetime

• Monitoring

19. AI Tool Configurations

AI agents may be configured with access to tools.

Examples:

Email
CRM
Cloud API
Database
Ticketing System
Code Repository

The tool configuration determines the agent’s effective capability.

That configuration is therefore security-relevant.

20. Logs as Assets

Security logs are also assets.

Logs may include:

• User identity

• Prompt metadata

• Agent actions

• Tool calls

• Authorization failures

• API requests

• RAG retrieval events

Logs require protection because they support:

• Detection

• Investigation

• Audit

• Incident response

If an attacker can alter logs, they may hide activity.

21. Security Configurations as Assets

Examples:

• IAM policies

• Network policies

• Agent permission policies

• Security filters

• WAF rules

• Detection rules

These assets require strong integrity.

Unauthorized modification could weaken the security posture without changing application functionality directly.

22. Data Classification

Data classification helps organizations apply appropriate controls based on sensitivity.

A simple model is:

Public
Internal
Confidential
Restricted

Organizations may use different terminology.

The important point is consistency.

23. Public Data

Information intended for unrestricted public access.

Examples:

• Public product information

• Public website content

• Published documentation

Typical security concerns:

• Integrity

• Availability

Confidentiality may be less important.

24. Internal Data

Information intended for employees or trusted users.

Examples:

• Internal procedures

• General internal documentation

• Team information

Unauthorized disclosure may have limited but meaningful impact.

25. Confidential Data

Information where unauthorized disclosure could significantly affect the organization.

Examples:

• Customer records

• Internal architecture

• Security documentation

• Business strategy

• Source code

Stronger access controls are usually required.

26. Restricted Data

The highest sensitivity level.

Examples:

• Credentials

• Private keys

• Highly sensitive personal information

• Administrative secrets

• Critical production credentials

Access should be highly controlled.

27. Example AI Data Classification

Asset	Example Classification
Public FAQ content	Public
Internal company policies	Internal
Security architecture	Confidential
Customer database	Confidential
API keys	Restricted
Production credentials	Restricted
Agent administrative token	Restricted

Your organization may classify these differently.

The purpose is to understand relative sensitivity.

28. Classification Must Follow the Data

Suppose:

Confidential Document
        ↓
RAG Ingestion
        ↓
Embedding
        ↓
Vector Database
        ↓
LLM Context

The document does not become “less sensitive” because it has moved through the AI pipeline.

Security teams should consider classification throughout the entire flow.

29. Confidentiality

Confidentiality means protecting information from unauthorized disclosure.

In AI systems, confidentiality threats may include:

• Unauthorized RAG retrieval

• Prompt-based data leakage

• Credential exposure

• Model data leakage

• Cross-user information exposure

• Log exposure

Example security objective:

Only authorized HR employees may access HR-related content through the AI assistant.

30. Integrity

Integrity means protecting information and systems from unauthorized modification.

AI integrity concerns include:

• Knowledge poisoning

• Training-data poisoning

• Model modification

• System prompt changes

• Vector-store manipulation

• Agent configuration changes

Example objective:

Only approved sources may modify the enterprise AI knowledge base.

31. Availability

Availability means ensuring systems and information remain accessible when required.

AI availability risks may include:

• Resource exhaustion

• Excessive token consumption

• Model provider outage

• Denial-of-service attacks

• Infrastructure failure

• Vector database outage

Example objective:

The customer support assistant must remain available during business-critical periods.

32. CIA Applied to AI

A useful starting model is:

               AI ASSET
                  │
      ┌───────────┼───────────┐
      │           │           │
      ▼           ▼           ▼
Confidentiality Integrity Availability

But AI systems often need additional objectives.

33. Privacy

Privacy is especially important when AI systems process personal information.

Questions include:

• Is personal information required?

• Has consent or another lawful basis been established where applicable?

• How long is the data retained?

• Is data sent to external providers?

• Can users request deletion?

Example objective:

Personal information should be processed only for the approved business purpose and retained only as required.

34. Authenticity

Authenticity concerns whether something is genuinely what it claims to be.

Examples:

• Is this model the approved model?

• Did this document come from an approved source?

• Is this user really the expected user?

• Is this API response genuine?

This is particularly relevant for:

• Models

• Datasets

• Software packages

• Documents

• External services

35. Accountability

Accountability means being able to determine who or what performed an action.

AI systems may involve:

User
+
Application
+
Agent
+
Tool

Logs should ideally allow investigators to determine:

Which user initiated the request?

Which agent acted?

Which tool was used?

What action occurred?

What resource was affected?

36. Safety

Safety becomes important when AI actions can cause harm beyond information security.

Examples:

• Dangerous automated actions

• Incorrect high-impact decisions

• Unsafe operational instructions

• Uncontrolled physical actions

Not every AI system is safety-critical.

But security teams should identify when safety objectives apply.

37. Reliability

AI systems may produce incorrect or inconsistent responses.

Reliability concerns include:

• Misinformation

• Hallucination

• Incorrect automation

• Inconsistent decisions

In some business contexts, this may become an important risk.

38. Human Oversight as a Security Objective

For high-impact workflows, organizations may require:

Certain AI-generated actions must be reviewed by a human.

Example:

AI Recommendation
       ↓
Human Review
       ↓
Business Decision

or:

AI Agent
   ↓
Proposed Administrative Change
   ↓
Human Approval
   ↓
Execution

Human oversight can be an important risk-reduction control.

39. Asset Criticality

Classification and criticality are related but different.

A system might process public information but still be business-critical.

Example:

Public customer support assistant used by millions of users.

Data sensitivity may be low.

Availability requirement may be very high.

Therefore assess:

Sensitivity
+
Business Criticality

40. Example Criticality Model

Low

Limited business impact.

Medium

Noticeable operational impact.

High

Major business or security impact.

Critical

Severe impact to:

• Customers

• Business operations

• Financial systems

• Safety

• Regulatory obligations

41. Identify Asset Owners

Every important asset should have an owner.

Examples:

Asset	Owner
Customer Data	Business / Data Owner
AI Application	Product Team
Model	AI Team
Cloud Platform	Platform Team
Security Logs	Security Operations
Agent Identity	Platform / AI Team

Ownership matters because somebody must make decisions about:

• Access

• Classification

• Retention

• Risk acceptance

• Remediation

42. Identify Custodians

The asset owner and technical custodian may differ.

For example:

Customer Data

Business Owner:
Customer Operations

Technical Custodian:
Data Platform Team

Security engineers should understand both.

43. Create an AI Asset Register

A useful asset register may contain:

ID	Asset	Type	Owner	Classification	Criticality	Security Objectives
A-01	Customer Data	Data	Customer Team	Confidential	High	C, I, P
A-02	LLM API Key	Credential	AI Team	Restricted	High	C, I
A-03	Vector DB	Data Store	AI Team	Confidential	High	C, I, A
A-04	Agent Identity	Identity	Platform	Restricted	Critical	C, I, A
A-05	Security Logs	Security	SOC	Confidential	High	I, A

Where:

C = Confidentiality
I = Integrity
A = Availability
P = Privacy

You may extend the model as required.

44. Connect Assets to Architecture

Do not maintain the asset register separately from the architecture.

Example:

Employee
   ↓
Application
   ↓
RAG
   ↓
Vector Database
   ↓
Confidential Documents

Now identify:

A-01 Employee Identity
A-02 Application
A-03 Vector Database
A-04 Confidential Documents

This creates traceability.

45. Connect Assets to Data Flows

Suppose:

DF-03
RAG → LLM

Data:

Confidential Enterprise Documentation

Now you can state:

Flow DF-03 contains Asset A-04.

This is useful when later identifying threats and controls.

46. Identify Crown Jewels

Not every asset deserves equal attention.

Identify the organization’s most critical AI-related assets.

Examples:

Restricted Customer Data
Production Agent Identity
Administrative API Credentials
Proprietary Model Weights
Critical Business Knowledge

These may become crown jewel assets.

Threat paths leading to these assets should receive additional attention.

47. Example Crown Jewel Analysis

Consider:

Crown Jewel:
Production Cloud Administrator Role

The AI agent should not normally have direct access to this role.

If the architecture shows:

AI Agent
   ↓
Administrative Cloud Credential

this should immediately attract attention.

48. Impact of Asset Compromise

For every critical asset ask:

Confidentiality Compromise

What happens if it is disclosed?

Integrity Compromise

What happens if it is modified?

Availability Compromise

What happens if it becomes unavailable?

Example:

Asset:
RAG Knowledge Base

Confidentiality Failure:
Internal information exposed.

Integrity Failure:
AI produces manipulated answers.

Availability Failure:
Assistant cannot retrieve knowledge.

49. Asset Compromise Matrix

Create:

Asset	Confidentiality Impact	Integrity Impact	Availability Impact
Customer Data	Critical	High	Medium
Model	Medium	Critical	High
Vector DB	High	High	High
Agent Credential	Critical	Critical	High
Logs	High	Critical	High

This helps later risk prioritization.

50. Example — Enterprise Knowledge Assistant

Consider:

Employee
   ↓
AI Assistant
   ↓
RAG
   ↓
Internal Documents

Potential assets:

Employee Identity
AI Application
System Prompt
LLM
RAG Service
Vector Database
Enterprise Documents
API Credentials
Logs

Now add:

AI Agent
   ↓
Cloud API

New critical assets appear:

Agent Identity
Cloud Permissions
Cloud API Tokens
Production Resources
Agent Configuration

Architecture changes create new assets.

51. Example — Security Operations AI Assistant

Imagine an AI assistant used by the SOC.

It may access:

• Security alerts

• SIEM logs

• Incident cases

• Threat intelligence

• Endpoint data

• Cloud logs

Security concerns include:

Confidentiality

Attackers should not retrieve sensitive incident data.

Integrity

Attackers should not poison investigation context.

Availability

SOC analysts need access during incidents.

Accountability

AI-assisted actions must remain traceable to the analyst.

52. Example — AI Coding Assistant

Potential assets:

• Source code

• Secrets

• Proprietary algorithms

• Repository credentials

• Build pipelines

Security objectives:

Protect Source Code
Protect Credentials
Prevent Unauthorized Code Changes
Maintain Repository Integrity

The asset model changes according to the business use case.

53. Security Objectives Must Be Testable

Avoid vague objectives such as:

Protect sensitive information.

Prefer:

Only users authorized for the source document may retrieve its contents through the RAG application.

Now the objective can be tested.

Another example:

Weak:

Protect AI agents.

Better:

The AI agent must use a dedicated identity with permissions limited to the approved tools and operations required by the business workflow.

54. Convert Objectives Into Requirements

The process is:

Asset
  ↓
Security Objective
  ↓
Security Requirement
  ↓
Security Control
  ↓
Validation

Example:

Asset:
HR Documents

Security Objective:
Confidentiality

Requirement:
Only HR-authorized users may retrieve HR content.

Control:
Document-level authorization.

Validation:
Attempt retrieval using an unauthorized account.

55. Asset-Based Threat Modeling

Once assets are identified, threats become easier to structure.

Ask:

Who would want this asset?

How could they reach it?

What could they do to it?

Example:

Asset:
API Credential

Threat:
Credential Theft

Attack Path:
Source Code Repository
   ↓
Hardcoded Credential
   ↓
Attacker

56. Asset-Driven Attack Paths

Consider a critical asset:

Customer Database

Now work backward.

Customer Database
      ↑
Enterprise API
      ↑
AI Agent
      ↑
LLM Decision
      ↑
User Input

Now ask:

Could an attacker influence the path from user input to the critical asset?

This is a powerful threat modeling technique.

57. Asset Dependencies

Assets may depend on other assets.

Example:

AI Application
      ↓
Depends On
      ↓
LLM API Credential
      ↓
Depends On
      ↓
Secret Management System

If the secrets platform fails, the AI application may be affected.

Dependency analysis helps identify hidden risks.

58. Asset Lifecycle

Assets change over time.

Consider:

Create
  ↓
Store
  ↓
Use
  ↓
Share
  ↓
Archive
  ↓
Delete

Security controls should cover the entire lifecycle.

For AI data, also consider:

Collect
  ↓
Ingest
  ↓
Embed
  ↓
Retrieve
  ↓
Generate
  ↓
Retain

59. Data Retention

Ask:

• How long are prompts stored?

• How long are model outputs stored?

• Are embeddings retained?

• Can user conversations be deleted?

• Are logs retained according to policy?

Keeping information indefinitely creates additional risk.

60. Data Minimization

A key principle is:

Do not provide the AI system with data it does not need.

Example:

Instead of allowing access to:

Entire Customer Database

provide access to:

Required Customer Fields Only

This reduces potential impact.

61. Data Segmentation

Sensitive datasets may require segmentation.

Example:

Enterprise Knowledge
      │
      ├── General
      ├── Engineering
      ├── HR
      └── Executive

Access should reflect user authorization.

AI should not collapse all segments into one unrestricted knowledge pool.

62. Model Provenance as an Asset Property

For models, track:

• Source

• Version

• Owner

• Approval

• Integrity

• Deployment location

Example:

Model	Source	Version	Approved
Internal Assistant Model	Approved Registry	v3	Yes

This supports supply-chain security.

63. Dataset Provenance

For datasets, track:

• Origin

• Owner

• Approval

• Date

• Integrity

• Classification

If the organization cannot determine where training or RAG data came from, security and governance become difficult.

64. Security Objectives by Asset Type

A simple reference:

Asset Type	Important Objectives
Credentials	Confidentiality, Integrity
Business Data	Confidentiality, Integrity, Privacy
Models	Integrity, Availability, Authenticity
RAG Data	Confidentiality, Integrity
Vector DB	Confidentiality, Integrity, Availability
AI Agent	Integrity, Accountability, Least Privilege
Logs	Integrity, Availability, Confidentiality
Production Services	Integrity, Availability

This is not universal.

Adjust according to the system.

65. Priority Questions for Every Asset

Ask:

What Is It?

Why Is It Valuable?

Who Owns It?

Where Is It Stored?

Who Can Access It?

How Is It Used?

What Depends on It?

What Happens If It Leaks?

What Happens If It Changes?

What Happens If It Disappears?

These questions build the security objective.

66. Common Asset Identification Mistakes

Mistake 1 — Listing Only Data

AI models, identities, permissions and logs are also assets.

Mistake 2 — Ignoring Prompts

Prompts can contain sensitive information.

Mistake 3 — Ignoring Agent Credentials

Agent credentials may provide access to highly privileged systems.

Mistake 4 — Treating Embeddings as Automatically Non-Sensitive

Their sensitivity depends on the source data and implementation.

Mistake 5 — Forgetting Business Assets

Security exists to protect business outcomes.

Mistake 6 — Applying One Classification to Everything

Different assets have different sensitivity and impact.

Mistake 7 — Ignoring Integrity

AI security discussions often focus on data leakage, but manipulated AI data can be equally damaging.

67. Build an AI Asset Register

Create a file:

AI-Asset-Register.md

Use:

# AI Asset Register

## System

## Business Owner

## Assessment Scope

| ID | Asset | Category | Owner | Location | Classification | Criticality | C | I | A | Privacy | Notes |
|---|---|---|---|---|---|---|---|---|---|---|---|

## Crown Jewel Assets

## Sensitive Data Assets

## Privileged Identities

## External Dependencies

## Key Observations

68. Example AI Asset Register

ID	Asset	Classification	Criticality	C	I	A
A-01	Employee Identity	Internal	High	H	H	M
A-02	HR Documents	Confidential	High	H	H	M
A-03	LLM API Key	Restricted	Critical	H	H	M
A-04	Vector DB	Confidential	High	H	H	H
A-05	Agent Identity	Restricted	Critical	H	H	H
A-06	AI Logs	Confidential	High	M	H	H

Where:

H = High
M = Medium
L = Low

69. Create a Security Objectives Register

Create:

AI-Security-Objectives.md

Example:

# AI Security Objectives

## SO-01 — Protect Enterprise Data Confidentiality

Only authorized users and workloads may access confidential enterprise data.

## SO-02 — Protect Knowledge Base Integrity

Only approved identities may modify RAG knowledge sources.

## SO-03 — Restrict AI Agent Capability

AI agents must operate using least-privilege identities and approved tools.

## SO-04 — Maintain AI Activity Accountability

Security-relevant AI actions must be attributable to the initiating user and workload.

## SO-05 — Protect Production Availability

AI workloads must implement appropriate availability and resource controls.

70. Connect Assets to Security Objectives

Example:

Asset	Objective
Customer Data	Prevent unauthorized disclosure
RAG Documents	Prevent unauthorized modification
Agent Identity	Prevent privilege misuse
Logs	Preserve integrity and availability
AI Application	Maintain availability

This creates a bridge to the next stages of threat modeling.

71. Connect Assets to Threats

Later your model will evolve into:

Asset
  ↓
Threat
  ↓
Attack Path
  ↓
Risk
  ↓
Control

Example:

Asset:
Agent Credential

Threat:
Credential Compromise

Attack Path:
Exposed Secret
   ↓
Attacker
   ↓
Agent Identity
   ↓
Enterprise API

Impact:
Unauthorized Enterprise Actions

72. Real-World Security Engineer Perspective

During an enterprise architecture review, you may ask:

What sensitive assets does this AI system access?

The team may answer:

“It’s just an internal chatbot.”

Your job is to continue asking.

For example:

What documents can it retrieve?

What credentials does it use?

Does it connect to external AI providers?

Can it take actions?

What does it log?

The architecture may eventually reveal:

Internal Chatbot
       ↓
RAG
       ↓
Customer Data
       +
Security Documentation
       +
Privileged AI Agent

The asset analysis completely changes the security assessment.

73. Asset Analysis Mindset

Whenever you see an AI system, train yourself to ask:

What Is Valuable?
       ↓
Where Is It?
       ↓
Who Owns It?
       ↓
Who Can Access It?
       ↓
How Sensitive Is It?
       ↓
How Critical Is It?
       ↓
What Must Remain Confidential?
       ↓
What Must Remain Accurate?
       ↓
What Must Remain Available?
       ↓
What Happens If It Is Compromised?

74. Knowledge Check

Before moving forward, make sure you can answer:

Question 1

What is an asset?

Question 2

Why are business assets important during threat modeling?

Question 3

Why can prompts become sensitive assets?

Question 4

Why should system prompts not be treated as primary access-control mechanisms?

Question 5

What security objectives commonly apply to vector databases?

Question 6

Why are AI agent identities important assets?

Question 7

What is the difference between data classification and business criticality?

Question 8

How does confidentiality apply to an AI system?

Question 9

How does integrity apply to RAG?

Question 10

Why is accountability important for AI agents?

Question 11

What is a crown jewel asset?

Question 12

Why should asset analysis be connected to architecture and data flows?

If you can answer these clearly, you are ready to begin analyzing trust relationships between these assets.

Key Takeaways

Effective AI threat modeling requires understanding:

What We Value
      +
How Sensitive It Is
      +
How Critical It Is
      +
Who Owns It
      +
Who Can Access It
      +
What Security Objectives Apply

AI systems introduce important new asset types, including:

• Models

• Prompts

• Embeddings

• Vector databases

• AI agent identities

• RAG knowledge

• Model configurations

But traditional assets remain equally important:

• Credentials

• Business data

• Cloud infrastructure

• APIs

• Logs

The core principle is:

You cannot prioritize AI threats effectively until you know which assets matter most and what security properties must be protected.

The asset register now gives you the foundation required to identify where trust changes across the architecture.

What’s Next?

➡️ 04 — Trust Boundaries in AI Systems

You now understand:

• What the important AI assets are.

• How sensitive those assets may be.

• Which assets are business-critical.

• What confidentiality, integrity and availability mean in AI systems.

• How privacy, authenticity and accountability extend those objectives.

• How to build an AI Asset Register.

The next step is to understand where trust changes between users, AI components, data sources, third-party services and privileged systems.

In the next lesson, you will learn how to:

• Define trust boundaries.

• Identify user-to-application trust boundaries.

• Identify application-to-LLM boundaries.

• Identify enterprise-to-third-party boundaries.

• Identify RAG trust boundaries.

• Identify AI agent privilege boundaries.

• Understand trusted vs untrusted AI context.

• Identify privilege transitions.

• Map controls to trust boundaries.

• Document trust boundaries for threat modeling.

The goal is to move from:

“I know what assets need protection.”

to:

“I know where those assets cross security boundaries and where stronger controls are required.”

➡️ Next: 04 — Trust Boundaries in AI Systems