CY0-001 — CompTIA SecAI+ (CY0-001) Exam Blueprint
Practical CY0-001 AI security exam blueprint for CompTIA SecAI+ final review.
How to Use This Exam Blueprint
Use this checklist as a practical readiness map for the CompTIA SecAI+ (CY0-001) exam. It is organized around the kinds of AI security knowledge, decisions, controls, and troubleshooting judgment a candidate should be able to apply.
Because exact official weighting is not provided here, the sections below are presented as readiness areas, not as guaranteed exam percentages. For best results:
- Review each topic area.
- Mark items you can explain and apply without notes.
- For weak areas, practice with short scenarios: identify the risk, choose a control, justify the tradeoff.
- In the final week, focus on missed decision points, vocabulary gaps, and scenario speed.
Topic-area readiness table
| Readiness area | What to know | What “ready” looks like |
|---|---|---|
| AI, ML, and generative AI fundamentals | Model types, training vs. inference, supervised/unsupervised learning, embeddings, tokens, prompts, agents, RAG, model evaluation | You can explain how an AI system works at a security-relevant level without turning every question into generic cybersecurity |
| AI risk and governance | Risk assessment, policy, ownership, acceptable use, data classification, auditability, third-party risk, human oversight | You can map an AI use case to risk controls and governance artifacts |
| Secure AI system architecture | Data pipelines, model endpoints, APIs, identity, network segmentation, secrets, storage, logging, deployment boundaries | You can identify where controls belong in an AI workflow |
| Data security and privacy | Sensitive data handling, consent, minimization, masking, tokenization, anonymization, encryption, retention, data lineage | You can recognize privacy leakage and choose practical data protection controls |
| Adversarial AI threats | Prompt injection, poisoning, evasion, model extraction, model inversion, membership inference, jailbreaking, hallucination abuse | You can match attack patterns to mitigations |
| Generative AI and LLM security | System prompts, prompt hierarchy, plugins/tools, agents, RAG, embeddings, vector stores, output handling | You can secure an LLM application beyond “filter the prompt” |
| MLOps and LLMOps security | Model registry, CI/CD, pipeline integrity, model versioning, reproducibility, evaluation gates, rollback, drift monitoring | You can secure the lifecycle from development through production monitoring |
| Application and API security for AI | Authentication, authorization, rate limiting, input validation, output encoding, API gateway controls, abuse prevention | You can apply normal AppSec controls to AI-specific data flows |
| Cloud, infrastructure, and endpoint controls | IAM, compute isolation, storage permissions, network access, key management, container security, workload monitoring | You can select infrastructure controls that reduce AI workload risk |
| Security monitoring and incident response | AI logs, prompt logs, model behavior telemetry, anomaly detection, alert triage, containment, evidence preservation | You can respond to AI incidents without destroying forensic value |
| Testing and validation | Red teaming, prompt testing, bias/fairness checks, security evaluations, regression testing, adversarial testing | You can design tests that reveal misuse, leakage, unsafe behavior, or degraded performance |
| Compliance and ethics | Privacy, explainability, accountability, fairness, transparency, safety, documentation, audit trails | You can distinguish compliance, ethics, and security concerns in scenarios |
AI and machine learning fundamentals checklist
Core concepts to review
- Explain the difference between training, validation, testing, and inference.
- Distinguish model, algorithm, dataset, feature, label, embedding, token, and parameter.
- Recognize when a system uses:
- Supervised learning
- Unsupervised learning
- Reinforcement learning
- Deep learning
- Generative AI
- Retrieval-augmented generation
- Agentic workflows
- Explain why AI systems can fail differently from deterministic software.
- Identify where randomness, probability, confidence scores, thresholds, and model uncertainty affect security decisions.
- Describe the difference between model behavior and application behavior.
- Recognize the security impact of:
- Overfitting
- Underfitting
- Drift
- Hallucination
- Bias
- Data leakage
- Model degradation
Can you do this?
| Prompt | Ready if you can… |
|---|---|
| A model performs well in testing but poorly in production. | Identify possible causes such as drift, data mismatch, overfitting, changed inputs, or pipeline defects. |
| A chatbot gives confident but false answers. | Explain hallucination risk and controls such as grounding, retrieval constraints, citations, validation, and human review. |
| A model makes security decisions using a threshold. | Explain the tradeoff between false positives and false negatives. |
| A team wants to train a model on all available business data. | Identify data classification, privacy, consent, minimization, and retention concerns. |
AI security governance and risk management
Governance artifacts to recognize
| Artifact | Purpose | Exam-readiness cue |
|---|---|---|
| AI acceptable use policy | Defines approved and prohibited AI usage | Know how it reduces shadow AI and unsafe data entry |
| Data classification policy | Labels data by sensitivity | Know how it drives access, encryption, masking, and retention |
| AI risk assessment | Identifies threats, impact, likelihood, and controls | Know how to prioritize mitigation |
| Model card or system card | Documents intended use, limitations, training data notes, evaluation results | Know how documentation supports transparency and review |
| Data lineage record | Tracks source, transformation, and use of data | Know why it matters for audits and incident response |
| Third-party AI assessment | Evaluates vendor, model, API, data usage, and contractual risk | Know what questions to ask before sending data externally |
| Human-in-the-loop procedure | Defines when humans approve, override, or review AI output | Know where automation needs oversight |
| Incident response playbook | Defines detection, triage, containment, recovery, and lessons learned | Know what changes for AI-specific incidents |
Risk decision checklist
- Identify the AI asset: model, dataset, prompt, vector index, endpoint, pipeline, plugin, agent, or output.
- Identify the threat actor: external attacker, insider, malicious user, compromised vendor, careless employee, or automated bot.
- Identify the harm:
- Data exposure
- Unsafe output
- Fraud or abuse
- Model theft
- Service disruption
- Compliance violation
- Reputational damage
- Select controls that match the risk, not just generic controls.
- Decide whether risk should be reduced, transferred, accepted, or avoided.
- Document ownership and accountability for the AI system.
- Confirm monitoring and review frequency.
- Consider whether human review is required before action is taken.
Common governance traps
| Trap | Why it matters |
|---|---|
| Treating AI as only a software problem | AI risk includes data, model behavior, governance, and misuse. |
| Trusting vendor claims without review | Third-party AI tools can introduce data handling, retention, and visibility issues. |
| Failing to document intended use | Models often become risky when reused outside their original context. |
| No owner for model output | Someone must be accountable for decisions, escalations, and exceptions. |
| Logging everything without classification | Prompt and response logs may contain sensitive data. |
Data security, privacy, and AI pipelines
Data lifecycle checklist
| Stage | What to review | Security questions |
|---|---|---|
| Collection | Sources, consent, sensitivity, legality, quality | Is the data appropriate and authorized for this use? |
| Ingestion | Transfer, validation, malware scanning, schema checks | Can untrusted data poison or break the pipeline? |
| Storage | Encryption, access control, segmentation, retention | Who can read, modify, export, or delete it? |
| Preparation | Cleaning, labeling, feature engineering, masking | Could sensitive values leak into features or labels? |
| Training or fine-tuning | Dataset selection, isolation, reproducibility | Can training data be traced, reviewed, and protected? |
| Retrieval | Embeddings, vector stores, indexes, document chunks | Can users retrieve data they should not see? |
| Inference | Input handling, output filtering, access decisions | Does the system reveal sensitive information? |
| Logging | Prompt logs, response logs, telemetry, audit trails | Are logs protected and minimized? |
| Archival or deletion | Retention, legal hold, secure deletion | Can data be removed when required? |
Data protection controls
- Data classification
- Data minimization
- Access control and least privilege
- Encryption in transit
- Encryption at rest
- Key management
- Tokenization
- Masking or redaction
- Anonymization or pseudonymization
- Data loss prevention
- Retention controls
- Secure deletion
- Audit logging
- Data lineage tracking
Can you do this?
| Scenario | Best readiness response |
|---|---|
| Employees paste customer records into a public AI tool. | Identify data exposure, policy violation, possible privacy issue, and need for approved tooling, DLP, training, and access controls. |
| A RAG system returns HR documents to non-HR users. | Check document-level authorization, index construction, metadata filters, identity propagation, and retrieval controls. |
| A data scientist wants production data for testing. | Recommend masking, synthetic data, controlled access, approved environments, and data minimization. |
| A model was trained on data that should have been deleted. | Consider lineage, retraining, legal review, incident handling, and retention process gaps. |
Adversarial AI threat checklist
Threats to recognize
| Threat | What it targets | What it looks like | Common mitigations |
|---|---|---|---|
| Prompt injection | LLM instructions and context | User input tells model to ignore instructions or reveal hidden data | Input handling, prompt isolation, tool permissions, output validation, least privilege |
| Jailbreaking | Safety and policy controls | Attempts to bypass guardrails through roleplay, encoding, or instruction tricks | Guardrails, policy enforcement, model evaluation, monitoring, defense in depth |
| Data poisoning | Training or fine-tuning data | Malicious samples degrade or manipulate model behavior | Data validation, source trust, anomaly detection, lineage, review workflows |
| Evasion attack | Model inference | Input is modified to avoid detection or change classification | Robust testing, adversarial evaluation, monitoring, layered controls |
| Model extraction | Model confidentiality | Repeated queries used to approximate or steal model behavior | Rate limiting, monitoring, watermarking where applicable, access control |
| Model inversion | Training data privacy | Attacker infers sensitive information from model outputs | Output limits, privacy-preserving training, access control, monitoring |
| Membership inference | Dataset privacy | Attacker determines whether a record was in training data | Regularization, privacy controls, output restriction, evaluation |
| Training data leakage | Data confidentiality | Model reveals memorized secrets or sensitive text | Data cleansing, secret scanning, output filtering, retraining if needed |
| Supply chain compromise | Dependencies and models | Malicious library, model artifact, or container image | Signed artifacts, SBOM, scanning, trusted registries, CI/CD controls |
| Tool abuse | AI agents and plugins | Model calls tools in unsafe ways | Tool permission scoping, approval gates, sandboxing, action validation |
Attack-to-control matching
| If you see… | Think first about… |
|---|---|
| “Ignore previous instructions” | Prompt injection |
| Model returns hidden system instructions | Prompt leakage or prompt injection weakness |
| Model accesses documents outside user permissions | Broken authorization in RAG or retrieval layer |
| Repeated high-volume queries against model endpoint | Extraction, scraping, denial of service, or abuse |
| Performance suddenly changes after new training data | Poisoning, drift, pipeline issue, or data quality problem |
| Agent sends email, transfers data, or modifies records without approval | Excessive tool permissions and missing human approval |
| Sensitive data appears in completions | Data leakage, memorization, poor filtering, or unsafe retrieval |
Generative AI, LLM, RAG, and agent security
LLM application components
| Component | Security focus |
|---|---|
| System prompt | Protect from disclosure, avoid relying on it as the only control |
| User prompt | Treat as untrusted input |
| Context window | Limit sensitive content and prevent cross-user contamination |
| Retrieval layer | Enforce authorization before retrieval and before response generation |
| Vector database | Protect embeddings, metadata, source documents, and indexes |
| Tools and plugins | Restrict actions, permissions, network access, and data access |
| Output handler | Validate, filter, encode, and log safely |
| Feedback loop | Prevent malicious feedback from poisoning future behavior |
| Monitoring | Capture abuse patterns, unsafe outputs, latency, cost anomalies, and policy violations |
RAG readiness checklist
- Explain how retrieval-augmented generation differs from training or fine-tuning.
- Identify where sensitive data can leak:
- Source documents
- Chunks
- Embeddings
- Metadata
- Retrieved context
- Prompt logs
- Final responses
- Enforce authorization at retrieval time.
- Preserve source document permissions in the index.
- Validate that users cannot retrieve documents by prompt manipulation.
- Review chunking strategy for overexposure of unrelated content.
- Protect vector indexes with access control and encryption.
- Monitor retrieval anomalies.
- Test for cross-tenant and cross-user leakage.
- Avoid assuming embeddings are automatically non-sensitive.
Agent security checklist
- List every tool the agent can call.
- Assign least privilege to each tool.
- Separate read-only tools from write/action tools.
- Require approval for high-impact actions.
- Validate tool inputs and outputs.
- Limit network destinations.
- Use sandboxing where possible.
- Log tool calls and decisions.
- Prevent prompt content from directly becoming privileged commands.
- Create rollback or recovery procedures for agent-initiated changes.
Decision path: securing an AI feature
flowchart TD
A[New AI feature request] --> B{Does it process sensitive data?}
B -- Yes --> C[Classify data and apply privacy controls]
B -- No --> D[Define intended use and misuse cases]
C --> D
D --> E{Can it take actions or call tools?}
E -- Yes --> F[Apply least privilege, approval gates, and tool logging]
E -- No --> G[Secure prompts, retrieval, and outputs]
F --> H[Test for abuse, leakage, and unsafe behavior]
G --> H
H --> I{Risk acceptable?}
I -- No --> J[Add controls or redesign]
I -- Yes --> K[Deploy with monitoring and review]
Secure AI architecture and design
Architecture control checklist
| Layer | Controls to review |
|---|---|
| Identity | SSO, MFA, least privilege, service accounts, workload identity, separation of duties |
| Network | Segmentation, private connectivity where appropriate, firewall rules, egress control, API gateways |
| Compute | Hardened images, container isolation, patching, runtime monitoring, resource limits |
| Storage | Encryption, access policies, backup, retention, versioning, object permissions |
| Model endpoint | Authentication, authorization, throttling, abuse detection, input/output controls |
| Secrets | Secret vaults, rotation, no secrets in prompts, code, images, or logs |
| CI/CD | Approved repositories, code review, artifact signing, scanning, promotion gates |
| Observability | Logs, metrics, traces, model behavior telemetry, alerting, audit trails |
| Resilience | Rollback, fail-safe behavior, fallback paths, degraded-mode planning |
| Governance | Approval records, risk assessments, documentation, periodic review |
Secure design questions
- What data does the AI system need, and what data should it never see?
- Who can submit prompts, files, queries, or API requests?
- Who can view outputs?
- What identities are used by the application, model endpoint, retrieval service, and tools?
- Are permissions based on the user, the service, or both?
- Can the AI system call external services?
- Can the AI system perform write actions?
- What happens if the model produces unsafe, false, or unauthorized output?
- What is logged, and who can access those logs?
- How is model or prompt configuration changed and approved?
- How is rollback performed?
Application security and API controls for AI systems
AppSec controls that still matter
| Control | AI-specific exam cue |
|---|---|
| Authentication | Confirm user, service, and workload identity before AI access |
| Authorization | Enforce permissions before data retrieval and tool use |
| Input validation | Treat prompts, documents, URLs, files, and metadata as untrusted |
| Output validation | Check generated text, code, commands, links, and structured output |
| Rate limiting | Reduce abuse, scraping, model extraction, and cost spikes |
| API gateway | Centralize auth, throttling, logging, and routing |
| Secure session management | Prevent cross-user context leakage |
| Error handling | Avoid exposing prompts, stack traces, model details, or secrets |
| Secure coding | Prevent injection, deserialization, path traversal, SSRF, and dependency risks |
| Content safety controls | Detect toxic, unsafe, confidential, or policy-violating output |
AI API scenario checks
| Scenario | What to check |
|---|---|
| Public chatbot endpoint receives high-volume requests | Rate limiting, bot controls, abuse monitoring, cost alerts, endpoint authentication if required |
| LLM summarizes uploaded files | Malware scanning, file type validation, size limits, data classification, retention policy |
| Model generates code | Secure code review, dependency scanning, sandboxed execution, warning labels |
| AI service returns structured JSON used by an application | Schema validation, safe parsing, allowlists, error handling |
| User prompt includes a URL | SSRF protections, URL validation, network egress controls, safe fetch service |
MLOps, LLMOps, and secure lifecycle readiness
Lifecycle checklist
| Phase | Readiness checks |
|---|---|
| Design | Threat model, data classification, intended use, abuse cases, control requirements |
| Data preparation | Source validation, lineage, cleaning, labeling quality, secret scanning |
| Development | Secure notebooks, repository controls, dependency review, peer review |
| Training/fine-tuning | Isolated environment, approved data, tracked configuration, reproducible runs |
| Evaluation | Security tests, quality metrics, bias checks, robustness tests, regression testing |
| Packaging | Signed artifacts, model registry, versioning, metadata, SBOM where applicable |
| Deployment | Approval gates, environment separation, endpoint hardening, rollback plan |
| Monitoring | Drift, abuse, leakage, latency, failures, unusual usage, cost anomalies |
| Change management | Approved updates, documented changes, comparison to baseline |
| Retirement | Disable endpoints, revoke keys, archive or delete data, preserve required records |
Model registry and artifact checks
- Can you identify the approved model version?
- Can you trace the model to its training data and configuration?
- Are models stored in a trusted registry?
- Are artifacts protected from unauthorized modification?
- Are promotion steps documented?
- Are rollback options available?
- Are deprecated models disabled or restricted?
- Are third-party models assessed before use?
Supply chain weak points
| Weak point | Risk | Control |
|---|---|---|
| Open-source model | Hidden behavior, license issue, unsafe training data | Vet source, scan artifacts, test behavior, document approval |
| Python/package dependency | Malicious or vulnerable library | Dependency scanning, pinned versions, trusted repositories |
| Container image | Vulnerable runtime or embedded secrets | Image scanning, minimal base images, secret scanning |
| Notebook environment | Untracked code, exposed credentials | Access control, versioning, secrets management |
| CI/CD pipeline | Unauthorized model or code promotion | Branch protections, approval gates, signed artifacts |
| Dataset source | Poisoned or unauthorized data | Source validation, lineage, sampling, anomaly detection |
Security monitoring, detection, and incident response
What to monitor in AI systems
| Signal | Why it matters |
|---|---|
| Authentication failures | Credential attacks or unauthorized access attempts |
| Unusual prompt patterns | Prompt injection, jailbreak attempts, probing |
| High query volume | Abuse, extraction, denial of service, cost attack |
| Unusual retrieval patterns | Data scraping or authorization bypass |
| Sensitive output events | Data leakage or policy failure |
| Tool invocation logs | Agent misuse or excessive permissions |
| Model performance drift | Data changes, degradation, or attack |
| Error rates and latency | Availability and reliability issues |
| Cost anomalies | Abuse, runaway agents, inefficient prompts |
| Configuration changes | Unauthorized prompt, model, or policy changes |
AI incident response checklist
- Classify the incident type:
- Data exposure
- Prompt injection
- Unsafe output
- Unauthorized tool action
- Model or data poisoning
- Model theft
- Availability or cost attack
- Preserve relevant evidence:
- Prompts
- Responses
- Retrieval context
- Tool calls
- Model version
- User identity
- API logs
- Dataset or pipeline changes
- Contain the issue:
- Disable affected endpoint
- Revoke keys or tokens
- Roll back model or prompt version
- Disable tool access
- Block abusive accounts or sources
- Assess data impact.
- Determine whether outputs influenced business decisions.
- Notify appropriate internal stakeholders.
- Remediate root cause.
- Add detection or test cases to prevent recurrence.
- Document lessons learned.
Triage decision cues
| Symptom | Likely investigation path |
|---|---|
| Model suddenly recommends unsafe actions | Check prompt/config changes, model version, retrieval data, safety filters |
| Users see another department’s documents | Check authorization propagation, vector metadata, index permissions |
| Endpoint costs spike overnight | Check query volume, agent loops, abuse, rate limits, token usage |
| Model classification accuracy drops | Check drift, new data, poisoning, threshold changes, pipeline defects |
| Sensitive information appears in logs | Check logging policy, redaction, retention, access permissions |
AI testing, validation, and evaluation
Testing types to know
| Test type | Purpose |
|---|---|
| Functional testing | Confirms the AI feature works as intended |
| Security testing | Finds exploitable weaknesses in inputs, outputs, APIs, permissions, and infrastructure |
| Adversarial testing | Tests evasion, prompt injection, poisoning, and misuse |
| Red teaming | Simulates realistic attacker or malicious user behavior |
| Regression testing | Confirms new changes do not reintroduce prior failures |
| Bias/fairness testing | Identifies disparate or inappropriate outcomes |
| Privacy testing | Detects leakage, memorization, or exposure of sensitive data |
| Robustness testing | Measures behavior under malformed, unexpected, or hostile input |
| Performance testing | Reviews latency, availability, scalability, and resource use |
Metrics and confusion matrix readiness
For classification scenarios, be comfortable with true positives, false positives, true negatives, and false negatives.
\[ \text{Accuracy} = \frac{TP + TN}{TP + TN + FP + FN} \]\[ \text{Precision} = \frac{TP}{TP + FP} \]\[ \text{Recall} = \frac{TP}{TP + FN} \]\[ \text{F1 Score} = 2 \times \frac{\text{Precision} \times \text{Recall}}{\text{Precision} + \text{Recall}} \]Metric decision checks
| If the scenario emphasizes… | Think about… |
|---|---|
| Avoiding missed malicious events | Recall / reducing false negatives |
| Avoiding unnecessary alerts or blocks | Precision / reducing false positives |
| Overall correct predictions in balanced data | Accuracy |
| Imbalanced datasets | Precision, recall, F1, and confusion matrix over simple accuracy |
| Threshold tuning | Tradeoff between false positives and false negatives |
| Production performance change | Drift, data quality, pipeline change, or adversarial behavior |
Privacy, compliance, and ethical AI readiness
Exam blueprint
- Explain why privacy is not the same as security.
- Identify sensitive, regulated, confidential, and proprietary data.
- Apply data minimization to AI use cases.
- Explain consent and purpose limitation at a high level.
- Recognize when explainability or transparency is needed.
- Identify bias and fairness concerns.
- Recognize accountability gaps in automated decision-making.
- Know why audit trails matter for AI decisions.
- Understand human review and escalation for high-impact outputs.
- Identify third-party data handling concerns.
- Recognize retention and deletion issues in training data, logs, and indexes.
Ethics and governance scenario cues
| Scenario wording | Likely concern |
|---|---|
| “The model cannot explain why it denied the request.” | Explainability, accountability, auditability |
| “The training data underrepresents a population.” | Bias, fairness, model performance gap |
| “Users are unaware their data is used for training.” | Consent, transparency, purpose limitation |
| “The AI system makes final decisions without review.” | Human oversight and accountability |
| “Logs contain prompts with personal information.” | Privacy, minimization, log protection |
Cloud, infrastructure, and operations checks
Infrastructure topics to review
| Topic | What to be ready for |
|---|---|
| IAM | Least privilege, role separation, service identities, key rotation, access review |
| Network security | Segmentation, ingress/egress control, private endpoints where appropriate, firewalling |
| Storage security | Encryption, bucket/container permissions, lifecycle policies, backup |
| Compute security | Patch management, hardened images, container security, workload isolation |
| Secrets management | Vaulting, rotation, no hardcoded credentials, no secrets in prompts/logs |
| Key management | Ownership, access control, rotation, separation from data access |
| Logging and monitoring | Centralized logs, alerting, retention, access control, tamper resistance |
| Cost and abuse controls | Rate limits, quotas, alerts, anomaly detection, runaway job prevention |
| Resilience | Backups, rollback, failover, degraded mode, dependency planning |
| Environment separation | Development, test, staging, production isolation |
Operational readiness questions
- Can a compromised model endpoint access sensitive storage?
- Can a compromised notebook access production data?
- Are training jobs isolated from production workloads?
- Are service accounts overprivileged?
- Are model artifacts protected from tampering?
- Are prompt templates and configuration files change-controlled?
- Can logs be modified by the same identities being monitored?
- Are emergency shutdown and rollback procedures defined?
Scenario and decision-point practice
Choose the best control
| Scenario | Best first control direction |
|---|---|
| A chatbot must answer questions from internal documents but only according to user permissions. | Identity-aware retrieval with document-level authorization and metadata filtering |
| A model endpoint is being queried thousands of times by one client. | Rate limiting, abuse detection, authentication review, and monitoring |
| A team wants the AI agent to approve refunds automatically. | Human approval gates, transaction limits, audit logs, and least-privilege tool access |
| Generated code is being copied directly into production. | Secure code review, testing, dependency scanning, and developer training |
| An LLM plugin can access internal ticketing and email. | Scope plugin permissions, validate actions, require approval for sensitive operations |
| Model performance drops after a dataset update. | Investigate data quality, drift, poisoning, and pipeline changes |
| Customer data appears in generated responses. | Contain, investigate retrieval/training/log sources, assess exposure, remediate leakage |
| A public model is downloaded for internal use. | Assess provenance, license, security, behavior, and artifact integrity before approval |
Identify the likely weakness
| Clue | Likely weakness |
|---|---|
| “The model was connected directly to production admin APIs.” | Excessive privilege and missing approval gates |
| “The prompt says not to reveal secrets.” | Overreliance on prompt instructions as a security boundary |
| “Everyone can query the same vector index.” | Broken access control in retrieval |
| “Training data was copied from many locations with no records.” | Missing data lineage and governance |
| “The model was updated outside the deployment pipeline.” | Change management and supply chain weakness |
| “Developers use personal AI accounts for debugging.” | Shadow AI and data exposure risk |
| “The system logs full prompts indefinitely.” | Privacy, retention, and log access risk |
Common weak areas and traps for CY0-001 preparation
| Weak area | How to fix it |
|---|---|
| Memorizing AI terms without security context | For every term, ask: what can go wrong, and what control reduces the risk? |
| Treating LLM prompts as trusted instructions | Remember that user-controlled text is input, not policy enforcement. |
| Forgetting retrieval authorization | RAG security often fails because indexed data is not filtered by user permissions. |
| Confusing fine-tuning with RAG | Fine-tuning changes model behavior; RAG supplies external context at inference time. |
| Ignoring logs as sensitive data | Prompts, responses, and retrieval context can contain confidential information. |
| Overlooking agent tool permissions | The model may be probabilistic, but tool actions can be real and high impact. |
| Choosing only one control | AI systems usually need layered controls across data, model, app, and infrastructure. |
| Assuming vendor AI tools remove customer responsibility | You still need data governance, access control, monitoring, and usage policy. |
| Using accuracy for every evaluation question | Consider precision, recall, false positives, false negatives, and class imbalance. |
| Forgetting incident evidence | Model version, prompts, retrieved context, and tool calls may be critical evidence. |
Final-week checklist
Seven-day review plan
| Timeframe | Focus |
|---|---|
| 7 days out | Revisit AI fundamentals, lifecycle, governance, and threat vocabulary |
| 6 days out | Drill adversarial AI attacks and match each to mitigations |
| 5 days out | Review RAG, vector store, prompt injection, and agent scenarios |
| 4 days out | Practice data privacy, lineage, logging, and third-party AI risk questions |
| 3 days out | Review MLOps/LLMOps, model registry, CI/CD, and supply chain controls |
| 2 days out | Practice mixed scenarios and explain why wrong answers are weaker |
| 1 day out | Light review: formulas, terms, traps, and decision cues; avoid cramming new material |
Final readiness checks
- I can explain the AI lifecycle from data collection to retirement.
- I can identify AI-specific threats from short scenario clues.
- I can match prompt injection, poisoning, evasion, extraction, inversion, and leakage to controls.
- I can secure a RAG system using identity-aware retrieval and data controls.
- I can explain why prompts are not reliable security boundaries.
- I can identify sensitive data exposure in prompts, logs, embeddings, and outputs.
- I can apply least privilege to AI tools, plugins, agents, and service accounts.
- I can choose monitoring signals for AI misuse, drift, leakage, and abuse.
- I can describe AI incident response evidence and containment steps.
- I can apply precision, recall, false positives, and false negatives in simple scenarios.
- I can distinguish governance, ethics, privacy, and technical security issues.
- I can explain tradeoffs instead of selecting controls by keyword alone.
Practical next step
After you complete this checklist, move into timed scenario practice for CompTIA SecAI+ (CY0-001). Focus especially on questions that require choosing the best control for an AI system, identifying the likely attack from limited evidence, and explaining why a technically correct control may not be the best first action.