13 Mapping Threats to Security Controls

By this point in the module, you have learned how to:

• Identify AI assets
• Map data flows
• Identify trust boundaries
• Identify threat actors
• Map attack surfaces
• Apply STRIDE
• Apply OWASP GenAI guidance
• Use MITRE ATLAS
• Threat model RAG
• Threat model AI agents
• Build attack paths and abuse cases
• Prioritize threats and assess risk

The next question is:

What security controls should we implement to reduce those risks?

Threat modeling becomes useful only when it leads to practical engineering decisions.

A strong threat model should help the organization move from:

Threat Identified

to:

Threat
  ↓
Attack Path
  ↓
Security Control
  ↓
Security Requirement
  ↓
Implementation
  ↓
Validation

This lesson focuses on that transition.

Learning Objectives

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

• Explain the purpose of threat-to-control mapping.

• Distinguish preventive, detective and responsive controls.

• Map controls to attack paths.

• Identify control breakpoints.

• Apply defense in depth.

• Map identity controls to AI threats.

• Map authorization and least-privilege controls.

• Map RAG security controls.

• Map AI agent security controls.

• Map data-protection controls.

• Map supply-chain controls.

• Map cloud and infrastructure controls.

• Define logging and monitoring requirements.

• Create security requirements from threats.

• Define control validation criteria.

• Build a Threat-to-Control Matrix.

• Evaluate residual risk after controls are applied.

1. Why Threat-to-Control Mapping Matters

A threat model that identifies risks but does not lead to security action is incomplete.

For example:

The AI agent may perform unauthorized production actions.

This is useful.

But engineering needs to know:

What exactly should we implement?

The next step is to map the threat to controls such as:

User Authorization
      +
Least-Privilege Agent Identity
      +
Tool Restrictions
      +
Parameter Validation
      +
Human Approval
      +
Logging

Now the finding becomes actionable.

2. Start With the Attack Path

Do not select controls randomly.

Start with the attack path.

Example:

Compromised Employee
       ↓
AI Agent
       ↓
Privileged Tool
       ↓
Production Cloud

Now ask:

Where can we interrupt this path?

Potential points include:

Compromised Employee
       ↓
[Conditional Access]
       ↓
AI Agent
       ↓
[User Authorization]
       ↓
Privileged Tool
       ↓
[Least Privilege]
       ↓
Production Cloud

This is control mapping.

3. Control Breakpoints

A control breakpoint is a point in an attack path where a security control can:

• Stop the attack

• Reduce likelihood

• Reduce impact

• Detect activity

• Enable containment

A single path may contain several breakpoints.

Example:

Malicious Document
       ↓
[Source Governance]
       ↓
RAG Ingestion
       ↓
[Content / Integrity Controls]
       ↓
LLM
       ↓
AI Agent
       ↓
[Policy Enforcement]
       ↓
Tool

This creates defense in depth.

4. Preventive Controls

Preventive controls attempt to stop the threat before impact occurs.

Examples include:

• Authentication

• Authorization

• Least privilege

• Network restriction

• Input validation

• Tool allowlisting

• Data segmentation

• Human approval

• Rate limits

Their goal is:

Prevent the attack path from progressing.

5. Detective Controls

Detective controls help identify suspicious or unauthorized behavior.

Examples include:

• Authentication alerts

• RAG retrieval monitoring

• Agent tool-call monitoring

• Cloud audit logs

• Model registry monitoring

• SIEM rules

• Behavior analytics

Their goal is:

Identify the attack when prevention fails or suspicious behavior begins.

6. Responsive Controls

Responsive controls help contain and recover from incidents.

Examples include:

• Disable account

• Disable agent identity

• Revoke tokens

• Block tool access

• Remove malicious RAG content

• Roll back model

• Restore configuration

• Isolate workload

Their goal is:

Reduce damage after suspicious activity is identified.

7. Prevent → Detect → Respond

For every important AI threat, try to identify controls across all three areas.

Example:

