Runbook 02 AI Risk Assessment Methodology

Runbook Purpose

This runbook provides a repeatable methodology for assessing and prioritizing AI security risk.

Use it after threat modeling has identified:

Threat scenarios
Abuse cases
Attack paths
Target assets
Security weaknesses
Existing controls

The goal is to answer:

Which AI risks matter most, why do they matter, and what should the organization do first?

This runbook helps move from:

Threat Identified
      ↓
Attack Path Understood
      ↓
Likelihood Assessed
      ↓
Impact Assessed
      ↓
Controls Evaluated
      ↓
Residual Risk Determined
      ↓
Risk Treatment Decision

The objective is not to create artificial mathematical precision.

The objective is to produce a consistent, evidence-based and defensible risk assessment.

Runbook Outcome

At the end of the assessment, you should have:

AI risk register
Likelihood ratings
Impact ratings
Inherent risk
Existing control assessment
Control effectiveness rating
Residual risk
Risk treatment recommendation
Remediation priority
Risk owner
Remediation owner
Target dates
Validation requirements
Executive risk summary

When to Use This Runbook

Use this runbook:

After AI Threat Modeling

Once realistic threats and attack paths have been identified.

Before Production Deployment

To determine whether residual risk is acceptable.

When AI Architecture Changes

Examples:

RAG Added

Sensitive Data Added

New Agent Tool Added

Production Access Added

Agent Permissions Increased

During Security Architecture Reviews

To prioritize identified security gaps.

During AI Red Team Follow-Up

To assess the business significance of validated attack scenarios.

After AI Security Incidents

To reassess likelihood, impact and control effectiveness.

During Risk Acceptance

To document the remaining risk and support an informed business decision.

Inputs Required

Before starting, collect:

Threat Information

Threat scenarios
Abuse cases
Attack paths
Threat actors
Preconditions

Asset Information

Asset register
Data classification
Crown jewels
Business owners

Architecture Information

AI architecture
RAG architecture
Agent architecture
External dependencies

Permission Information

User permissions
Agent permissions
Tool permissions
Cloud IAM
Data access

Control Information

Preventive controls
Detective controls
Responsive controls
Validation evidence

Business Information

Business criticality
Regulatory obligations
Financial impact
Customer impact
Operational dependencies

Core Risk Concepts

Before rating risk, keep these concepts separate.

Threat

Something that could cause harm.

Example:

Unauthorized RAG data retrieval.

Vulnerability or Security Gap

A weakness that allows the threat.

Example:

Document-level authorization is missing during retrieval.

Impact

The consequence if the threat succeeds.

Example:

Confidential HR information is disclosed.

Risk

The significance of the threat considering likelihood, impact and controls.

Conceptually:

Threat
   +
Weakness
   +
Likelihood
   +
Impact
   =
Risk

Inherent Risk

Inherent risk is the level of risk before considering existing security controls.

Example:

AI Agent
   ↓
AdministratorAccess
   ↓
Production Cloud

If a compromised user can influence this agent, inherent risk may be:

Critical

before considering controls such as:

User authorization
Human approval
Logging
Tool restrictions

Residual Risk

Residual risk is what remains after existing or planned controls are considered.

Example:

Critical Inherent Risk
        ↓
Least Privilege
+
User Authorization
+
Approval
+
Monitoring
        ↓
Medium Residual Risk

Residual risk is the risk the organization must ultimately:

Accept
Further reduce
Avoid
Transfer where appropriate

Recommended Risk Model

Start simple.

Risk = Likelihood × Impact

Then use contextual factors to justify those ratings.

For AI systems, consider:

Exposure
Attack Complexity
Required Access
Threat Actor Capability
Asset Criticality
Data Sensitivity
Agent Privilege
Autonomy
Blast Radius
Persistence
Scale
Detectability
Response Capability
Existing Controls

Do not mechanically multiply every factor.

Use them to support professional judgment.

Phase 1 — Validate the Threat Scenario

Step 1 — Review the Threat

Do not rate a vague label such as:

Prompt Injection

Rate a complete scenario.

Example:

A compromised employee may influence a cloud operations agent to perform a production network change because the agent uses a privileged workload identity and does not independently enforce the initiating user’s permissions.

This can be assessed.

Step 2 — Confirm the Attack Path

Document:

Threat Actor
      ↓
Starting Position
      ↓
