AI for Sr Security Consultant

Artificial Intelligence is becoming part of enterprise architecture.

Organisations are deploying:

Generative AI applications
Large Language Models
AI assistants
AI copilots
Retrieval-Augmented Generation systems
AI agents
Machine learning platforms
AI-enabled SaaS
AI-powered security tools
Automated business workflows

This creates a new consulting requirement.

Senior Security Consultants must increasingly be able to answer:

How is the organisation using AI?

What enterprise data can AI access?

What actions can AI systems perform?

What happens if an AI system is manipulated?

How should AI risk be governed?

Are existing security controls sufficient for AI workloads?

At the same time, AI can improve the way security consultants perform:

Research
Discovery
Threat modelling
Evidence analysis
Control mapping
Reporting
Security architecture analysis

The objective is not to become an AI researcher.

The objective is to develop enough AI security knowledge to assess enterprise AI systems and responsibly use AI within security consulting engagements.

Module Mission

Your mission is to understand two dimensions of AI security consulting.

AI for Sr Security Consultant
│
├── Securing AI
│   ├── AI Governance
│   ├── AI Architecture
│   ├── LLM Security
│   ├── AI Agents
│   ├── Data Security
│   ├── Identity
│   ├── Supply Chain
│   └── Monitoring
│
└── Using AI in Consulting
    ├── Discovery
    ├── Research
    ├── Threat Modelling
    ├── Evidence Analysis
    ├── Control Mapping
    ├── Reporting
    └── Knowledge Management

By the end of this module, you should be able to incorporate AI security into enterprise consulting engagements without abandoning established security principles.

1. Why AI Matters to Security Consultants

Enterprise AI adoption introduces new:

Applications
Data flows
Trust relationships
Identities
APIs
Third-party dependencies
Attack surfaces
Governance requirements

Consider:

Employee
   ↓
Enterprise AI Assistant
   ↓
LLM
   ↓
Internal Knowledge Base
   ↓
Customer Information

The AI assistant may now become another path to sensitive enterprise information.

2. AI Security Is Still Enterprise Security

Do not treat AI as completely disconnected from existing cybersecurity.

AI systems still depend on:

Identity

Applications

APIs

Cloud

Containers

Networks

Databases

Secrets

Third Parties

Logging

Monitoring

Many AI compromises therefore begin with familiar weaknesses.

Examples:

Stolen credentials
Excessive permissions
Exposed APIs
Insecure cloud storage
Vulnerable applications
Poor secrets management
Weak supply-chain controls

AI introduces additional risks on top of these foundations.

3. Understand the AI System

Before assessing security, understand what has actually been built.

A simplified AI architecture might be:

User
 ↓
Web Application
 ↓
AI Orchestration Layer
 ↓
Prompt Construction
 ↓
LLM API
 ↓
Response

A more complex enterprise system may be:

User
 ↓
Enterprise Application
 ↓
AI Gateway
 ↓
AI Orchestrator
 ├─────────────┐
 ↓             ↓
LLM          Vector DB
 ↓             ↓
Tools       Enterprise Data
 ↓
External APIs

Each connection creates a trust relationship.

4. Understand AI Terminology

A Senior Security Consultant should understand at least:

Artificial Intelligence

Systems capable of performing tasks associated with human intelligence.

Machine Learning

Systems that learn patterns from data.

Generative AI

AI capable of generating content.

Large Language Model

A model trained on large amounts of textual information.

Prompt

Instructions or context supplied to an LLM.

Embedding

A numerical representation used to represent semantic relationships.

Vector Database

A system used to store and search embeddings.

RAG

Retrieval-Augmented Generation.

AI Agent

An AI system capable of reasoning about tasks and interacting with tools or systems.

5. Understand the AI Lifecycle

AI security should cover more than production inference.

Consider:

Data Collection
      ↓
Data Preparation
      ↓
Model Development / Selection
      ↓
Training / Fine-Tuning
      ↓
Evaluation
      ↓
Deployment
      ↓
Inference
      ↓
Monitoring
      ↓
Retirement

Security requirements can exist at every stage.

6. Enterprise AI Discovery

Before reviewing controls, understand AI usage.

Ask:

Which AI systems are deployed?

Who owns them?

Which models are used?

Where are they hosted?

Which data can they access?

Are third-party AI services used?

Can AI systems execute actions?

Are AI agents deployed?

How are models approved?

How are AI systems monitored?

7. Build an AI Asset Inventory

Track:

Without inventory, AI governance becomes difficult.

8. Identify Shadow AI

Employees may independently use public AI services.

Examples:

Employee
   ↓
Public AI Service
   ↓
Source Code

or:

Employee
   ↓
Public AI Service
   ↓
Customer Information

This can create:

Data leakage
Privacy risk
Intellectual-property exposure
Compliance risk

Shadow AI should therefore be considered during discovery.