Threat	Prevent	Detect	Respond
Unauthorized RAG retrieval	Document authorization	Retrieval anomalies	Disable user/session
RAG poisoning	Source governance	Document-change alerts	Remove content/reindex
Agent privilege abuse	Least privilege	Tool-call monitoring	Disable agent
Credential compromise	MFA / managed identity	Authentication anomaly	Revoke token
Model tampering	Integrity validation	Registry monitoring	Roll back model

This creates operational security, not just architecture security.

8. Defense in Depth

Do not rely on one security control.

Consider:

User
 ↓
AI Agent
 ↓
Production

Weak approach:

System Prompt:
"Do not perform unauthorized actions."

Stronger approach:

User Authentication
      ↓
User Authorization
      ↓
Agent Tool Restrictions
      ↓
Least-Privilege Identity
      ↓
Parameter Validation
      ↓
Approval
      ↓
Production API Authorization

Each layer reduces dependence on another.

9. AI Models Should Not Be Primary Security Controls

This principle should remain central:

Critical security decisions should be enforced outside the LLM whenever possible.

Avoid:

LLM Decides User Is Authorized
       ↓
Action Executed

Prefer:

LLM Proposes Action
       ↓
Trusted Authorization Layer
       ↓
Policy Check
       ↓
Execution

The model can assist.

Trusted systems should enforce.

10. Map Identity Threats to Controls

Threat:

Attacker impersonates an employee.

Potential controls:

Prevent

• MFA

• SSO

• Conditional access

• Session protection

• Strong credential policies

Detect

• Impossible travel

• Unusual sign-in behavior

• New device alerts

• Session anomalies

Respond

• Revoke session

• Disable account

• Reset credential

11. Map Agent Identity Threats

Threat:

Agent credential is compromised.

Potential controls:

Prevent

• Managed workload identities

• Short-lived credentials

• Secrets management

• Least privilege

Detect

• Unexpected API usage

• New source location

• abnormal agent activity

Respond

• Disable identity

• Revoke token

• Rotate credential

• Block tool access

12. Authentication Is Not Enough

Consider:

Authenticated Employee
       ↓
RAG
       ↓
Restricted HR Data

Authentication confirms identity.

It does not prove the user should access the HR data.

Therefore:

Authentication
       +
Authorization

must be separated.

13. Authorization Controls

Authorization should be applied to:

• Users

• Data

• APIs

• Tools

• Actions

• Resources

Example:

User
 ↓
AI Assistant
 ↓
RAG
 ↓
Document Authorization
 ↓
Allowed Documents

This is much stronger than relying on the model to decide what the user may see.

14. User-Context Authorization for Agents

Consider:

Normal Employee
      ↓
Privileged Agent

A dangerous design checks only:

Can Agent Perform Action?

A stronger design asks:

Can User Perform Action?
        +
Can Agent Perform Action?
        +
Is Target Resource Allowed?

All three may need validation.

15. Least Privilege

Least privilege is one of the most important AI agent controls.

Threat:

Agent compromise leads to broad production impact.

Control:

Restrict the agent to only the permissions required.

Before:

AI Agent
 ↓
AdministratorAccess

After:

AI Agent
 ↓
Read Security Findings

The attack surface may remain.

The blast radius is greatly reduced.

16. Tool Restriction

Agent capability depends on more than IAM.

An agent may have multiple tools:

AI Agent
   ├── Read Data
   ├── Send Email
   ├── Delete Data
   └── Admin Cloud

If only search is required, remove unnecessary tools.

Prefer:

AI Agent
   └── Read Approved Security Data

Removing capability may eliminate entire attack paths.

17. Tool Allowlisting

Use an explicit list of approved tools.

Example:

Allowed:
- SearchKnowledge
- ReadFinding
- CreateTicket

Not:

Allow any available tool.

This reduces uncontrolled functionality.

18. Parameter Validation

Even an approved tool can be abused through dangerous parameters.

Example:

Tool:
DeleteResource

The request may target:

production-database

Control:

Agent
 ↓
Tool Request
 ↓
Parameter Validation
 ↓
Allowed Resource?
 ↓
Execution

Validate:

• Target

• Operation

• Scope

• Quantity

• Destination

19. Human Approval

Human approval can be useful for high-risk actions.