Entry Point
      ↓
Security Gap
      ↓
Privilege
      ↓
Target Asset
      ↓
Business Impact

Step 3 — Confirm Preconditions

Example:

Attacker must control an employee account.

Employee must have access to the AI agent.

Agent must possess production privileges.

User-context authorization must be absent or ineffective.

Do not inflate likelihood by ignoring prerequisites.

Phase 2 — Identify the Target Asset

Step 4 — Identify the Asset

Examples:

Restricted HR Data

Customer Records

Production Cloud

Agent Administrative Identity

Model Registry

AI Credentials

Avoid generic labels such as:

Data

Step 5 — Determine Asset Criticality

Use a simple scale:

Low

Loss has limited impact.

Medium

Loss creates noticeable operational or security impact.

High

Loss affects important systems, confidential data or business operations.

Critical

Loss may cause:

Major production compromise
Restricted data exposure
Severe financial impact
Regulatory impact
Safety impact
Large-scale outage

Phase 3 — Assess Data Sensitivity

Step 6 — Classify the Data

Example scale:

Public

Internal

Confidential

Restricted

Risk should increase appropriately as sensitive data becomes accessible.

Example:

Public Product FAQ

is different from:

Restricted Employee Records

even when the technical weakness is identical.

Phase 4 — Assess Exposure

Step 7 — Determine Attack Surface Exposure

Classify the entry point.

Public

Internet accessible.

External Authenticated

Accessible to customers or partners.

Internal

Accessible to employees.

Privileged

Requires administrator or developer access.

Indirect

Influenced through:

Documents
Email
Websites
RAG
Supply chain

Step 8 — Record Exposure

Example:

## Exposure

Internal Authenticated

## Rationale

Any employee with enterprise access can reach the AI assistant.

Exposure influences likelihood.

It does not determine risk by itself.

Phase 5 — Assess Required Access

Step 9 — Determine Starting Privilege

Possible ratings:

None

Anonymous

Authenticated External User

Employee

Developer

Privileged Administrator

Supply-Chain Access

Example:

Threat A requires:

Anonymous Internet User

Threat B requires:

AI Platform Administrator

The second normally has a lower probability, all else being equal.

Phase 6 — Assess Attack Complexity

Step 10 — Determine Complexity

Low

Direct path
Few prerequisites
Common techniques
Little specialized knowledge

Medium

Several conditions required
More than one step
Some technical expertise

High

Complex chain
Specialized knowledge
Multiple security boundaries
Significant access required

Step 11 — Record the Reasoning

Example:

## Attack Complexity

Medium

## Rationale

The attacker must compromise an employee identity and then influence the agent into requesting an unauthorized action. No direct infrastructure compromise is required.

Phase 7 — Assess Threat Actor Capability

Step 12 — Identify Likely Actor

Examples:

Opportunistic attacker
Skilled external attacker
Malicious employee
Compromised employee
Supply-chain attacker
Well-resourced adversary

Ask:

Does the identified actor realistically possess the access and expertise required?

Do not assume every threat actor has unlimited capability.

Phase 8 — Assess AI-Specific Privilege

Step 13 — Determine AI Capability

For AI agents, ask:

Can the AI only generate text?

Can it retrieve enterprise data?

Can it send messages?

Can it modify business records?

Can it change production?

Can it modify IAM?

Step 14 — Rate Agent Privilege

Low

Public information or low-risk read-only access.

Medium

Internal data or limited business actions.

High

Sensitive data or production write operations.

Critical

Administrative, IAM, destructive or high-impact business authority.

Agent privilege may dramatically change impact.

Phase 9 — Assess Autonomy

Step 15 — Determine Human Control

Low Autonomy

AI Recommends
      ↓
Human Executes

Medium Autonomy

AI Proposes
      ↓
Human Approves
      ↓
AI Executes

High Autonomy

AI Decides
      ↓
AI Executes

Higher autonomy may:

Increase likelihood of unintended execution
Reduce intervention opportunities
Increase scale

Autonomy alone does not make a system high risk, but it is an important factor.

Phase 10 — Assess Blast Radius

Step 16 — Ask the Compromise Question

If this AI component were fully compromised, what could the attacker affect?

Document:

Data Read

Data Modified

Resources Modified

Resources Deleted

Environments Reached

Security Controls Changed

External Destinations Reached