9. Classify AI Systems by Risk

Not every AI system requires identical controls.

Consider:

Data sensitivity
Business criticality
External exposure
User population
Autonomy
Decision impact
Tool access
Regulatory impact

Example:

Internal FAQ Bot
→ Lower Risk

Customer Data Assistant
→ Higher Risk

Autonomous Financial Agent
→ Potentially Very High Risk

Risk determines control depth.

10. AI Threat Modelling

Use familiar threat-modelling principles.

Identify:

Assets
   ↓
Actors
   ↓
Entry Points
   ↓
Trust Boundaries
   ↓
Data Flows
   ↓
Privileges
   ↓
Threat Scenarios

Then identify AI-specific attack paths.

11. AI Assets

Assets may include:

Models
Training data
Prompts
System prompts
Embeddings
Vector databases
API credentials
AI plugins
Agent tools
Model outputs
Conversation histories
Enterprise knowledge
Model configuration

Understand which assets matter to the organisation.

12. AI Threat Actors

Potential actors include:

External attackers
Malicious users
Insiders
Compromised employees
Supply-chain attackers
Third-party providers

Threat modelling should remain realistic.

13. AI Attack Surface

An AI application may expose:

Web Interface

API

Prompt Interface

Model Endpoint

Vector Database

Plugins

Tools

File Upload

External Content

Agent Interfaces

Administration Interface

Each requires review.

14. Prompt Injection

Prompt injection attempts to manipulate an AI system’s instructions.

Example concept:

Trusted Instructions
       +
Untrusted Input
       ↓
LLM
       ↓
Manipulated Behaviour

The security problem becomes particularly significant when the model has access to sensitive information or privileged tools.

15. Direct Prompt Injection

A user intentionally supplies malicious instructions.

Conceptually:

User
 ↓
Malicious Prompt
 ↓
LLM
 ↓
Unexpected Behaviour

Impact depends on what the system is capable of doing.

16. Indirect Prompt Injection

Instructions may exist inside external content consumed by an AI system.

Example:

AI Agent
   ↓
External Website
   ↓
Malicious Embedded Instructions
   ↓
Agent Processing
   ↓
Manipulated Action

This becomes important for agents that browse, retrieve documents, or process email.

17. Prompt Injection Is Not Only a Prompt Problem

Do not rely solely on:

“Tell the model not to follow malicious instructions.”

A stronger architecture controls what the model can actually access and do.

Think:

Untrusted Input
      ↓
Model
      ↓
Restricted Tool Interface
      ↓
Authorisation
      ↓
Policy Enforcement
      ↓
Target Resource

Assume model behaviour may sometimes be manipulated.

Limit consequences.

18. Sensitive Information Disclosure

AI systems may expose:

Personal data
Credentials
Source code
Internal documents
Security architecture
Confidential business information

Potential paths include:

User
 ↓
AI Assistant
 ↓
Enterprise Retrieval
 ↓
Sensitive Document

Access control must continue to apply through AI interfaces.

19. RAG Security

Retrieval-Augmented Generation commonly follows:

User Question
      ↓
Embedding
      ↓
Vector Search
      ↓
Relevant Documents
      ↓
LLM Context
      ↓
Answer

Security questions include:

Who can query?
Which documents are indexed?
Are permissions preserved?
Can users retrieve documents they could not otherwise access?
Can malicious documents manipulate the model?

20. RAG Authorization

One of the most important questions is:

Does the retrieval layer preserve source-system authorization?

Weak architecture:

Employee
   ↓
AI Assistant
   ↓
Shared Vector Database
   ↓
All Enterprise Documents

Better:

Employee Identity
       ↓
Authorised Retrieval
       ↓
Permitted Documents
       ↓
LLM

AI must not become an authorization bypass.

21. Vector Database Security

Review:

Authentication
Authorization
Network exposure
Encryption
Tenant isolation
Data classification
Backup
Logging

Embeddings should not automatically be considered harmless data.

22. System Prompt Security

System prompts may contain:

Application instructions
Business rules
Workflow logic
Internal context
Security controls

Do not treat secrecy of the system prompt as the primary security boundary.

Security should survive even if some prompt behaviour becomes known.

23. Output Handling

AI output is untrusted.

If output is passed into:

HTML
SQL
Shell commands
APIs
Infrastructure tools

additional validation is required.

Conceptually:

LLM Output
    ↓
Validation
    ↓
Policy
    ↓
Execution

Do not assume model-generated output is safe.

24. Excessive Agency

AI agents become significantly more dangerous when they can perform high-impact actions.

Example:

AI Agent
│
├── Read Email
├── Access Documents
├── Create Tickets
├── Modify Cloud
└── Execute Scripts

A compromised decision process could now produce real-world consequences.

25. AI Agent Security

Assess:

Agent Identity

Agent Permissions

Available Tools

Tool Parameters

Data Access

External Inputs