Examples:

• IAM changes

• Data deletion

• Production deployment

• External data transfer

• Financial transactions

Pattern:

AI Agent
 ↓
Proposed Action
 ↓
Human Approval
 ↓
Execution

Approval should provide enough context for meaningful review.

20. Human Approval Is Not a Universal Fix

Approval can fail when:

• Reviewers approve automatically

• Context is unclear

• Alerts are too frequent

• Users do not understand impact

Therefore approval should be used selectively for meaningful high-impact decisions.

21. Map Prompt Injection to Controls

Threat:

Untrusted instructions influence AI behavior.

Potential controls should focus on impact reduction.

Prevent

• Context separation

• Restricted tools

• Authorization outside the model

• Least privilege

• Treat external content as untrusted

Detect

• Suspicious interaction monitoring

• Unusual agent tool usage

• Content-to-action correlation

Respond

• Disable session

• Disable agent

• Review related actions

The key point is:

Prompt filtering alone should not be the security strategy.

22. Map Indirect Prompt Injection

Attack path:

Malicious Document
       ↓
RAG
       ↓
LLM
       ↓
Agent
       ↓
Tool

Possible controls:

Source Governance
      +
Content Provenance
      +
Treat Retrieved Content as Untrusted
      +
Restricted Agent Tools
      +
Independent Authorization
      +
Approval

Multiple controls are necessary because no single control guarantees model behavior.

23. RAG Source Governance

Threat:

Malicious or unauthorized content enters the knowledge base.

Controls include:

• Approved data sources

• Restricted contributors

• Content ownership

• Review workflows

• Version control

• Change logging

• Provenance

High-impact RAG knowledge deserves stronger governance.

24. RAG Ingestion Controls

Secure the ingestion process using:

• Dedicated service identity

• Write restrictions

• Approved sources

• Data classification

• Malware scanning where appropriate

• Logging

• Integrity checks

Threat modeling should include the complete ingestion path.

25. RAG Retrieval Authorization

One of the most important RAG controls is:

Preserve user authorization when retrieving knowledge.

Pattern:

User Identity
      ↓
Authorization
      ↓
Allowed Knowledge Scope
      ↓
Vector Retrieval

Not:

User Logged In
      ↓
Search Everything

26. Data Segmentation

Segmentation reduces exposure and blast radius.

Instead of:

One Vector Database
 ↓
All Enterprise Knowledge

consider logical or physical separation:

General Knowledge
HR Knowledge
Security Knowledge
Executive Knowledge

with appropriate authorization.

27. Metadata Integrity

If authorization depends on metadata such as:

Department = HR
Classification = Confidential

protect that metadata from tampering.

Controls may include:

• Restricted write access

• Integrity monitoring

• Source-derived permissions

• Change audit

28. RAG Deletion Controls

Threat:

Deleted source information remains accessible in RAG.

Requirement:

Source Deleted
      ↓
Index Updated
      ↓
Vector Record Removed

Create defined deletion and retention processes.

29. RAG Provenance

Maintain information such as:

• Source document

• Version

• Owner

• Classification

• Ingestion date

Provenance supports both:

• Trust decisions

• Incident investigation

30. Sensitive Information Protection

Threat:

AI exposes confidential information.

Controls may include:

• Data classification

• Authorization

• Data minimization

• Segmentation

• Output controls

• DLP where appropriate

• Provider governance

Always focus first on preventing unauthorized access to the underlying data.

31. Data Minimization

A strong security principle is:

Do not give the AI access to data it does not need.

Before:

Agent
 ↓
Entire Customer Database

After:

Agent
 ↓
Approved Customer Fields

Reducing available data reduces potential impact.

32. Secrets Management

Threat:

AI credentials are exposed.

Controls include:

• Secret management platform

• Managed identity

• No hardcoded credentials

• Short-lived tokens

• Rotation

• Audit logs

Never place:

• API keys

• Passwords

• Private keys

inside prompts or source code unnecessarily.

33. External Model Provider Controls

When data crosses to a third-party model provider, consider:

• Data classification

• Encryption

• Contractual requirements