Step 17 — Rate Blast Radius

Low

Single user or low-value resource.

Medium

Limited system or department.

High

Multiple important systems.

Critical

Enterprise-wide or crown-jewel compromise.

Phase 11 — Assess Persistence

Step 18 — Determine Duration of Impact

Compare:

Temporary

One Manipulated Response

with:

Persistent

RAG Poisoning
      ↓
Many Future Responses

or:

Model Replacement
      ↓
Production Behavior Persists

Persistence may increase impact.

Phase 12 — Assess Scale

Step 19 — Determine Scope of Effect

Ask:

How Many Users?

How Many Records?

How Many Systems?

How Many Environments?

How Many Future Sessions?

Example:

One User Session

versus:

Shared AI Assistant Used Enterprise-Wide

The same technical issue may have different risk.

Phase 13 — Assess Detectability

Step 20 — Determine Whether the Attack Is Visible

High Detectability

Clear, centralized and reliable security events exist.

Example:

Production IAM Modification

Medium Detectability

Some telemetry exists but investigation is required.

Low Detectability

Attack may look like normal AI behavior.

Example:

Subtle RAG Poisoning

Low detectability may justify stronger preventive controls.

Phase 14 — Assess Response Capability

Step 21 — Determine Containment Capability

Ask:

Can the User Be Disabled?

Can the Agent Be Disabled?

Can Tokens Be Revoked?

Can Tools Be Blocked?

Can the RAG Index Be Rebuilt?

Can the Model Be Rolled Back?

Step 22 — Rate Response Capability

Strong

Rapid, tested containment exists.

Partial

Containment exists but is manual or untested.

Weak

Containment is unclear or slow.

Poor response capability can increase residual risk.

Phase 15 — Determine Likelihood

Step 23 — Combine Likelihood Factors

Review:

Exposure
Required Access
Attack Complexity
Threat Actor Capability
Preconditions
Existing Preventive Controls

Then assign:

Low

Attack requires uncommon access, difficult conditions or a complex chain.

Medium

Attack is realistic under plausible conditions.

High

Attack surface is easily reachable and the attack requires limited complexity or access.

Step 24 — Document the Likelihood Rationale

Example:

## Likelihood

Medium

## Rationale

The attacker must first control an employee account. The AI agent is available to the user, and the attack does not require infrastructure compromise. Existing MFA lowers the probability of initial account compromise, but no independent agent authorization currently exists.

The rationale is more important than the word Medium.

Phase 16 — Determine Impact

Step 25 — Assess Technical Impact

Consider:

Confidentiality

Integrity

Availability

Privilege

Persistence

Step 26 — Assess Business Impact

Consider:

Operational Disruption

Customer Impact

Financial Loss

Regulatory Impact

Privacy

Reputation

Safety

Step 27 — Assign Impact

Low

Limited impact with easy recovery.

Medium

Noticeable security or operational effect.

High

Significant data, customer or operational impact.

Critical

Severe enterprise impact, crown-jewel compromise or major regulatory / financial / safety consequence.

Step 28 — Record Impact Rationale

Example:

## Impact

Critical

## Rationale

Successful exploitation could allow modification of production network controls and expose externally reachable services. This could result in service disruption and secondary compromise.

Phase 17 — Determine Inherent Risk

Step 29 — Use the Risk Matrix

A simple matrix:

Likelihood ↓ / Impact →	Low	Medium	High	Critical
Low	Low	Low	Medium	High
Medium	Low	Medium	High	Critical
High	Medium	High	Critical	Critical

Adapt this to organizational standards.

Step 30 — Record Inherent Risk

Example:

## Inherent Risk

Critical

This reflects the scenario before existing controls are considered.

Phase 18 — Identify Existing Controls

Step 31 — Record Preventive Controls

Examples:

MFA

RAG Authorization

Least Privilege

Agent Tool Restrictions

Human Approval

Network Segmentation

Step 32 — Record Detective Controls

Examples:

Agent Tool Logs

RAG Retrieval Logs

Cloud Audit Logs

Identity Alerts

Document Change Monitoring

Step 33 — Record Response Controls

Examples:

Agent Kill Switch

Credential Revocation

RAG Reindexing

Model Rollback

Emergency Deny Policy

Phase 19 — Assess Control Effectiveness

Step 34 — Do Not Ask Only Whether a Control Exists

Ask:

Does this control actually address this specific attack path?

Example:

Threat:

Authenticated employee retrieves restricted HR information.

Control:

MFA

MFA is useful, but it does not solve the authorization failure.

The relevant control is:

Fine-grained RAG retrieval authorization.

Step 35 — Rate Control Effectiveness

Use:

None

No meaningful control.

Weak

Control exists but provides limited protection.

Partial

Control addresses part of the scenario.

Strong

Control directly and reliably breaks or limits the path.

Step 36 — Document Evidence

Example:

## Control

Agent Least Privilege

## Effectiveness

Partial

## Evidence

IAM review shows the agent cannot modify IAM but still has broad production network modification rights.

Phase 20 — Reassess Residual Likelihood

Step 37 — Ask Whether Controls Reduce Probability

Example:

Before controls:

Any Employee
      ↓
Agent
      ↓
Production Action

After:

Employee
      ↓
User Authorization
      ↓
Approved Tool
      ↓
Human Approval

Likelihood may move from:

High

to:

Low / Medium

depending on control strength.

Phase 21 — Reassess Residual Impact

Step 38 — Ask Whether Controls Reduce Blast Radius

Example:

Before:

Agent → Administrator

After:

Agent → Restart Approved Workloads Only

Even if the attack succeeds, impact is now lower.

This is why least privilege is an impact-reduction control, not only a prevention control.

Phase 22 — Determine Residual Risk

Step 39 — Assign Residual Rating

Example:

## Inherent Risk

Critical

## Existing Controls

- MFA
- User-context authorization
- Least-privilege agent identity
- Human approval
- Central logging

## Residual Likelihood

Low

## Residual Impact

High

## Residual Risk

Medium

Phase 23 — Validate Risk Aggregation

Step 40 — Review Connected Findings

Do not assess every finding independently.

Example:

Prompt Manipulation
       +
Excessive Agent Privilege
       +
Missing Approval
       =
Critical Attack Path

Three moderate findings can create one critical path.

Ask:

Does this weakness become more dangerous when combined with another weakness?

Phase 24 — Evaluate Common AI Risk Scenarios

Scenario 1 — Public FAQ Prompt Manipulation

Architecture:

Anonymous User
      ↓
FAQ Assistant
      ↓
Public Data

Likelihood:

High

Impact:

Low

Risk:

Low / Medium

Key lesson:

High exploitability does not automatically mean high business risk.

Scenario 2 — Unauthorized Enterprise RAG Retrieval

Architecture:

Employee
 ↓
RAG
 ↓
Restricted HR Data

Likelihood:

High

Impact:

High / Critical

Risk:

Critical

Scenario 3 — Privileged AI Agent Abuse

Architecture:

Compromised Employee
       ↓
AI Agent
       ↓
Production Cloud

Likelihood:

Medium

Impact:

Critical

Risk:

Critical

Scenario 4 — RAG Knowledge Poisoning

Architecture:

Malicious Contributor
       ↓
RAG Source
       ↓
Shared Enterprise AI

Likelihood:

Medium

Impact:

High

Additional factors:

Persistent
Many users
Potentially difficult to detect

Risk:

High

Scenario 5 — Agent Credential Compromise

Architecture:

Attacker
   ↓
Agent Credential
   ↓
Production API

Likelihood:

Low / Medium

Impact:

Critical

Risk:

High / Critical

depending on permission scope.

Scenario 6 — External LLM Data Exposure

Architecture:

Confidential Enterprise Data
        ↓
External LLM Provider

Assess:

Data classification
Retention
Provider contract
Security controls
Regulatory requirements

Risk cannot be determined from architecture alone.

Scenario 7 — AI Cost / Resource Abuse

Architecture:

Attacker
 ↓
AI API
 ↓
Repeated Expensive Requests

Likelihood:

High

Impact:

Medium

Risk:

High

where usage controls are weak.

Phase 25 — Determine Risk Treatment

Once residual risk is known, select a treatment.

Avoid

Remove the risky capability.

Example:

AI Agent Does Not Need IAM Modification
        ↓
Remove IAM Tool

This can eliminate the attack path.

Mitigate

Implement additional controls.

Example:

Agent Admin Access
      ↓
Least Privilege
      +
Authorization
      +
Approval

Transfer

Shift part of the financial or contractual impact.

Examples may involve:

Insurance
Contractual arrangements

