CY0-001 — CompTIA SecAI+ Quick Review
Quick Review for CompTIA SecAI+ (CY0-001): high-yield AI security concepts, controls, threats, metrics, governance, and practice focus areas.
This Quick Review is an IT Mastery study companion for candidates preparing for CompTIA SecAI+ (CY0-001). Use it to refresh the most testable ideas before moving into topic drills, mock exams, and detailed explanations in the IT Mastery question bank.
The main exam-prep mindset: secure the full AI system, not just the model. CY0-001-style questions may describe data pipelines, model behavior, cloud services, prompts, APIs, users, governance, incident response, monitoring, or business risk. Read each scenario for the asset at risk, the threat actor’s path, and the control that most directly reduces the stated risk.
Quick Exam Mindset
What to Prioritize
| Area | What to know quickly | Common exam decision point |
|---|---|---|
| AI/ML fundamentals | Training, inference, supervised vs. unsupervised learning, LLMs, embeddings, RAG, agents | Identify which AI component is being attacked or misused |
| Data security | Collection, labeling, storage, lineage, privacy, integrity, retention | Choose controls for sensitive data exposure or poisoned data |
| Model security | Evasion, poisoning, extraction, inversion, prompt attacks, jailbreaks | Match the attack type to the most effective mitigation |
| Secure architecture | IAM, network controls, API security, secrets, sandboxing, logging | Decide where to enforce least privilege and isolation |
| Governance and risk | Policies, risk assessments, human oversight, auditability, accountability | Distinguish technical controls from governance controls |
| Testing and validation | Red teaming, adversarial testing, model evaluation, drift monitoring | Know what to test before and after deployment |
| Incident response | Detection, containment, rollback, evidence, communications, lessons learned | Pick the next best step in an AI security incident |
Fast Decision Rules
| If the scenario says… | Think first about… |
|---|---|
| “The model behaves differently after new training data was added” | Data poisoning, data quality, drift, retraining controls |
| “The chatbot reveals confidential information” | Prompt injection, data leakage, access control, RAG permissions |
| “An attacker sends crafted inputs to misclassify results” | Evasion/adversarial examples |
| “A user extracts model behavior through many queries” | Model extraction, rate limiting, monitoring, output controls |
| “The model reveals whether a person was in the training set” | Membership inference and privacy risk |
| “The model reconstructs sensitive attributes” | Model inversion and data minimization |
| “An AI agent performs unauthorized actions” | Tool permissions, agent sandboxing, approval gates, least privilege |
| “The issue appeared only in production” | Monitoring, drift, logging, deployment validation |
| “The organization cannot explain how decisions are made” | Explainability, documentation, audit trails, governance |
| “The model is accurate but unfair across groups” | Bias testing, fairness metrics, representative data, human review |
Core AI and Security Concepts
AI System Components
For exam review, break an AI system into components:
| Component | Security concern |
|---|---|
| Data source | Sensitive data, provenance, consent, quality, tampering |
| Data pipeline | ETL errors, insecure storage, weak access control, untracked transformations |
| Feature engineering / embeddings | Leakage, reidentification, unintended sensitive features |
| Model training | Poisoned data, insecure training environment, untrusted code or dependencies |
| Model registry | Unauthorized model replacement, weak versioning, missing approvals |
| Inference endpoint | Abuse, extraction, evasion, prompt injection, denial of service |
| Application layer | Broken authorization, insecure APIs, poor session handling |
| RAG/vector store | Retrieval of unauthorized documents, stale data, embedding leakage |
| Agent tools | Overprivileged actions, unsafe plugins, command execution risk |
| Monitoring/logging | Sensitive logs, insufficient telemetry, missed drift or abuse |
A strong answer usually protects the specific weak point described in the question. For example, encrypting a model artifact may help confidentiality, but it does not stop a prompt injection attack against a deployed chatbot.
Common AI Terms to Keep Straight
| Term | Quick meaning | Trap |
|---|---|---|
| Training | Model learns patterns from data | Training data quality directly affects model behavior |
| Inference | Model generates predictions or outputs | Runtime controls matter even if training was secure |
| Fine-tuning | Additional training for a specific task/domain | Can introduce new leakage, bias, or unsafe behavior |
| Embedding | Numeric representation of text/data | Embeddings may still reveal sensitive information |
| RAG | Retrieval-augmented generation using external knowledge | Retrieval permissions must match user permissions |
| Prompt | Input/instructions to an AI system | Prompts are not trusted security boundaries |
| Guardrail | Control that constrains model behavior | Guardrails reduce risk; they do not guarantee safety |
| Hallucination | Plausible but incorrect output | Different from unauthorized disclosure |
| Drift | Production data/behavior changes over time | Requires monitoring and possible retraining |
| Model card | Documentation about model use, limits, and performance | Documentation supports governance, not runtime enforcement |
AI Threats and Attack Patterns
High-Yield Threat Table
| Threat | What happens | Best-fit mitigations |
|---|---|---|
| Data poisoning | Attacker manipulates training or fine-tuning data | Data provenance, validation, outlier detection, approval workflow, clean rollback |
| Evasion attack | Crafted input causes wrong output at inference | Adversarial testing, input validation, robust model design, monitoring |
| Prompt injection | Malicious instructions override intended behavior | Prompt hardening, context separation, output validation, least-privilege tools |
| Jailbreak | User bypasses safety restrictions | Red teaming, safety filters, abuse monitoring, model/prompt updates |
| Model extraction | Attacker approximates or steals model behavior via queries | Rate limits, anomaly detection, output throttling, authentication |
| Model inversion | Attacker infers sensitive training data attributes | Data minimization, privacy controls, limiting outputs, aggregation |
| Membership inference | Attacker determines if a record was in training data | Privacy-preserving training, regularization, minimizing memorization |
| Sensitive data leakage | Model or logs expose secrets/PII | DLP, redaction, access control, retention limits, secret scanning |
| Supply chain compromise | Malicious model, package, dataset, or plugin is introduced | Provenance checks, signed artifacts, dependency scanning, approvals |
| Agent tool abuse | AI agent calls tools or APIs in harmful ways | Sandboxing, scoped tokens, allowlists, human approval, transaction limits |
| RAG authorization failure | User retrieves content they should not access | Per-user retrieval authorization, document ACLs, filtering |
| Denial of service | Excessive AI queries exhaust compute or costs | Rate limiting, quotas, autoscaling controls, abuse detection |
Attack Identification Shortcuts
| Clue in question | Likely answer |
|---|---|
| Manipulated labels or training samples | Data poisoning |
| Subtle image/text changes cause misclassification | Evasion/adversarial examples |
| “Ignore previous instructions” or hidden instructions in a document | Prompt injection |
| Excessive API calls to learn model outputs | Model extraction |
| Inferring original private data from outputs | Model inversion |
| Determining whether a person’s data was included | Membership inference |
| Model performance degrades as real-world inputs change | Data drift or concept drift |
| AI retrieves documents outside user’s role | RAG access control failure |
| AI tool performs action without approval | Agent authorization failure |
Secure AI Lifecycle Review
Lifecycle Controls
| Phase | Key controls | Exam focus |
|---|---|---|
| Plan | Risk assessment, acceptable use, threat modeling, data classification | Define the risk before selecting tools |
| Collect data | Provenance, consent/authorization, minimization, labeling quality | Bad data creates bad and risky models |
| Prepare data | Sanitization, deidentification, validation, lineage | Track transformations and prevent leakage |
| Train/fine-tune | Isolated environments, approved datasets, secure dependencies | Training pipeline is part of the attack surface |
| Validate | Accuracy, bias, robustness, security tests, red teaming | Security testing is not the same as accuracy testing |
| Deploy | IAM, secrets management, API controls, logging, rollback plan | Production controls must enforce policy |
| Operate | Monitoring, drift detection, abuse detection, cost controls | AI risk changes after deployment |
| Respond | Containment, rollback, evidence, root cause, lessons learned | Treat AI incidents like security incidents |
| Retire | Data/model disposal, access removal, documentation | Decommissioning reduces residual risk |
Secure-by-Design Questions
When a scenario asks for the “best” design control, prefer preventive architecture over after-the-fact detection when prevention is feasible.
| Goal | Strong design choice |
|---|---|
| Prevent unauthorized document retrieval | Enforce document-level authorization before retrieval |
| Prevent unsafe agent actions | Use scoped permissions, sandboxing, and human approval for high-risk actions |
| Prevent training data tampering | Use controlled ingestion, provenance tracking, and approval gates |
| Prevent secret exposure | Keep secrets out of prompts, training data, logs, and model responses |
| Prevent model artifact tampering | Use signed artifacts, model registry controls, and deployment approvals |
| Prevent cross-tenant leakage | Enforce tenant isolation across data, vector stores, logs, and inference contexts |
Data Security and Privacy
Data Risk Checklist
For CY0-001 review, ask these questions whenever a scenario involves data:
- What type of data is involved? Sensitive, confidential, personal, regulated, proprietary, or public?
- Where does the data flow? Training set, prompt, vector database, logs, model output, third-party service?
- Who can access it? Users, developers, vendors, admins, AI agents, downstream applications?
- How is it protected? Encryption, IAM, DLP, masking, tokenization, retention controls?
- Can it be reconstructed or inferred? Embeddings, outputs, model behavior, logs, analytics?
- Is it necessary? Data minimization is often a better answer than collecting more data.
Privacy and Confidentiality Controls
| Control | Best use |
|---|---|
| Data minimization | Reduce what is collected, stored, trained on, or sent to a model |
| Deidentification/masking | Lower direct exposure of sensitive fields |
| Tokenization | Replace sensitive values with controlled substitutes |
| Encryption | Protect data at rest and in transit |
| Access control | Restrict who and what can use data |
| DLP | Detect or block sensitive data in prompts, outputs, or storage |
| Retention limits | Reduce exposure window |
| Audit logging | Support investigation and accountability |
| Privacy review | Confirm appropriate use and risk treatment before deployment |
Common trap: anonymization is not automatically permanent protection. AI systems can sometimes infer, correlate, or reconstruct sensitive information. If the question emphasizes reidentification risk, choose stronger privacy controls, minimization, aggregation, or governance review.
LLM, Prompt, RAG, and Agent Security
Prompt and LLM Controls
| Risk | Practical control |
|---|---|
| Prompt injection | Separate system instructions from user content; validate inputs; treat retrieved text as untrusted |
| Jailbreak attempts | Use safety filters, red-team prompts, behavior monitoring |
| Sensitive output | Apply DLP/redaction and restrict access to source data |
| Hallucinated answers | Use grounding, citations, retrieval constraints, human review for high-impact use |
| Unsafe code generation | Sandbox execution; require review; scan outputs |
| Overreliance | Add human-in-the-loop controls for high-risk decisions |
| Prompt leakage | Avoid embedding secrets or policies that should not be disclosed |
RAG Security
RAG systems often fail when they retrieve the right-looking document for the wrong user. The key is to enforce permissions before and during retrieval, not only after generation.
| RAG layer | Control |
|---|---|
| Document ingestion | Classify content, preserve ACLs, verify source integrity |
| Embedding generation | Protect embedding stores; avoid embedding unnecessary sensitive data |
| Retrieval | Apply user-specific authorization and filtering |
| Prompt assembly | Keep retrieved content separated from trusted instructions |
| Generation | Constrain output, cite sources when appropriate |
| Logging | Avoid storing sensitive prompts, retrieved passages, or outputs unnecessarily |
Agentic AI Security
AI agents create additional risk because they can take actions, not just answer questions.
| Agent capability | Security risk | Control |
|---|---|---|
| Email or messaging | Data leakage, phishing, unauthorized sending | Approval workflow, restricted recipients, logging |
| File access | Exposure or modification of sensitive files | Least privilege, read/write separation, ACL enforcement |
| Code execution | Command injection, malware, data exfiltration | Sandbox, network restrictions, review |
| API calls | Unauthorized transactions | Scoped tokens, allowlists, transaction limits |
| Web browsing | Prompt injection from untrusted pages | Content isolation, tool restrictions, validation |
| Database access | Excessive queries, sensitive extraction | Query controls, row/column permissions, monitoring |
High-yield rule: Do not give an AI agent broad credentials just because the user is authenticated. Scope the agent’s permissions to the task, data, and risk level.
Security Architecture Controls
Control Selection Table
| Scenario need | Prefer this control |
|---|---|
| Verify model artifact integrity | Signing, checksums, trusted model registry |
| Limit excessive queries | Rate limiting, quotas, anomaly detection |
| Restrict administrative actions | RBAC/ABAC, MFA, just-in-time access |
| Protect API endpoint | Authentication, authorization, input validation, throttling |
| Protect secrets | Secrets manager, rotation, no secrets in prompts/logs |
| Isolate risky AI execution | Sandbox, container isolation, network egress controls |
| Detect abuse | Central logging, SIEM integration, behavioral analytics |
| Reduce blast radius | Segmentation, least privilege, tenant isolation |
| Support rollback | Versioned models, deployment pipeline controls |
| Prove accountability | Audit logs, approvals, documentation |
Least Privilege in AI Systems
Apply least privilege to:
- Human users
- Developers and data scientists
- Service accounts
- Training jobs
- Inference services
- AI agents and tools
- Vector databases
- Model registries
- CI/CD pipelines
- Monitoring and logging platforms
A frequent exam trap is focusing only on user permissions while ignoring service accounts, plugins, connectors, or AI tools that can access sensitive systems.
Model Evaluation, Metrics, and Monitoring
Confusion Matrix Terms
| Term | Meaning |
|---|---|
| True positive | Model correctly identifies a positive case |
| True negative | Model correctly identifies a negative case |
| False positive | Model incorrectly flags a negative case as positive |
| False negative | Model misses a positive case |
Key formulas:
\[ \text{Precision} = \frac{\text{True Positives}}{\text{True Positives} + \text{False Positives}} \]\[ \text{Recall} = \frac{\text{True Positives}}{\text{True Positives} + \text{False Negatives}} \]\[ F1 = 2 \times \frac{\text{Precision} \times \text{Recall}}{\text{Precision} + \text{Recall}} \]Metric Decision Rules
| If the priority is… | Focus on… |
|---|---|
| Avoiding false alarms | Precision |
| Avoiding missed detections | Recall |
| Balancing precision and recall | F1 score |
| Understanding threshold tradeoffs | ROC/PR analysis |
| Ensuring predictions match real likelihood | Calibration |
| Detecting changed input patterns | Data drift monitoring |
| Detecting changed target relationships | Concept drift monitoring |
| Detecting unequal outcomes across groups | Fairness/bias metrics |
Example trap: A model can have high overall accuracy while performing poorly for a smaller subgroup. If the scenario emphasizes fairness, equity, or disparate performance, do not choose “increase overall accuracy” as the complete answer.
Monitoring Targets
| Monitor | Why it matters |
|---|---|
| Input distributions | Detect drift, abuse, or unexpected data |
| Output distributions | Detect behavior changes or unsafe responses |
| Error rates | Identify quality and reliability issues |
| User feedback | Catch harmful or incorrect outputs |
| Query patterns | Detect extraction, scraping, or abuse |
| Cost/compute usage | Detect denial of wallet or runaway automation |
| Security events | Correlate AI activity with broader incidents |
| Bias/fairness indicators | Identify unequal production impact |
| Data and model versions | Support root cause analysis |
Governance, Risk, and Compliance Concepts
Governance Artifacts
| Artifact | Purpose |
|---|---|
| AI acceptable use policy | Defines permitted and prohibited use |
| Risk assessment | Identifies likelihood, impact, and treatment options |
| Threat model | Maps attack paths and controls |
| Data inventory | Tracks data sources, sensitivity, and owners |
| Model inventory | Tracks deployed models, versions, owners, and use cases |
| Model card | Documents model purpose, limitations, evaluation, and risks |
| Data sheet | Documents dataset source, collection, quality, and constraints |
| Approval record | Shows review and accountability |
| Audit log | Supports investigation and evidence |
| Incident playbook | Defines response steps for AI-specific events |
Human Oversight
Human review is especially important when AI outputs affect:
- Security enforcement decisions
- Financial or employment outcomes
- Legal, safety, or health-related decisions
- Access to sensitive resources
- Irreversible or high-impact actions
- Public communications or customer commitments
Exam trap: Human-in-the-loop is not just “a person exists somewhere.” The reviewer must have enough information, authority, and time to meaningfully approve, reject, or escalate the AI output.
AI Incident Response
Common AI Incident Types
| Incident | Likely response focus |
|---|---|
| Prompt injection causing data disclosure | Contain app, preserve logs, fix retrieval/authorization, rotate exposed secrets |
| Poisoned training data | Stop affected pipeline, identify source, restore clean data/model, strengthen ingestion controls |
| Model extraction | Limit queries, block abusive accounts, analyze access logs, adjust output/rate controls |
| Unsafe agent action | Disable tool access, revoke tokens, review transactions, add approval gates |
| Model drift causing bad decisions | Roll back or adjust thresholds, validate data, retrain if appropriate |
| Sensitive data in logs | Restrict access, purge where appropriate, update logging/redaction controls |
| Compromised model artifact | Remove artifact, verify registry, redeploy trusted version, review supply chain |
Response Order
A practical sequence:
- Detect and validate the issue.
- Triage impact: data, users, systems, decisions, and business process.
- Contain the model, endpoint, agent, dataset, or integration.
- Preserve evidence: prompts, outputs, logs, versions, access records.
- Eradicate root cause: fix data, prompts, permissions, dependencies, or architecture.
- Recover safely: redeploy known-good version, test controls, monitor closely.
- Improve: update playbooks, tests, monitoring, documentation, and training.
Common trap: In a security incident, immediately retraining the model is not always the best first step. If active data leakage or unauthorized action is happening, containment comes first.
Supply Chain and DevSecOps for AI
AI Supply Chain Risks
| Asset | Risk | Control |
|---|---|---|
| Open-source model | Malicious or unsuitable model | Trusted sources, scanning, evaluation, license review |
| Dataset | Poisoned, biased, unauthorized, low quality | Provenance, validation, documentation |
| Package/library | Vulnerability or malicious dependency | Dependency scanning, pinning, SBOM-style tracking |
| Model artifact | Tampering or unauthorized replacement | Signing, registry access controls |
| Plugin/tool | Excessive permissions | Review, allowlisting, sandboxing |
| CI/CD pipeline | Unauthorized deployment | Protected branches, approvals, secrets management |
| Container image | Vulnerabilities or embedded secrets | Image scanning, minimal images, secret scanning |
Deployment Controls
A secure AI deployment should support:
- Reproducible builds and deployments
- Versioned datasets and model artifacts
- Approval gates for high-risk changes
- Rollback to known-good versions
- Separation of development, testing, and production
- Secure secrets handling
- Logging without unnecessary sensitive data
- Continuous monitoring after release
Common Candidate Mistakes
Technical Mistakes
- Treating the model as the only asset and ignoring data, prompts, APIs, logs, and tools.
- Choosing encryption for every scenario, even when the problem is authorization, poisoning, or unsafe output.
- Assuming a prompt is a security boundary.
- Forgetting that embeddings and logs can contain or reveal sensitive information.
- Confusing hallucination with data leakage.
- Confusing evasion with poisoning: evasion happens at inference; poisoning affects training or fine-tuning.
- Ignoring RAG document permissions.
- Giving AI agents broad access instead of scoped, task-specific permissions.
- Treating high accuracy as proof of security, fairness, or reliability.
- Skipping monitoring because a model passed predeployment tests.
Scenario-Reading Mistakes
- Missing whether the question asks for prevention, detection, response, or governance.
- Selecting the most advanced-sounding control instead of the most direct one.
- Failing to identify the actor: user, insider, external attacker, vendor, model, agent, or service account.
- Ignoring words like “first,” “best,” “most likely,” “most effective,” or “least disruptive.”
- Overlooking operational constraints such as production availability, rollback, or evidence preservation.
Mini Review Tables
Attack vs. Control
| Attack | Primary control theme |
|---|---|
| Data poisoning | Data provenance and validation |
| Prompt injection | Context isolation and tool restriction |
| Jailbreak | Safety testing and abuse monitoring |
| Model extraction | Query controls and anomaly detection |
| Model inversion | Privacy-preserving design and output limitation |
| Membership inference | Reduce memorization and sensitive training exposure |
| RAG leakage | Authorization-aware retrieval |
| Agent misuse | Least privilege and approval gates |
| Artifact tampering | Signing and registry governance |
| Drift | Monitoring and lifecycle management |
Governance vs. Technical Control
| Need | Governance control | Technical control |
|---|---|---|
| Define acceptable AI use | Policy | Enforcement in platforms/tools |
| Track deployed models | Model inventory | Registry and deployment metadata |
| Explain model limitations | Model card | Monitoring and validation tests |
| Approve high-risk use | Review board/workflow | Approval gates in CI/CD |
| Investigate incidents | Playbook | Logs, telemetry, version history |
| Reduce privacy risk | Data handling policy | Masking, DLP, minimization |
Quick Self-Check Before Practice
You are ready for focused CY0-001 practice when you can quickly answer:
- What part of the AI system is being attacked: data, model, prompt, retrieval, API, agent, or pipeline?
- Is the issue happening during training, deployment, inference, or monitoring?
- Is the best answer preventive, detective, corrective, or governance-focused?
- What control most directly addresses the stated risk?
- Could the model output be wrong, biased, unauthorized, unsafe, or sensitive?
- Are permissions enforced for both users and AI components?
- Is the organization preserving evidence and maintaining version history?
- Are monitoring and rollback included for production AI systems?
How to Use This with Question-Bank Practice
After reviewing these notes, move into IT Mastery practice using original practice questions organized by topic. A good sequence is:
- Start with short topic drills on AI threats, data security, and LLM/RAG controls.
- Review every missed question with the detailed explanations, especially the wrong-answer rationales.
- Build mixed sets that combine governance, architecture, incident response, and model evaluation.
- Take timed mock exams only after you can explain why each control fits a scenario.
- Revisit this Quick Review to patch weak areas, then repeat targeted drills.
Practical next step: choose one weak domain from this Quick Review, complete a focused question bank drill on that topic, and read the detailed explanations until you can identify the attack, affected AI component, and best control without guessing.
Continue in IT Mastery
Use this Quick Review as a final concept map, then move into IT Mastery for focused topic drills, mixed practice sets, timed mock exams, and detailed explanations. The practice questions are original IT Mastery practice items; they are not official CompTIA questions, copied live-exam content, or exam dumps.