• Retention

• Privacy

• Data residency

• Provider security

• Access controls

The external provider represents an organizational trust boundary.

34. Output Validation

Threat:

Model output is automatically trusted by downstream systems.

Control:

LLM Output
    ↓
Validation
    ↓
Policy Enforcement
    ↓
Destination

Output validation may be necessary for:

• SQL

• Code

• URLs

• API parameters

• Commands

• Structured data

35. Code Execution Controls

If an AI system can execute code, apply stronger controls.

Example:

LLM
 ↓
Generated Code
 ↓
Sandbox
 ↓
Restricted Execution

Potential controls include:

• Sandboxing

• Network restrictions

• Resource limits

• No production credentials

• Approval

• Execution logging

36. Resource Limits

Threat:

AI workload is abused for denial of service or excessive cost.

Controls include:

• Rate limits

• Token limits

• Request quotas

• Timeouts

• Tool-call limits

• Agent iteration limits

• Cost budgets

Apply them at appropriate levels:

User
Agent
API
Tool

37. Agent Loop Controls

Threat:

Agent
 ↓
Tool
 ↓
Agent
 ↓
Tool
 ↓
...

Controls may include:

• Maximum iterations

• Maximum tool calls

• Execution timeout

• Token limit

• Cost limit

• Failure threshold

38. Supply-Chain Controls

Threats may enter through:

• Software packages

• Models

• Datasets

• Containers

• Plugins

Controls include:

• Approved repositories

• Dependency inventory

• Vulnerability scanning

• Model provenance

• Container scanning

• Artifact integrity

• Deployment approvals

39. Model Integrity Controls

Threat:

Approved model is replaced or modified.

Controls include:

Approved Model Registry
        ↓
Integrity Validation
        ↓
Deployment Approval
        ↓
Production

Also consider:

• Version tracking

• Access restrictions

• Change logs

• Rollback

40. Dataset Integrity Controls

Threat:

Training or fine-tuning data is poisoned.

Controls may include:

• Dataset provenance

• Restricted modification

• Review workflows

• Change control

• Data quality checks

• Versioning

41. Cloud Infrastructure Controls

AI still depends on traditional cloud controls.

Examples:

• IAM

• Network segmentation

• Private endpoints

• Encryption

• Audit logging

• Secrets management

• Cloud security monitoring

An AI-specific threat may eventually depend on a traditional cloud misconfiguration.

42. Container Controls

If AI workloads use containers:

• Trusted images

• Vulnerability scanning

• Non-root execution

• Resource limits

• Restricted filesystem

• Image provenance

• Secret protection

43. Kubernetes Controls

For Kubernetes-hosted AI:

• RBAC

• Workload identities

• Network policies

• Pod security

• Admission controls

• Audit logging

• Secret management

Threat models should map AI workloads to these existing infrastructure controls.

44. Network Controls

Use network controls to reduce unnecessary paths.

Example:

Before:

AI Agent
 ↓
Any Internet Destination

After:

AI Agent
 ↓
Approved APIs Only

Potential controls:

• Egress filtering

• Private networking

• Firewalls

• Network policies

• Service endpoints

45. Egress Controls

Egress is especially important for AI agents.

Threat:

Agent exfiltrates information through external tools.

Possible controls:

• Restricted destinations

• DLP

• Proxy controls

• Approved API list

• External transfer approval

• Network monitoring

46. Logging Controls

Logging should support reconstruction of AI activity.

Important events may include:

• Authentication

• Authorization decisions

• RAG retrieval

• RAG ingestion

• Model/configuration changes

• Agent tool calls

• Approval

• Administrative changes

47. Agent Audit Requirements

For high-risk agents, capture:

Initiating User
      ↓
Agent Identity
      ↓
Request
      ↓
Tool
      ↓
Parameters
      ↓
Authorization Decision
      ↓
Approval
      ↓
Result

This supports accountability and incident response.

48. Protect Security Logs

Logs themselves require:

• Access control

• Integrity protection

• Retention

• Centralization

• Availability

Attackers should not easily erase evidence.

49. Detection Requirements

Threat modeling should generate detection requirements.