Transfer does not remove the technical risk.

Accept

The appropriate risk owner formally accepts the residual risk.

Security should not silently accept business risk.

Step 41 — Prefer Architecture Simplification

Before adding controls, ask:

Can we remove the risky capability entirely?

Example:

Instead of:

AI Agent
 ↓
Cloud Administrator

use:

AI Agent
 ↓
Read Security Findings

where that satisfies the business need.

Step 42 — Prefer High-Leverage Controls

Examples:

Fine-grained authorization
Least privilege
Data segmentation
Dedicated workload identity
Centralized logging

These may reduce several attack paths simultaneously.

Phase 27 — Prioritize Remediation

Step 43 — Assign Remediation Priority

Example model:

P1 — Immediate

Critical residual risk
Crown-jewel exposure
Production administrative access
Restricted data exposure

P2 — High

High residual risk
Significant business impact
Large blast radius

P3 — Medium

Medium residual risk
Strong compensating controls exist

P4 — Improvement

Low residual risk
Defense enhancement

Step 44 — Prioritize Attack Paths

Do not prioritize only by finding count.

Example:

Finding 1 — Prompt manipulation
Finding 2 — Broad agent permissions
Finding 3 — Missing approval

The real priority may be:

AP-01 — Unauthorized Production Change

because all three contribute to the same path.

Phase 28 — Assign Ownership

Step 45 — Identify Remediation Owner

The team responsible for fixing the technical gap.

Examples:

AI Engineering
Platform Engineering
Identity Team
Data Team
SOC

Step 46 — Identify Risk Owner

The person or function responsible for the business risk decision.

Examples:

Product Owner
Business Owner
Platform Owner
Data Owner

These may be different.

Example:

Remediation Owner:
Cloud Platform Team

Risk Owner:
AI Product Owner

Phase 29 — Set Target Dates

Step 47 — Align Date to Risk

Example:

Critical

Before production or immediate remediation.

High

Short-term priority.

Medium

Planned remediation.

Low

Backlog or accepted improvement.

Use organizational policy where available.

Phase 30 — Build the AI Risk Register

Create:

AI Risk Register.md

Use:

ID	Threat Scenario	Asset	Likelihood	Impact	Inherent Risk	Controls	Residual Risk	Treatment	Owner	Status
R-01	Unauthorized RAG retrieval	HR Data	High	High	Critical	Document Authz	Medium	Mitigate	AI Team	Open
R-02	Privileged agent abuse	Production Cloud	Medium	Critical	Critical	Least Privilege + Approval	High	Mitigate	Platform	Open
R-03	RAG poisoning	Knowledge Base	Medium	High	High	Source Governance	Medium	Mitigate	Data Team	Open

Phase 31 — Use an Expanded Risk Register

For larger assessments:

ID	Threat Actor	Scenario	Asset	Exposure	Access	Complexity	Privilege	Blast Radius	Likelihood	Impact	Inherent	Control Effectiveness	Residual	Owner

This provides more context for difficult decisions.

Phase 32 — Create a Detailed Risk Record

Use:

# R-XX — Risk Name

## Business Scenario

## Threat Actor

## Threat Scenario

## Attack Path

## Target Asset

## Asset Classification

## Business Criticality

## Exposure

## Required Access

## Attack Complexity

## Threat Actor Capability

## Agent Privilege

## Agent Autonomy

## Blast Radius

## Persistence

## Scale

## Detectability

## Response Capability

## Likelihood

## Likelihood Rationale

## Impact

## Impact Rationale

## Inherent Risk

## Existing Controls

## Control Effectiveness

## Residual Likelihood

## Residual Impact

## Residual Risk

## Recommended Treatment

## Priority

## Remediation Owner

## Risk Owner

## Target Date

## Validation Requirement

## Status

Example Risk Record

# R-02 — Unauthorized Production Action Through AI Agent

## Business Scenario

Cloud engineers use an AI agent to investigate and perform selected cloud operations.

## Threat Actor

Compromised cloud engineer.

## Threat Scenario

An attacker controlling an employee account attempts to cause the AI agent to perform a production network change beyond the user's approved permissions.

## Attack Path

Compromised Employee
        ↓
AI Agent
        ↓
Missing User Authorization
        ↓
Cloud Action Tool
        ↓
Privileged Agent Identity
        ↓
Production Cloud

## Target Asset