Memory

Approval Requirements

Logging

Kill Mechanism

Agent security should be treated similarly to privileged workload security.

26. Agent Identity

Each agent should have a clearly defined identity.

Avoid:

AI Agent
   ↓
Shared Administrator Account

Prefer:

AI Agent
   ↓
Dedicated Workload Identity
   ↓
Least-Privilege Role

This improves both security and accountability.

27. Agent Least Privilege

Suppose an AI agent only needs to create service tickets.

It should not receive:

Ticket System Administrator

if it only requires:

Create Ticket
Read Assigned Ticket
Update Specific Fields

AI does not change least-privilege principles.

28. Human-in-the-Loop Controls

High-impact actions may require approval.

Example:

AI Recommendation
      ↓
Human Approval
      ↓
Privileged Action

Possible examples:

Delete production resource
Transfer money
Disable user
Change firewall
Deploy code

The level of human control should reflect risk.

29. Agent Tool Security

Review every available tool.

Ask:

What can this tool do?

Which parameters can the model control?

Which identity executes it?

Can actions be reversed?

Is approval required?

Is the activity logged?

Tool security may be more important than the model itself.

30. Agent Memory

AI agents may retain:

User information
Previous tasks
Credentials
Business context
Operational information

Review:

What Is Stored?

Where?

For How Long?

Who Can Access It?

Can It Be Deleted?

Can It Be Manipulated?

Memory creates another data-security surface.

31. AI Supply-Chain Security

AI systems depend on many external components.

Example:

Application
   ↓
AI Framework
   ↓
Model
   ↓
Model Repository
   ↓
Libraries
   ↓
Plugins
   ↓
External APIs

A weakness in any component may affect the application.

32. Model Supply Chain

Assess:

Model source
Provenance
Integrity
Licensing
Approval
Security evaluation
Update process

Downloading arbitrary models into enterprise environments creates risk.

33. AI Libraries and Frameworks

AI applications often depend heavily on:

Python packages
AI frameworks
Model libraries
Orchestration frameworks
Plugins

Apply standard software supply-chain controls:

Dependency Inventory

Approved Sources

Version Control

Vulnerability Scanning

Integrity Validation

Patch Management

34. Model Poisoning

Attackers may attempt to manipulate:

Training data
Fine-tuning data
Model artifacts
Knowledge sources

Conceptually:

Manipulated Data
      ↓
Training / Retrieval
      ↓
AI Behaviour

Protect the integrity of AI development pipelines.

35. Data Poisoning

Review:

Data sources
Data ownership
Data validation
Data lineage
Approval
Integrity monitoring

AI security and data governance are closely connected.

36. Model Theft

Models may represent significant intellectual property.

Potential controls include:

Access control
Network restrictions
Encryption
API controls
Monitoring
Rate limits
Asset governance

Assess the value of the model before determining control requirements.

37. Model Denial of Service

AI services can consume significant computational resources.

Attackers may attempt:

Large Request Volume
       ↓
High Model Consumption
       ↓
Resource Exhaustion
       ↓
Cost / Availability Impact

Consider:

Rate limiting
Quotas
Resource controls
Monitoring
Abuse detection

38. AI Cost Abuse

Cloud-hosted AI introduces another business impact:

Unexpected consumption costs.

Security reviews should therefore consider:

API quotas
Usage limits
Budget monitoring
Abuse detection
Authentication

39. AI API Security

Treat AI APIs like other enterprise APIs.

Review:

Authentication
Authorization
Input validation
Rate limiting
Network controls
Secrets
Logging
Abuse protection

Do not assume an API is secure because it calls an AI model.

40. AI Secrets Management

AI applications may use:

Model API keys
Database credentials
Cloud credentials
Search credentials
SaaS tokens

Avoid:

Source Code
   ↓
Hardcoded AI API Key

Use managed secret-storage mechanisms and workload identity where supported.

41. AI Infrastructure Security

AI workloads may run on:

Cloud VMs
Containers
Kubernetes
Managed AI platforms
Serverless services

Apply normal infrastructure controls.

Review:

IAM

Network

Compute

Containers

Secrets

Storage

Encryption

Logging

Patch Management

AI workloads are still workloads.

42. AI Cloud Security

Cloud AI services should be reviewed within the broader cloud architecture.

Consider:

Cloud Organisation
       ↓
AI Project / Account
       ↓
Identity
       ↓
AI Platform
       ↓
Model
       ↓
Data

Check whether enterprise cloud guardrails also cover AI resources.

43. AI Network Security

Review:

Public endpoints
Private connectivity
Egress
Model endpoints
Vector databases
Management interfaces
External APIs

Ask:

Does the AI workload actually require internet access?

44. AI Data Security

Determine what data enters:

Training

Fine-Tuning

Prompts

Retrieval

Conversation History

Agent Memory

Model Outputs

Each may have different security requirements.