Example threat:

User attempts large-scale RAG collection.

Detection requirement:

Alert on abnormal retrieval volume or unusual cross-domain document access.

Another:

AI agent performs unexpected cloud administration.

Detection requirement:

Alert when high-risk agent tools are invoked outside approved user roles or workflows.

50. Detection Mapping

Create:

Threat	Telemetry	Detection
Account compromise	Identity logs	Sign-in anomaly
RAG poisoning	Document logs	Unexpected source changes
RAG collection	Retrieval logs	High-volume sensitive access
Agent abuse	Tool logs	Unusual tool invocation
Model tampering	Registry logs	Unauthorized model change
Cloud impact	Cloud audit	Unexpected production action

51. Response Controls

Every critical threat should have a containment strategy.

Examples:

User Compromise

Disable Account
Revoke Sessions

Agent Compromise

Disable Workload Identity
Block Tool Access

RAG Poisoning

Remove Source
Rebuild Index

Model Compromise

Stop Deployment
Rollback Model

Cloud Compromise

Revoke Credentials
Isolate Workload
Restore Configuration

52. Kill Switches

High-impact AI agents should have a clear emergency disable mechanism.

Possible methods:

• Disable service identity

• Disable agent

• Revoke token

• Block tool endpoint

• Apply emergency deny policy

The security team should know:

How do we stop this agent immediately?

53. Fail-Safe Defaults

When a security dependency fails, prefer safe failure.

Example:

Authorization Service Failure
       ↓
DENY

not:

Authorization Service Failure
       ↓
ALLOW

This is especially important for high-impact automated actions.

54. Threat-to-Control Mapping

A simple mapping might look like:

Threat	Preventive Controls	Detective Controls	Responsive Controls
Unauthorized RAG Retrieval	Document authz	Retrieval monitoring	Disable user
RAG Poisoning	Source governance	Change monitoring	Remove/reindex
Prompt-to-Agent Abuse	Tool restrictions	Tool-call monitoring	Disable agent
Agent Privilege Escalation	Least privilege	User/agent mismatch alert	Revoke identity
Model Tampering	Integrity validation	Registry monitoring	Rollback
Resource Abuse	Rate limits	Cost anomaly alerts	Block requester

55. One Threat May Require Multiple Controls

Threat:

Privileged agent abuse.

Do not map only:

Least Privilege

A stronger control set may be:

Authentication
+
User Authorization
+
Dedicated Agent Identity
+
Least Privilege
+
Tool Allowlisting
+
Parameter Validation
+
Approval
+
Logging

Each addresses a different failure point.

56. One Control May Address Multiple Threats

Example:

Least privilege

may reduce:

• Agent privilege escalation

• Credential compromise impact

• Tool abuse

• Lateral movement

• Blast radius

These are high-leverage controls.

57. Identify High-Leverage Controls

Controls that break multiple attack paths should often receive high priority.

Examples include:

• Strong authorization

• Least privilege

• Data segmentation

• Dedicated identities

• Central logging

• Restricted agent tools

These can improve security across many scenarios simultaneously.

58. Prioritize Controls Using Risk

Do not implement controls only because they appear on a checklist.

Use the risk model.

Example:

Critical Threat

Privileged AI agent can modify production IAM.

Priority controls:

1. Reduce Agent Permissions
2. Add User Authorization
3. Add Approval
4. Add Tool Monitoring

Lower-priority cosmetic controls should not delay these.

59. Control Selection Questions

For each proposed control ask:

Which Threat Does It Address?

Which Attack Path Does It Break?

Does It Reduce Likelihood?

Does It Reduce Impact?

Can It Be Validated?

Who Owns It?

How Will We Monitor It?

What Happens If It Fails?

60. Convert Threats Into Security Requirements

Threat models should generate specific requirements.

Weak requirement:

Secure the AI agent.

Better:

The production AI agent must use a dedicated workload identity with permissions limited to approved cloud read operations.

This is:

• Specific

• Testable

• Assignable

61. Requirement Structure

A useful security requirement includes:

ID
Requirement
Rationale
Threat Addressed
Owner
Validation Method