Production cloud environment.

## Asset Classification

Critical.

## Business Criticality

Mission critical.

## Exposure

Internal authenticated.

## Required Access

Valid cloud engineer account.

## Attack Complexity

Medium.

## Threat Actor Capability

Moderate.

## Agent Privilege

High.

## Agent Autonomy

Medium.

## Blast Radius

High.

## Persistence

Potentially persistent until configuration is restored.

## Scale

Multiple production resources may be affected.

## Detectability

Medium.

## Response Capability

Partial.

## Likelihood

Medium.

## Likelihood Rationale

A valid employee account is required, but the agent is directly available after authentication and no independent user-context authorization currently protects the cloud action.

## Impact

Critical.

## Impact Rationale

An unauthorized network change could expose production services or disrupt critical workloads.

## Inherent Risk

Critical.

## Existing Controls

- SSO
- MFA
- Dedicated agent identity
- Cloud audit logging

## Control Effectiveness

Partial.

## Residual Likelihood

Medium.

## Residual Impact

Critical.

## Residual Risk

Critical.

## Recommended Treatment

Mitigate before production.

## Priority

P1

## Recommended Controls

- User-context authorization
- Least-privilege agent permissions
- Tool allowlisting
- Parameter validation
- Human approval
- Agent tool-call monitoring
- Tested kill switch

## Remediation Owner

Cloud Platform Team.

## Risk Owner

AI Service Owner.

## Status

Open.

Phase 33 — Validate High-Risk Ratings

For every Critical or High risk ask:

Is the Attack Technically Possible?

Are the Preconditions Accurate?

Is the Asset Classification Correct?

Is the Impact Realistic?

Did We Consider Existing Controls?

Do We Have Evidence?

Do not use high ratings simply because the issue involves AI.

Phase 34 — Avoid Risk Inflation

Common mistake:

Prompt Injection = Critical

This is not sufficient.

Instead assess:

Prompt Manipulation
      ↓
What Can the AI Access?
      ↓
What Can the AI Do?
      ↓
What Asset Is Behind It?
      ↓
What Controls Exist?

The same AI weakness can range from:

Low

to:

Critical

depending on architecture.

Phase 35 — Avoid False Precision

Do not create numbers such as:

Risk = 8.7362

unless the organization’s methodology genuinely supports that level of precision.

Prefer:

Likelihood: Medium

Impact: Critical

Risk: Critical

with clear rationale.

Phase 36 — Document Uncertainty

If information is unknown, record it.

Example:

## Unknown

Whether the external model provider retains RAG context.

## Risk Impact

Residual risk cannot be finalized until provider data-processing behavior is confirmed.

Do not guess.

Phase 37 — Create Validation Tasks

Unknowns and assumptions should become tasks.

Example:

Validation ID	Risk	Validation	Owner
VAL-01	R-01	Test non-HR user against HR documents	AI Team
VAL-02	R-02	Review actual agent IAM policy	Platform
VAL-03	R-03	Review RAG contributor permissions	Data Team
VAL-04	R-04	Validate provider retention contract	Governance

Phase 38 — Reassess After Validation

If validation shows:

Assumption:
Agent is read-only

is false and the agent actually has:

AdministratorAccess

update:

Impact
Blast radius
Inherent risk
Residual risk
Remediation priority

Risk assessment must reflect evidence.

Phase 39 — Risk Acceptance

If residual risk cannot or will not be reduced further, formal acceptance may be required.

Create:

# Risk Acceptance

## Risk ID

## Residual Risk

## Risk Description

## Business Justification

## Existing Controls

## Compensating Controls

## Risk Owner

## Approval Date

## Review Date

## Expiration Date

## Conditions

Phase 40 — Use Expiration Dates

Risk acceptance should not automatically mean:

Accepted Forever

Prefer:

Accepted
   ↓
Review Date
   ↓
Reassess

especially when:

Architecture changes quickly
Compensating controls are temporary
Risk is High

Phase 41 — Risk Escalation

Escalate when scenarios involve:

Critical production systems
Restricted data
AI agents with broad administrative authority
Missing authorization
Unclear external data handling
Inability to contain the AI system
Persistent high residual risk

Escalation means:

The appropriate owner must make an informed decision.

It does not automatically mean the project must stop.

Phase 42 — Communicate Risk to Engineering

Engineering needs:

What Is Wrong?