45. Data Classification

Apply enterprise classification.

Example:

Public

Internal

Confidential

Restricted

Then determine which AI services may process each class.

46. Data Minimisation

Ask:

Does the model actually need all this information?

Instead of sending complete records, provide only required data.

Full Dataset
     ↓
Minimise
     ↓
Required Context
     ↓
AI

This reduces exposure.

47. Data Retention

Understand:

Are prompts retained?
Are responses retained?
Are conversations retained?
Are they used for training?
Where are they stored?
How are they deleted?

Retention should align with enterprise requirements.

48. Privacy

AI systems may process personal information.

Review:

Purpose
Data minimisation
Retention
Access
Transparency
Third-party processing
Cross-border considerations

Engage privacy and legal specialists when required.

49. AI Identity Architecture

Map:

Human Identity
      ↓
AI Application
      ↓
Application Identity
      ↓
Model
      ↓
Tool Identity
      ↓
Enterprise Resource

There may be multiple identity layers.

Do not assess only user login.

50. Identity Propagation

Suppose:

Alice
 ↓
AI Assistant
 ↓
Enterprise Search

The critical question is:

Does enterprise search operate using Alice’s authorization or a shared service identity?

A shared overprivileged identity can destroy access boundaries.

51. AI Authorization

Authentication answers:

Who is this?

Authorization answers:

What may they do?

AI systems may need authorization at:

Application
Model
Retrieval
Tool
Data
Agent-action

layers.

52. AI Logging

Capture appropriate events such as:

Authentication
Model access
Tool invocation
Administrative changes
Security-policy violations
Sensitive actions
Agent approvals

Be careful not to create new data leakage by indiscriminately logging sensitive prompts.

53. AI Security Monitoring

Possible monitoring signals:

Unusual Prompt Volume

Repeated Policy Violations

Unexpected Tool Calls

Privilege Failures

Sensitive Data Requests

Large Retrieval Activity

Abnormal API Usage

Unusual Agent Actions

Detection must be designed around the actual AI architecture.

54. AI Incident Response

Organisations should be prepared for scenarios such as:

Sensitive data disclosure
Compromised AI credentials
Prompt injection
Malicious agent actions
Model compromise
Poisoned knowledge sources
AI service outage

Define response processes before incidents occur.

55. AI Kill Switches

High-impact AI systems may require a way to rapidly:

Disable Agent

Disable Tool

Revoke Credential

Block Model Endpoint

Disable Integration

Return to Manual Processing

This is especially important for autonomous systems.

56. AI Security Testing

Testing may include:

Architecture review
Threat modelling
Access-control testing
Prompt-injection testing
Data leakage testing
Agent abuse testing
API testing
Supply-chain review
Logging validation

Testing should reflect the actual system.

57. AI Red Teaming

AI red teaming attempts to identify how an AI system might fail or be abused.

Areas may include:

Prompt Manipulation

Data Disclosure

Tool Abuse

Unsafe Actions

Authorization Bypass

Agent Manipulation

External Content Attacks

Senior consultants should understand how red-team results translate into enterprise risk and remediation.

58. Use Established AI Security References

AI security assessments can be informed by established industry guidance such as:

OWASP guidance for LLM and Generative AI applications
MITRE ATLAS
NIST AI Risk Management Framework
Cloud-provider AI security guidance
Organisational secure-development standards

Do not blindly convert frameworks into checklists.

Use them to support structured analysis.

59. AI Governance

Technology controls alone are insufficient.

Enterprise AI governance should address:

Ownership

Approved Use

Risk Classification

Data

Security

Privacy

Model Selection

Third Parties

Monitoring

Incident Management

Lifecycle

AI governance connects technical implementation to enterprise accountability.

60. AI Acceptable Use

Organisations may define:

Approved AI services
Permitted data
Prohibited data
Permitted business use
Development requirements
Human-review requirements

Policies should be practical enough that employees can follow them.

61. AI Risk Assessment

A structured AI risk assessment can follow:

Business Use Case
      ↓
AI Architecture
      ↓
Data
      ↓
Users
      ↓
Model
      ↓
Integrations
      ↓
Autonomy
      ↓
Threats
      ↓
Controls
      ↓
Residual Risk

62. AI Risk Scenario Example

Observation:

The customer-support AI agent can issue account credits using a shared service account without secondary approval.

Threat scenario:

Manipulation of the agent or compromise of the AI application could result in unauthorised account-credit transactions.

Potential impact:

Financial loss
Fraud
Customer disputes
Operational impact

63. AI Finding Example

Finding

AI Agent Uses Excessive Privileges for Customer Account Operations

Observation

The customer-support AI agent authenticates to the customer-management platform using a service account capable of modifying multiple account attributes beyond those required by the AI workflow.

Risk

If the agent is manipulated or the service identity is compromised, excessive permissions could enable unauthorised modification of customer accounts.