Example:

AGENT-SEC-001

Requirement:
The production cloud agent must use a dedicated
least-privilege workload identity.

Threat:
Privileged agent abuse.

Validation:
Review actual IAM policy.

62. RAG Security Requirements

Examples:

RAG-SEC-001
Retrieval must enforce source-document authorization using the initiating user's identity.

RAG-SEC-002
Only approved identities may modify production RAG knowledge sources.

RAG-SEC-003
RAG ingestion and retrieval activity must be auditable.

RAG-SEC-004
Source permissions and classification metadata must be preserved during ingestion.

63. Agent Security Requirements

Examples:

AGENT-SEC-001
Production agents must use dedicated workload identities.

AGENT-SEC-002
Agent permissions must follow least privilege.

AGENT-SEC-003
High-risk tool actions must be independently authorized.

AGENT-SEC-004
Production agent tool calls must be centrally logged.

AGENT-SEC-005
Security operations must be able to disable high-risk agents during an incident.

64. Model Security Requirements

Examples:

MODEL-SEC-001
Only approved models may be deployed to production.

MODEL-SEC-002
Production model artifacts must have verifiable provenance.

MODEL-SEC-003
Model deployment actions must be auditable.

65. Security Requirement Register

Create an Obsidian note:

AI Security Requirements Register.md

Use:

ID	Requirement	Threat	Priority	Owner	Validation	Status
RAG-SEC-001	Enforce document-level retrieval authorization	RAG-T01	Critical	AI Team	Access test	Open
AGENT-SEC-001	Dedicated least-privilege agent identity	AG-T01	Critical	Platform	IAM review	Open
MODEL-SEC-001	Approved models only	AT-05	High	ML Platform	Registry review	Open

66. Define Control Validation

Never stop at:

Control implemented.

The next question is:

How will we prove it works?

Examples:

Requirement

RAG retrieval enforces user authorization.

Validation

Use an account without HR access and confirm the AI assistant cannot retrieve HR content.

67. Validate Agent Least Privilege

Requirement:

Agent should have read-only access.

Validation:

• Review IAM policy

• Test allowed operation

• Test denied write operation

Expected:

Read → Allowed

Write → Denied

68. Validate Human Approval

Requirement:

Production resource deletion requires approval.

Validation:

Attempt authorized test workflow without approval.

Expected:

Requested Deletion
      ↓
Blocked Pending Approval

69. Validate Kill Switch

Requirement:

Security operations can disable the agent.

Validation:

In an authorized non-production environment:

Disable Agent Identity
       ↓
Attempt Tool Call
       ↓
Denied

A kill switch that has never been tested may not work when needed.

70. Control Effectiveness

After implementation, evaluate whether the control is:

• Effective

• Partially Effective

• Ineffective

• Not Implemented

• Not Applicable

This becomes useful during architecture and risk reviews.

71. Control Assessment Register

Use:

Control	Threat	Design	Implementation	Validation	Result
RAG Authorization	Data Disclosure	Defined	Implemented	Tested	Effective
Agent Least Privilege	Privilege Abuse	Defined	Partial	Reviewed	Partial
Agent Kill Switch	Incident Containment	Defined	Implemented	Not Tested	Partial

72. Residual Risk

After controls are implemented, reassess the risk.

Example:

Threat:
Privileged Agent Abuse

Inherent Risk:
Critical

Controls:
Least Privilege
User Authorization
Approval
Logging

Residual Risk:
Medium

If residual risk remains high, additional treatment may be required.

73. Control Gaps

A control gap exists when:

• Control does not exist

• Control exists but is weak

• Control is misconfigured

• Control cannot be validated

• Control does not actually address the threat

Document gaps clearly.

74. Example Control Gap

Threat:

RAG users may retrieve unauthorized documents.

Existing control:

Enterprise login required.

Control gap:

Authentication exists, but document-level authorization is missing.

Required control:

Retrieval authorization based on source permissions.

75. Build the Threat-to-Control Matrix

Create:

AI Threat-to-Control Matrix.md

Use:

Threat ID	Threat	Prevent	Detect	Respond	Requirement	Validation
RAG-T01	Unauthorized retrieval	Document authz	Retrieval alerts	Disable session	RAG-SEC-001	Access test
RAG-T02	Knowledge poisoning	Source governance	Change alerts	Remove/reindex	RAG-SEC-002	Contributor review
AG-T01	Agent privilege abuse	Least privilege	Tool alerts	Disable agent	AGENT-SEC-001	IAM review
AT-05	Model tampering	Artifact integrity	Registry alerts	Rollback	MODEL-SEC-001	Registry test

This becomes one of the most useful artifacts in the entire threat model.

76. Expanded Threat-to-Control Matrix

For larger systems use:

Threat	Asset	Attack Path	Preventive Control	Detective Control	Responsive Control	Control Owner	Evidence	Residual Risk

This connects:

Threat
 ↓
Control
 ↓
Owner
 ↓
Evidence
 ↓
Risk

77. Defense-in-Depth Example — RAG

Threat:

Malicious document influences AI agent.

Layered controls:

Restricted Contributors
       ↓
Document Review
       ↓
Ingestion Logging
       ↓
Retrieved Content Treated as Untrusted
       ↓
Restricted Agent Tools
       ↓
User Authorization
       ↓
Human Approval

An attacker must now bypass several controls.

78. Defense-in-Depth Example — AI Cloud Agent

Threat:

Compromised employee causes production change.

Controls:

MFA
 ↓
Conditional Access
 ↓
User Authorization
 ↓
Dedicated Agent Identity
 ↓
Least Privilege
 ↓
Tool Restriction
 ↓
Parameter Validation
 ↓
Approval
 ↓
Cloud API Authorization
 ↓
Monitoring

This is much stronger than relying on a prompt instruction.

79. Defense-in-Depth Example — Model Deployment

Threat:

Malicious model is deployed.

Controls:

Approved Source
      ↓
Model Provenance
      ↓
Integrity Validation
      ↓
Model Registry Authorization
      ↓
Deployment Approval
      ↓
Production Monitoring

80. Control Ownership

Every important control should have an owner.

Examples:

Control	Owner
User Authentication	Identity Team
Agent IAM	Platform Team
RAG Authorization	AI Engineering
Data Classification	Data Owner
AI Monitoring	Security Operations
Model Registry	ML Platform

Threat modeling should make ownership clearer.

81. Control Dependencies

Controls often depend on other controls.

Example:

RAG Authorization
      ↓
Depends On
      ↓
Correct User Identity

or:

Detection Rule
      ↓
Depends On
      ↓
High-Quality Logging

Document critical dependencies.

82. Security Control Categories

A practical enterprise view may group controls into:

Identity

Data

Application

AI / Model

RAG

Agent

Infrastructure

Supply Chain

Detection

Incident Response

Governance

This helps organize large threat models.

83. Map Controls to Frameworks

Organizations may also map controls to external frameworks such as:

• NIST

• ISO

• Internal security standards

However, framework mapping should come after understanding the real threat and control.

Do not choose controls simply to satisfy a framework checkbox.

84. Architecture Control Review

A useful pattern is:

Component
 ↓
Threat
 ↓
Existing Control
 ↓
Control Gap
 ↓
Required Control
 ↓
Validation

Example:

AI Agent

Threat:
Privilege Abuse

Existing Control:
Dedicated Identity

Gap:
Identity Has Admin Permissions

Required Control:
Least Privilege

Validation:
IAM Policy Review

85. Control Prioritization

Prioritize controls that:

• Address critical risks

• Protect crown jewels

• Break multiple attack paths

• Reduce large blast radius

• Are foundational for other controls

Examples may include:

Fine-Grained Authorization

Least-Privilege Agent Identity

RAG Access Controls

Centralized AI Logging

86. Avoid Control Overload

Security teams can produce huge lists of recommendations.

This can make implementation difficult.

Instead prioritize:

Critical Controls
      ↓
High-Value Controls
      ↓
Defense Improvements

Focus first on what materially changes risk.

87. Common Control Mapping Mistakes

Selecting Controls Before Understanding the Threat