How Can It Happen?

What Should Change?

How Do We Test the Fix?

Example:

The AI agent currently authorizes production changes using its workload identity rather than the initiating user’s permissions. Implement user-context authorization and validate that unauthorized users receive a denied result.

Phase 43 — Communicate Risk to Leadership

Leadership needs:

What Could Happen?

How Likely Is It?

What Is the Business Impact?

What Must We Fix First?

What Risk Remains?

Avoid framework jargon where it does not help the decision.

Phase 44 — Executive Risk Summary

Example:

# Executive Risk Summary

## Overall Risk

High

## Primary Risk Drivers

- AI agent has production write capability.
- RAG accesses confidential enterprise data.
- User authorization is not consistently preserved across AI workflows.
- AI-specific monitoring is incomplete.

## Highest-Priority Risks

1. Unauthorized production actions through the AI agent.
2. Unauthorized retrieval of restricted enterprise data.
3. Persistent RAG knowledge poisoning.

## Priority Actions

1. Implement user-context authorization.
2. Reduce agent permissions.
3. Enforce document-level RAG authorization.
4. Implement agent and RAG monitoring.
5. Validate emergency containment.

## Expected Residual Risk

Medium after priority controls are implemented and tested.

Phase 45 — Build a Remediation Roadmap

Example:

P1 — Before Production

User-Context Authorization

Agent Least Privilege

RAG Authorization

Critical Logging

Kill Switch

P2 — Short-Term Hardening

RAG Source Governance

Parameter Validation

Enhanced Detection

Provider Governance

P3 — Continuous Improvement

Advanced Behavioral Analytics

Threat Hunting

Red-Team Validation

Automation

Phase 46 — Reassess When Architecture Changes

Trigger reassessment when:

New Sensitive Data Added

New RAG Source Added

New Agent Tool Added

Agent Gains Write Access

Agent Becomes Autonomous

New External Provider Added

New Model Deployed

New Production Connection Added

Phase 47 — Example Risk Change

Version 1:

AI Agent
 ↓
Read Cloud Findings

Risk:

Medium

Version 2:

AI Agent
 ↓
Modify Production Network

Risk may become:

Critical

even if the prompt interface is unchanged.

Capability changes risk.

Phase 48 — Risk Review Cadence

Review high-risk AI systems:

When major changes occur
After significant incidents
During scheduled risk reviews

Frequency should follow organizational policy and the pace of architecture change.

AI Risk Assessment Checklist

Threat

Threat scenario is specific
Threat actor identified
Attack path documented
Preconditions documented

Asset

Target asset identified
Asset classification known
Business owner identified
Crown-jewel status considered

Likelihood

Exposure assessed
Required access assessed
Complexity assessed
Threat actor capability considered
Existing preventive controls considered
Likelihood rationale documented

Impact

Confidentiality considered
Integrity considered
Availability considered
Business impact considered
Regulatory impact considered
Agent privilege considered
Blast radius considered
Persistence considered
Scale considered
Impact rationale documented

Controls

Preventive controls identified
Detective controls identified
Response controls identified
Control effectiveness evaluated
Evidence reviewed

Residual Risk

Residual likelihood determined
Residual impact determined
Residual risk assigned
Reasoning documented

Treatment

Avoid considered
Mitigate considered
Transfer considered where applicable
Accept considered where appropriate
Treatment selected

Ownership

Remediation owner assigned
Risk owner assigned
Priority assigned
Target date defined

Validation

Assumptions validated
Security tests defined
Evidence collected
Risk updated after testing

Decision Questions

Whenever a rating is unclear, ask:

What Must the Attacker Already Control?
        ↓
How Easily Can They Reach the Surface?
        ↓
How Difficult Is the Attack?
        ↓
What Asset Is Behind It?
        ↓
How Sensitive Is That Asset?
        ↓
What Authority Does the AI Have?
        ↓
What Happens If the AI Is Fully Compromised?
        ↓
How Many Systems or Users Are Affected?
        ↓
How Long Would the Effect Last?
        ↓
Would We Detect It?
        ↓
Can We Contain It?
        ↓
Which Controls Actually Break the Path?
        ↓
What Risk Remains?

Common Risk Assessment Mistakes

Rating the Vulnerability Name

Do not rate:

Prompt Injection

Rate the complete scenario.

Treating Every AI Issue as Critical