Recommendation

Implement a dedicated workload identity with permissions restricted to explicitly approved actions and introduce human approval for high-impact transactions.

64. AI Risk Register

Possible fields:

AI Risk ID

AI System

Business Owner

Use Case

Data Classification

Model

Threat Scenario

Existing Controls

Likelihood

Impact

Residual Risk

Treatment

Owner

Integrate AI risk into enterprise risk management where practical.

65. AI Third-Party Risk

Many organisations consume AI through vendors.

Assess:

Data processing
Retention
Model training
Security controls
Access
Subprocessors
Incident notification
Availability
Exit strategy

Do not assess AI vendors solely through technical controls.

66. AI Vendor Questions

Ask:

Is customer data used to train models?

Where is data processed?

How long is it retained?

Which administrators can access it?

Which subprocessors are involved?

How are incidents reported?

How is tenant isolation implemented?

What happens when the contract ends?

67. AI Governance Operating Model

A possible structure:

Executive Governance
       ↓
AI Governance Committee
       ↓
Security + Privacy + Legal + Risk
       ↓
AI Platform Team
       ↓
Application Teams

Responsibilities should be explicit.

68. AI Security Architecture Review

A Senior Security Consultant can use:

Business Use Case
      ↓
Architecture
      ↓
Trust Boundaries
      ↓
Identity
      ↓
Data
      ↓
Model
      ↓
Retrieval
      ↓
Tools
      ↓
External Integrations
      ↓
Logging
      ↓
Threat Model

This extends the architecture-review methodology you already learned.

69. AI Architecture Review Questions

Ask:

Users

Who interacts with the system?

Model

Which model is used?

Hosting

Where does it run?

Data

What information enters the system?

Retrieval

Which knowledge sources are available?

Identity

Which identities are used?

Tools

What actions can the model perform?

External Access

Which external services are contacted?

Monitoring

What activity is recorded?

70. Example Enterprise AI Architecture

Employee
   ↓
Entra ID
   ↓
Internal AI Portal
   ↓
AI Gateway
   ↓
LLM Orchestrator
   ├──────────────┐
   ↓              ↓
Enterprise RAG   AI Agent
   ↓              ↓
Vector DB       ServiceNow
   ↓              ↓
Internal Docs   IT Actions

Now identify the trust boundaries.

71. Threat Model the Architecture

Potential scenarios:

Compromised Employee
      ↓
AI Portal
      ↓
Unauthorized Retrieval

Malicious Document
      ↓
RAG
      ↓
Indirect Prompt Injection
      ↓
Agent
      ↓
Unauthorized Action

Compromised Agent Identity
      ↓
ServiceNow
      ↓
Privileged IT Action

The complete architecture matters.

72. Identify Blast Radius

Ask:

If the AI system is compromised, what can the attacker reach?

Example:

AI Application
      ↓
Agent Identity
      ↓
IT Management
      ↓
Cloud Administration
      ↓
Production

This would represent a very different risk from a chatbot that can only answer public FAQs.

73. Apply Assume-Compromise Thinking

Ask:

What happens if the model follows a malicious instruction?

Then determine whether surrounding controls contain the damage.

Manipulated Model
      ↓
Restricted Identity
      ↓
Restricted Tool
      ↓
Approval
      ↓
Limited Impact

This is a powerful AI security design principle.

74. AI Security Control Layers

Think in layers:

Governance
    ↓
Identity
    ↓
Application
    ↓
Model
    ↓
Data
    ↓
Tool
    ↓
Infrastructure
    ↓
Monitoring

No single layer should be responsible for all security.

75. Secure AI Design Principles

Useful principles include:

Least privilege
Strong identity
Explicit authorization
Data minimisation
Secure defaults
Separation of duties
Human approval for high-impact actions
Treat external input as untrusted
Treat model output as untrusted
Defence in depth
Comprehensive monitoring
Fail safely

These are familiar security principles applied to AI systems.

76. AI Security Assessment Methodology

Use:

Define Objective
      ↓
Identify AI Systems
      ↓
Classify Risk
      ↓
Understand Architecture
      ↓
Map Data
      ↓
Map Identity
      ↓
Map Tools
      ↓
Threat Model
      ↓
Assess Controls
      ↓
Test Critical Scenarios
      ↓
Determine Risk
      ↓
Recommend

77. AI Security Assessment Domains

A reusable assessment structure:

01 Governance

02 Asset Management

03 Architecture

04 Identity & Access

05 Data Protection

06 LLM Security

07 RAG Security

08 Agent Security

09 Application Security

10 Infrastructure Security

11 Supply Chain

12 Logging & Monitoring

13 Incident Response

14 Third-Party Risk

78. AI Security Maturity

A simple maturity model:

Level 1 — Ad Hoc

AI is deployed with little central governance.

Level 2 — Developing

Initial policies and inventories exist.

Level 3 — Defined