Always start from the scenario and attack path.

Relying on Prompt Instructions

Prompts are not strong authorization boundaries.

Using Only Preventive Controls

Some attacks will still occur.

Include detection and response.

Adding Controls Without Validation

A control that cannot be tested may provide false confidence.

Ignoring Existing Enterprise Controls

Use existing IAM, logging, cloud and data-security capabilities where appropriate.

Mapping One Control to Every Threat

Different threats require different combinations of controls.

Ignoring Blast Radius

Sometimes reducing permissions is more effective than trying to prevent every AI behavior.

88. Real-World AI Security Engineer Workflow

At this stage:

Threat Scenario
      ↓
Attack Path
      ↓
Identify Breakpoints
      ↓
Map Preventive Controls
      ↓
Map Detective Controls
      ↓
Map Responsive Controls
      ↓
Define Security Requirements
      ↓
Assign Control Owners
      ↓
Implement
      ↓
Validate
      ↓
Reassess Residual Risk

89. Security Control Mapping Mindset

For every threat ask:

Where Can We Stop It?

Where Can We Limit Its Impact?

Where Can We Observe It?

How Would We Contain It?

Which Control Already Exists?

Does That Control Actually Address the Threat?

What Control Is Missing?

Can the Control Be Tested?

Who Owns the Control?

What Risk Remains Afterward?

90. Knowledge Check

Question 1

What is a control breakpoint?

Question 2

What is the difference between preventive, detective and responsive controls?

Question 3

Why should critical authorization be enforced outside the LLM?

Question 4

Why is authentication insufficient for RAG authorization?

Question 5

How does least privilege reduce agent risk?

Question 6

Why should agent tool parameters be independently validated?

Question 7

Why does RAG source governance matter?

Question 8

How can data segmentation reduce blast radius?

Question 9

Why is model output often treated as untrusted input?

Question 10

Why are kill switches useful for high-risk agents?

Question 11

What makes a security requirement testable?

Question 12

Why should control effectiveness be validated?

Question 13

What is a Threat-to-Control Matrix?

Question 14

Why should residual risk be reassessed after controls are implemented?

Key Takeaways

Threat modeling becomes actionable when threats are mapped to concrete controls.

The basic process is:

Threat
  ↓
Attack Path
  ↓
Control Breakpoints
  ↓
Prevent
  +
Detect
  +
Respond
  ↓
Security Requirements
  ↓
Validation
  ↓
Residual Risk

For enterprise AI systems, the most important controls frequently include:

Authentication
      +
Authorization
      +
Least Privilege
      +
Data Segmentation
      +
RAG Governance
      +
Agent Tool Restrictions
      +
Policy Enforcement
      +
Human Approval
      +
Logging
      +
Monitoring
      +
Containment

The most important principle is:

Do not try to make the AI model itself responsible for protecting critical assets. Build trusted security controls around the model so that unexpected AI behavior cannot automatically become enterprise compromise.

Strong AI security is not one perfect filter.

It is defense in depth.

What’s Next?

➡️ 14 — Building an Enterprise AI Threat Model

You now have all the individual building blocks:

• Business context

• Architecture

• Assets

• Data flows

• Trust boundaries

• Threat actors

• Attack surfaces

• STRIDE analysis

• OWASP GenAI mapping

• MITRE ATLAS mapping

• RAG threat modeling

• Agent threat modeling

• Attack paths

• Risk prioritization

• Security controls

The next lesson brings everything together.

You will learn how to build a complete Enterprise AI Threat Model from start to finish.

You will create a structured threat model containing:

• Scope

• Business context

• Architecture

• Asset register

• Data-flow analysis

• Trust-boundary register

• Threat-actor profiles

• Attack-surface register

• Threat scenarios

• Abuse cases

• Attack paths

• Risk register

• Threat-to-control mappings

• Security requirements

• Detection requirements

• Residual risk

• Executive summary

The goal is to move from:

“I understand the individual parts of AI threat modeling.”

to:

“I can perform and deliver a complete enterprise AI threat modeling engagement.”

➡️ Next: 14 — Building an Enterprise AI Threat Model