Realistic Practice. AI Security. Adaptive Learning. Exam Readiness.
Aligned with the latest ISC2 CISSP Exam Outline
Practice across all eight CISSP domains
🟠No registration🔵 Instant Access 🟡 Works on Any Device
AI Security in CISSP Domain 3
Security Architecture and Engineering
AI introduces new attack surfaces, but secure architecture still begins with trusted design principles.
For CISSP Domain 3 — Security Architecture and Engineering — candidates should think beyond protecting an AI application. The real challenge is designing an environment where models, training data, prompts, outputs, APIs, infrastructure, and trust boundaries are protected as an integrated system.
The key CISSP question is:
How do we architect AI securely rather than trying to secure it after deployment?
That distinction—security by design instead of security as an afterthought—is central to Domain 3.
Why AI Security Matters in CISSP Domain 3
AI systems introduce components that may not exist in traditional architectures:
AI and machine-learning models;
training and fine-tuning datasets;
prompts and system instructions;
model outputs;
inference engines;
AI APIs;
vector databases;
retrieval-augmented generation (RAG) systems;
plugins and external tools;
model repositories;
GPUs and specialized infrastructure; and
third-party foundation models.
Each component creates assets, interfaces, dependencies, and trust boundaries that security architects must understand.
The CISSP mindset remains:
Design security into the architecture based on risk, rather than relying on one protective technology.
1. Threat Modeling AI Systems
Before selecting AI security controls, understand what can go wrong.
Threat modeling should identify:
Assets — What must be protected?
Threat actors — Who might attack or misuse the system?
Attack surfaces — Where can interaction occur?
Trust boundaries — Where does information move between different levels of trust?
Threats — What could compromise confidentiality, integrity, or availability?
Controls — How should identified risks be reduced?
For an AI application, the architecture may resemble:
User → Application → AI Model → Data Source → External Tools
Every transition deserves scrutiny.
CISSP Exam Thinking
Do not begin with:
“Which AI security product should we buy?”
Begin with:
“What are we protecting, from whom, and where are the trust boundaries?”
2. Prompt Injection Is a Trust-Boundary Problem
Prompt injection occurs when malicious or untrusted instructions influence an AI system's behavior.
An attacker may attempt to make the system:
ignore instructions;
reveal sensitive information;
perform unauthorized actions;
manipulate output;
access connected resources; or
misuse integrated tools.
The deeper architectural lesson is important:
Untrusted input should never automatically become trusted instruction.
Prompt injection cannot be addressed reliably by simply telling a model to “ignore malicious prompts.”
Security architecture should consider:
input validation;
privilege restrictions;
output validation;
separation of trusted instructions from untrusted content;
limited tool permissions;
human approval for consequential actions; and
monitoring.
CISSP Insight
Treat AI-generated decisions and instructions according to their trust level, not according to how confidently the model presents them.
3. Least Privilege Becomes Critical for AI Agents
Modern AI systems may interact with:
databases;
email;
cloud services;
APIs;
source-code repositories;
ticketing systems;
business applications; and
administrative tools.
Giving an AI agent broad privileges creates significant risk.
If the model is manipulated, compromised, or simply wrong, excessive permissions can turn an incorrect output into a damaging action.
The traditional principle remains:
Grant only the minimum access required to perform the authorized function.
For AI agents, this may mean:
read-only rather than write access;
restricted API scopes;
limited datasets;
isolated service accounts;
transaction limits; and
approval before sensitive actions.
CISSP Exam Thinking
When choosing between making an AI system more capable and reducing unnecessary privilege, CISSP security architecture generally favors least privilege consistent with business requirements.
4. Defense in Depth for AI
There is no single “AI security control” capable of protecting the entire system.
A secure architecture may combine:
Identity controls — authentication and authorization.
Data controls — classification, encryption, access restrictions, and loss prevention.
Application controls — input and output validation.
Model controls — model testing and behavioral safeguards.
Network controls — segmentation and restricted communication.
Monitoring controls — logging, anomaly detection, and security monitoring.
Human controls — approval for high-impact actions.
Governance controls — policies, standards, risk assessments, and oversight.
If one control fails, another should reduce the likelihood or impact of compromise.
AI security should be layered, not dependent on a single safeguard.
5. Secure AI Architecture Requires Isolation
AI workloads may process untrusted input while simultaneously accessing sensitive organizational resources.
That combination creates architectural risk.
Isolation can limit the blast radius of compromise.
Examples include:
sandboxing;
workload isolation;
containerization;
network segmentation;
separate development and production environments;
dedicated service identities;
restricted API access; and
controlled execution environments.
CISSP Principle
Do not give an untrusted or partially trusted component unrestricted access to trusted resources.
This principle predates AI and remains highly relevant to it.
6. Protect AI Model Integrity
AI models themselves can be valuable organizational assets.
Attackers may attempt to:
alter models;
replace models;
introduce malicious models;
manipulate training processes;
compromise model repositories; or
tamper with configuration.
Organizations therefore need assurance that the model running in production is the authorized and expected model.
Controls may include:
integrity verification;
controlled model repositories;
digital signatures;
cryptographic hashes;
access controls;
version management;
change control; and
secure deployment pipelines.
CISSP Insight
Protecting AI is not only about confidentiality.
Model integrity can be critical to trustworthy system behavior.
7. Training Data Poisoning
An AI system learns from information.
If an attacker can manipulate training or fine-tuning data, the resulting model behavior may also be manipulated.
This is known broadly as data poisoning.
Possible consequences include:
inaccurate predictions;
biased behavior;
hidden malicious behavior;
weakened security decisions; or
unreliable outputs.
Architectural defenses may include:
trusted data sources;
provenance tracking;
access control;
integrity verification;
validation;
change management; and
monitoring of training pipelines.
CISSP Exam Thinking
When the concern is unauthorized modification of training data, think primarily about integrity.
8. Model Supply Chain Security
Organizations rarely build every AI component themselves.
AI architectures may depend on:
pretrained models;
open-source libraries;
datasets;
APIs;
cloud platforms;
plugins;
extensions;
development frameworks; and
third-party model repositories.
This creates an AI supply chain.
A compromised component may affect the entire system.
Organizations should consider:
source trustworthiness;
component provenance;
vulnerability management;
integrity verification;
version control;
dependency management;
vendor assessment; and
controlled deployment.
CISSP Rule
A system is not automatically trustworthy simply because a component came from a popular source.
Trust should be established through appropriate assurance.
9. Encryption Still Matters—but It Is Not the Whole Answer
AI does not make traditional cryptography obsolete.
Sensitive AI information may require protection:
At rest — datasets, models, embeddings, logs, configuration.
In transit — communication between users, applications, APIs, models, and data sources.
Organizations must also protect cryptographic keys appropriately.
But CISSP candidates should avoid treating encryption as a universal answer.
Encryption cannot by itself prevent:
excessive privileges;
prompt injection;
poisoned training data;
insecure architecture;
unauthorized processing;
malicious outputs; or
poor governance.
Exam Trap
If the question asks for the best architectural approach, “encrypt everything” is rarely sufficient.
Think layered security architecture.
10. RAG Systems Create New Trust Relationships
Retrieval-Augmented Generation allows an AI system to retrieve external information before generating a response.
A simplified flow may be:
User → AI Application → Retrieval System → Organizational Data → Model → Response
This creates several questions:
Is the user authorized to access the retrieved information?
Can one user retrieve another user's data?
Can malicious documents manipulate model behavior?
Are retrieval sources trusted?
Can sensitive information leak into output?
Are permissions enforced before retrieval?
CISSP Insight
The AI model should not become a shortcut around existing authorization controls.
AI must respect the security boundaries of the underlying information systems.
11. Fail Securely
AI systems can produce unpredictable or incorrect results.
Security architecture should therefore consider what happens when:
the model fails;
confidence is low;
a dependency becomes unavailable;
suspicious activity occurs;
validation fails; or
the AI attempts an unauthorized action.
A secure design should prefer a safe state rather than continuing risky operations.
For example, a financial AI agent unable to validate a high-value transaction should not simply proceed because the model believes the transaction is legitimate.
CISSP Principle
Failure should not automatically result in increased access or reduced protection.
12. Human-in-the-Loop as an Architectural Control
Human oversight is not merely a governance concept.
It can also be an architectural security control.
For low-risk tasks, automated execution may be appropriate.
For high-impact actions, architecture can require human approval before execution.
Examples include:
deleting production data;
transferring funds;
changing security configurations;
granting privileges;
executing code;
disabling security controls; or
taking consequential actions against users.
The greater the potential impact, the stronger the case for independent validation.
AI autonomy should be proportional to business risk.
AI Security Architecture: The CISSP Mental Model
When confronted with an AI architecture question, think:
Assets → Threats → Trust Boundaries → Least Privilege → Isolation → Layered Controls → Monitoring → Safe Failure
Do not ask only:
“How do I secure the AI model?”
Ask:
“How do I secure the entire system in which the AI model operates?”
That is the Domain 3 perspective.
Example CISSP Question
An organization deploys an AI agent that can analyze security incidents and execute remediation actions across production systems. What is the BEST architectural approach to reduce the risk of an incorrect or manipulated AI decision causing widespread damage?
A. Increase the amount of training data available to the modelB. Give the AI administrator privileges so remediation can occur quicklyC. Restrict the agent to minimum necessary privileges and require approval for high-impact actionsD. Encrypt all communication between the AI agent and production systems
Best answer: C
Encryption protects communications, but it does not prevent an authorized AI agent from performing a harmful action.
More training data does not eliminate unpredictable behavior.
Administrator privileges would increase the potential impact.
Least privilege combined with approval for high-impact actions reduces the blast radius of both compromise and error.
High-Yield AI Security Rules for CISSP Domain 3
Remember these principles:
Secure AI by design, not after deployment.
Threat-model the entire AI system, not only the model.
Treat untrusted input as untrusted—even when processed by AI.
Apply least privilege to AI agents and connected tools.
Use defense in depth rather than relying on one AI safeguard.
Isolate AI workloads when they process untrusted content.
Protect model and training-data integrity.
Evaluate AI models, libraries, datasets, and APIs as supply-chain dependencies.
Encryption is necessary in many cases but does not fix insecure architecture.
AI must not bypass authorization controls protecting underlying information.
Design systems to fail securely.
Require human approval when automated actions could create unacceptable impact.
Final CISSP Takeaway
Domain 3 asks you to think like a security architect, not an AI developer.
The strongest CISSP answer will usually protect the system through sound architectural principles:
least privilege, separation, isolation, defense in depth, trusted components, secure failure, cryptographic protection, integrity, and appropriate human oversight.
AI introduces new attack techniques such as prompt injection and data poisoning, but the architectural lesson is timeless:
Never give an uncertain component more trust, access, or authority than the business requirement demands.
That is AI Security through the lens of CISSP Domain 3.