AI security requirements are standardised.

Level 4 — Managed

Controls are monitored and measured.

Level 5 — Optimised

Security is continuously evaluated and automated.

Avoid maturity scoring without evidence.

79. AI Transformation Roadmap

An organisation beginning AI governance might use:

0–3 Months — Discover

AI inventory
Approved-use policy
Critical-risk identification
Shadow-AI assessment

3–6 Months — Standardise

AI security standard
Architecture review process
Data requirements
Vendor requirements

6–12 Months — Engineer

AI gateway
Identity integration
Monitoring
Secure RAG
Agent controls

12–24 Months — Optimise

Continuous assessment
AI red teaming
Automated governance
Continuous monitoring

80. Using AI as a Security Consultant

AI can also improve consulting productivity.

Possible workflow:

Consultant
   ↓
AI Assistant
   ↓
Research
Analysis
Drafting
Structuring

But the consultant remains responsible for:

Accuracy
Confidentiality
Risk judgement
Final recommendations

81. AI for Discovery Preparation

AI can help develop:

Interview questions
Evidence requests
Assessment checklists
Workshop agendas

Example task:

Generate discovery questions for an enterprise privileged-access assessment covering governance, authentication, PAM, JIT, service accounts, emergency access, access reviews, and monitoring.

Review and tailor the output before use.

82. AI for Architecture Analysis

AI can help structure questions around an architecture.

For example:

Architecture Description
       ↓
AI
       ↓
Potential Trust Boundaries
       ↓
Potential Threats
       ↓
Review Questions

But AI should not replace your architecture analysis.

83. AI for Threat Modelling

Provide a sanitised architecture description and ask AI to identify:

Assets
Entry points
Trust boundaries
Threat actors
Abuse cases
Attack paths

Then validate the output.

AI may identify possibilities.

You determine whether they are realistic.

84. AI for Control Mapping

AI can help map a technical observation against multiple frameworks.

Example:

Security Finding
      ↓
AI Assistance
      ↓
NIST
ISO
CIS
Internal Standard

Always validate framework references before using them in a deliverable.

85. AI for Evidence Analysis

AI may help organise large sets of authorised evidence.

Possible tasks:

Summarisation
Comparison
Pattern identification
Missing-control identification
Evidence categorisation

However:

Never upload confidential client evidence to an AI service unless its use is explicitly authorised and appropriately protected.

86. AI for Finding Development

AI can help improve structure.

Example input:

Observation:
18 production cloud roles have wildcard administrative permissions.

Evidence:
IAM export.

Context:
Roles are used by engineering teams.

Existing Controls:
MFA for human users.

AI can help draft:

Finding title
Observation
Risk statement
Recommendation

The consultant must validate every conclusion.

87. AI for Report Drafting

AI can assist with:

Grammar
Structure
Conciseness
Executive translation
Formatting

Useful transformation:

Technical Finding
      ↓
AI Draft
      ↓
Executive Language
      ↓
Consultant Validation

Do not allow AI to invent evidence or conclusions.

88. AI for Executive Communication

AI can help transform:

38 technically detailed findings

into candidate themes such as:

Identity Governance

Cloud Governance

Security Visibility

Exposure Management

The consultant decides whether those themes accurately represent the assessment.

89. AI for Meeting Preparation

AI can help prepare:

Stakeholder questions
Workshop structure
Technical follow-ups
Executive briefing points

This can reduce preparation time.

90. AI for Knowledge Management

A consultant can use approved AI tooling to organise:

Framework Knowledge

Architecture Patterns

Assessment Questions

Risk Scenarios

Finding Patterns

Remediation Guidance

This can become a powerful consulting knowledge system.

91. AI Hallucination Risk

AI may generate:

Incorrect facts
Nonexistent controls
Incorrect framework references
Incorrect product capabilities
Invented vulnerabilities

Therefore:

AI Output
   ↓
Verify
   ↓
Validate
   ↓
Use

Never:

AI Output
   ↓
Client Report

without professional review.

92. AI Confidentiality Risk

Before providing information to AI, ask:

Is This Client Confidential?

Does It Contain Personal Data?

Does It Contain Credentials?

Does It Reveal Architecture?

Is This AI Service Approved?

Is Retention Understood?

If the answer creates uncertainty, do not upload the information until governance permits it.

93. AI Should Not Make Risk Decisions

AI may assist analysis.

But final risk decisions require human judgement.

Why?

Because risk depends on:

Business context
Threat reality
Existing controls
Risk appetite
Operational constraints

These are often incomplete or nuanced.

94. AI Should Not Invent Evidence

Never allow generated content such as:

“The organisation does not conduct quarterly access reviews.”

unless evidence supports that statement.

Consulting conclusions must remain evidence-based.

95. Responsible AI Consulting Workflow

Use:

Consultant Question
      ↓
Approved Data
      ↓