This destroys prioritization.

Ignoring Business Impact

Technical severity alone is insufficient.

Ignoring Existing Controls

Residual risk matters.

Counting Authentication as Authorization

A user may be authenticated and still unauthorized.

Ignoring Agent Privilege

This is one of the biggest causes of underestimated AI risk.

Ignoring Attack-Path Combinations

Several moderate gaps may combine into a Critical scenario.

Ignoring Detectability

Hard-to-detect persistent threats may need stronger preventive controls.

Ignoring Response Capability

Fast containment can materially reduce impact.

Accepting Risk Without an Owner

Security findings do not become formally accepted merely because remediation is delayed.

Example AI Risk Prioritization Table

Priority	Risk	Why
P1	Privileged Agent Abuse	Production impact + large blast radius
P1	Unauthorized RAG Retrieval	Restricted-data exposure + easy user access
P2	RAG Knowledge Poisoning	Persistent impact across many users
P2	Agent Credential Compromise	Critical impact but stronger prerequisites
P3	Resource Abuse	Operational and cost impact
P4	Public FAQ Manipulation	Limited business impact

This is only an example.

Actual prioritization must reflect the real environment.

Risk Assessment Deliverable Structure

Use:

AI-Risk-Assessment/
│
├── 01 Risk Methodology.md
├── 02 Asset Criticality.md
├── 03 Threat Scenarios.md
├── 04 Attack Paths.md
├── 05 AI Risk Register.md
├── 06 Control Effectiveness.md
├── 07 Validation Register.md
├── 08 Risk Treatment Plan.md
├── 09 Risk Acceptances.md
└── 10 Executive Risk Summary.md

Runbook Completion Criteria

The risk assessment is complete when every major threat can be traced through:

Threat
  ↓
Attack Path
  ↓
Target Asset
  ↓
Likelihood
  ↓
Impact
  ↓
Inherent Risk
  ↓
Existing Controls
  ↓
Control Effectiveness
  ↓
Residual Risk
  ↓
Risk Treatment
  ↓
Owner

For each High or Critical risk, you should be able to answer:

Why is the rating high?

What evidence supports it?

What controls reduce it?

Who owns remediation?

Who owns the remaining risk?

What must happen before production?

Runbook Summary

The complete AI risk assessment process is:

1. Validate Threat Scenario
        ↓
2. Validate Attack Path
        ↓
3. Identify Target Asset
        ↓
4. Assess Asset Criticality
        ↓
5. Assess Exposure
        ↓
6. Assess Required Access
        ↓
7. Assess Attack Complexity
        ↓
8. Assess AI Privilege and Autonomy
        ↓
9. Assess Blast Radius
        ↓
10. Assess Persistence and Scale
        ↓
11. Assess Detectability
        ↓
12. Assess Response Capability
        ↓
13. Determine Likelihood
        ↓
14. Determine Impact
        ↓
15. Determine Inherent Risk
        ↓
16. Review Existing Controls
        ↓
17. Assess Control Effectiveness
        ↓
18. Determine Residual Risk
        ↓
19. Select Risk Treatment
        ↓
20. Prioritize Remediation
        ↓
21. Assign Owners
        ↓
22. Validate Assumptions
        ↓
23. Communicate Risk
        ↓
24. Reassess After Change

The core principle is:

Do not rate AI risks based on how impressive or unfamiliar the attack sounds. Rate the complete business scenario based on how realistic the attack is, what authority the AI has, which asset is affected, what the impact would be and what controls actually stand between the attacker and that outcome.

What’s Next?

➡️ Runbook 03 — Enterprise AI Threat Modeling Review & Governance

You now have:

A repeatable AI threat modeling methodology
A repeatable AI risk assessment methodology

The final runbook for this module focuses on how an enterprise should review, govern, approve and maintain AI threat models over time.

You will build a repeatable process for:

Threat model intake
Review ownership
Architecture review
Security review
Risk review
Evidence validation
Remediation tracking
Risk acceptance
Production approval
Change-triggered reassessment
Periodic review
AI security governance reporting
Threat model quality standards

The goal is to move from:

“I can build and assess an AI threat model.”

to:

“I can operate an enterprise process that ensures important AI systems are threat modeled, reviewed, approved and continuously reassessed.”

➡️ Next: Runbook 03 — Enterprise AI Threat Modeling Review & Governance