AI Assistance
      ↓
Consultant Validation
      ↓
Evidence Check
      ↓
Professional Judgement
      ↓
Final Deliverable

AI supports the consultant.

It does not become the consultant.

96. AI Consulting Guardrails

Establish personal guardrails:

No Credentials

No Secrets

No Unapproved Client Data

No Blind Trust

No Invented Evidence

No Automatic Risk Ratings

No Unverified Framework Mapping

Human Review Required

These should become habitual.

97. Practical Scenario — Enterprise AI Assistant

A multinational organisation introduces an AI assistant.

Architecture:

Employees
   ↓
Enterprise AI Portal
   ↓
LLM
   ↓
RAG
   ↓
SharePoint + Internal Documents

The organisation asks:

“Is this secure enough for enterprise deployment?”

98. Step 1 — Understand the Business Use Case

Determine:

Users
Purpose
Business owner
Criticality
Expected data
Restricted use cases

Do not begin with prompt testing.

99. Step 2 — Map the Data

Employee Prompt
      ↓
AI Application
      ↓
Retrieval
      ↓
Internal Documents
      ↓
LLM
      ↓
Response

Ask where data is:

Stored
Processed
Logged
Retained

100. Step 3 — Map Identity

Employee Identity
      ↓
AI Portal
      ↓
Retrieval Identity
      ↓
Document Platform

Determine whether user authorization is preserved.

101. Step 4 — Identify Threats

Potential scenarios:

Prompt injection
Sensitive information disclosure
Unauthorized retrieval
Malicious documents
Account compromise
AI service compromise
Excessive logging
Third-party data exposure

102. Step 5 — Assess Controls

Review:

SSO

MFA

Authorization

Document Permissions

Data Classification

AI Gateway

Prompt Controls

Output Controls

Logging

Monitoring

Vendor Controls

103. Step 6 — Identify Major Finding

Suppose retrieval uses one shared service identity with access to all internal documents.

Finding:

Enterprise AI Retrieval Does Not Preserve Source-System Access Controls

Risk:

Users may retrieve information through the AI assistant that they are not authorised to access directly.

This is primarily an authorization architecture problem.

Employee
   ↓
Enterprise Identity
   ↓
AI Portal
   ↓
Identity-Aware Retrieval
   ↓
Authorised Documents
   ↓
LLM

Preserve authorization through the retrieval process.

105. Practical Scenario — AI Security Agent

The SOC deploys an AI agent that can:

Query SIEM
Investigate alerts
Disable accounts
Isolate endpoints

Architecture:

SIEM Alert
   ↓
AI Agent
   ↓
Investigation
   ↓
Decision
   ├── Disable User
   └── Isolate Endpoint

This is a high-impact system.

106. Identify Agent Risk

Potential attack path:

Manipulated Security Event
      ↓
AI Agent
      ↓
Incorrect Decision
      ↓
Disable Critical Account
      ↓
Business Disruption

Or:

Prompt Injection
      ↓
AI Agent
      ↓
Endpoint Isolation
      ↓
Operational Impact

107. Design Agent Guardrails

Possible target:

AI Investigation
      ↓
Recommended Action
      ↓
Policy Validation
      ↓
Human Approval
      ↓
Security Action

For lower-risk actions, controlled automation may be appropriate.

For high-impact actions, stronger approval may be required.

108. AI Security Finding Themes

Common enterprise themes may include:

AI Governance

AI Asset Visibility

Data Protection

Identity & Access

RAG Authorization

Agent Privilege

AI Supply Chain

Monitoring

Third-Party AI

AI Incident Response

Avoid creating dozens of disconnected AI findings when systemic themes exist.

109. Senior Consultant AI Questions

During an AI engagement ask:

Business

What business problem does the AI system solve?

Ownership

Who is accountable for it?

Architecture

How does the system work?

Model

Which models are used?

Data

What information can the AI access?

Identity

Which identities operate each component?

Retrieval

Are source permissions preserved?

Agent

What actions can the system perform?

Tools

What privileges do those tools have?

Third Party

Where does enterprise data leave the organisation?

Monitoring

Can misuse be detected?

Response

Can the AI system be rapidly disabled?

110. AI Security Review Checklist

Use:

[ ] Business use case understood
[ ] AI owner identified
[ ] AI system inventoried
[ ] Risk classification established
[ ] Architecture documented
[ ] Models identified
[ ] Hosting identified
[ ] Data flows mapped
[ ] Data classification understood
[ ] Retention reviewed
[ ] User identities reviewed
[ ] Workload identities reviewed
[ ] Authorization reviewed
[ ] RAG architecture reviewed
[ ] Source permissions validated
[ ] Vector database security reviewed
[ ] Prompt injection considered
[ ] Output handling reviewed
[ ] Agent capabilities identified
[ ] Agent privileges reviewed
[ ] Tool permissions reviewed
[ ] Human approval requirements reviewed
[ ] Secrets management reviewed
[ ] AI APIs reviewed
[ ] Infrastructure security reviewed
[ ] Supply-chain dependencies reviewed
[ ] Third-party AI reviewed
[ ] Logging reviewed
[ ] Monitoring reviewed
[ ] Incident response reviewed
[ ] Kill mechanisms considered
[ ] Security testing performed
[ ] Findings validated
[ ] Residual risks documented
[ ] Risk owners identified
[ ] Remediation roadmap created

111. Build Your AI Security Consultant Toolkit

Create:

AI Security Consultant Toolkit/
│
├── 01 AI Discovery Questionnaire
├── 02 AI Asset Inventory
├── 03 AI Risk Classification
├── 04 AI Architecture Review Checklist
├── 05 AI Threat Model
├── 06 LLM Security Checklist
├── 07 RAG Security Checklist
├── 08 AI Agent Security Checklist
├── 09 AI Data Security Checklist
├── 10 AI IAM Checklist
├── 11 AI Supply Chain Checklist
├── 12 AI Vendor Assessment
├── 13 AI Risk Register
├── 14 AI Finding Template
├── 15 AI Security Assessment Report
└── 16 AI Security Roadmap

112. Build an AI Consulting Prompt Library

For approved use cases, maintain reusable prompts for:

Discovery Questions

Architecture Review

Threat Modelling

Attack Path Analysis

Control Mapping

Finding Structuring

Executive Translation

Report QA

Never include sensitive information in templates.

113. AI Security Consultant Capability Model

Your capability should develop across:

AI Fundamentals
      ↓
AI Architecture
      ↓
AI Threats
      ↓
AI Security Controls
      ↓
AI Governance
      ↓
AI Risk
      ↓
Enterprise AI Consulting

You do not need to become a machine-learning engineer to provide valuable AI security consulting.

114. Senior Security Consultant + AI

The future Senior Security Consultant increasingly needs to combine:

Enterprise Security
        +
Cloud Security
        +
Architecture
        +
Risk
        +
AI Security
        +
Consulting
        =
Modern Security Advisory

AI should become another architecture domain that you can assess within the broader enterprise.

Key Takeaways

AI introduces new security concerns, but it does not eliminate established security principles.

Always begin with:

Business
   ↓
Architecture
   ↓
Data
   ↓
Identity
   ↓
Trust
   ↓
Threat
   ↓
Controls
   ↓
Risk

Then add AI-specific considerations such as:

Prompt injection
RAG security
Model security
Agent autonomy
Tool abuse
AI supply chain
Model/data poisoning
AI governance

For AI agents, remember:

The most important question may not be what the model can say. It may be what the model is allowed to do.

For enterprise AI:

AI must not become a shortcut around existing identity, authorization, data-protection, and governance controls.

And when using AI as a consultant:

AI Assistance
      +
Human Validation
      +
Evidence
      +
Professional Judgement
      =
Responsible AI-Assisted Consulting

AI can accelerate analysis.

AI can improve drafting.

AI can support research.

AI can help organise information.

But the Senior Security Consultant remains responsible for:

Accuracy
Evidence
Risk judgement
Recommendations
Confidentiality
Client outcomes

Learning Path Complete

You have now completed the Senior Security Consultant Learning Path.

Your journey covered:

00 Start Here
      ↓
01 Security Consulting Foundations
      ↓
02 Security Assessments
      ↓
03 Architecture Reviews
      ↓
04 Cloud Security Reviews
      ↓
05 Risk & Compliance
      ↓
06 Client Reporting
      ↓
07 Security Transformation
      ↓
08 Consulting Projects
      ↓
09 Enterprise Engagements
      ↓
10 Interview Preparation
      ↓
11 Career Resources
      ↓
AI for Sr Security Consultant

You have moved from understanding how security consulting works to developing a complete enterprise consulting mindset.

The final professional model is:

Understand the Business
        ↓
Understand the Architecture
        ↓
Identify Critical Assets
        ↓
Map Identity & Data
        ↓
Understand Threats
        ↓
Evaluate Controls
        ↓
Identify Attack Paths
        ↓
Determine Business Risk
        ↓
Develop Practical Recommendations
        ↓
Communicate Clearly
        ↓
Build the Roadmap
        ↓
Help the Organisation Improve

That is the mindset of a Senior Security Consultant.

Continue Building

Do not stop with the documentation.

Use the learning path to repeatedly practise:

Assess → Analyse → Design → Document → Present → Improve

Build your consulting toolkit.

Complete realistic enterprise projects.

Practise architecture reviews.

Write professional findings.

Build risk registers.

Create executive presentations.

Develop security roadmaps.

Review AI systems.

And most importantly:

Learn to connect technology, architecture, threats, controls, risk, and business decisions.

That ability is what turns cybersecurity knowledge into professional security consulting capability.