Section 9 Quiz

--- shuffle_answers: true shuffle_questions: false --- ## An organization runs AI Scanner against a new model and discovers it is susceptible to system prompt extraction through adversarial probing. What happens next in the continuous loop? > Hint: Follow the SCAN phase finding through the next phase of the loop. - [ ] The model is removed from production and replaced with a different model > Removing the model entirely may be overkill. The continuous loop is designed to identify vulnerabilities and deploy targeted protections, not to reject every model with findings. - [x] AI Guard is configured with specific rules to detect and block system prompt extraction patterns in model responses -- the PROTECT phase deploys runtime guardrails based on Scanner's specific findings > Correct! The continuous loop's second phase (PROTECT) deploys runtime guardrails based on Scanner's findings. Since Scanner identified system prompt extraction susceptibility, Guard is configured to detect instruction-like content in model outputs and block responses that contain system prompt fragments. Guard's rules are tuned to the specific model's vulnerabilities, not generic catch-all rules. - [ ] AI Scanner re-scans the model immediately to confirm the finding > Re-scanning to confirm is part of the VALIDATE phase, which comes after the PROTECT phase. The immediate next step after SCAN findings is to deploy protections (PROTECT). - [ ] The finding is documented and addressed in the next quarterly security review > The continuous loop operates continuously, not on a quarterly cycle. Scanner findings trigger immediate protective action through Guard deployment. ## AI Scanner and AI Guard both map to OWASP LLM01: Prompt Injection, but at different stages. What is the key operational difference between how Scanner and Guard address prompt injection? > Hint: Think about when each tool operates -- before deployment versus during operation. - [ ] Scanner uses ML-based detection while Guard uses pattern matching > Both Scanner and Guard can use various detection techniques. The key difference is not the detection method but the timing and operational context. - [ ] Scanner addresses direct injection while Guard addresses indirect injection > Both tools address both types of injection. The distinction is not about injection type but about operational timing. - [x] Scanner tests for injection susceptibility before deployment (proactive assessment), while Guard blocks injection attempts in real time during operation (runtime protection) > Correct! Scanner is a pre-deployment and periodic assessment tool -- it probes the model with known injection techniques to identify vulnerabilities. Guard is a runtime protection tool -- it sits in the live request path and blocks injection attempts as they happen. Scanner answers "Is this model vulnerable?" Guard answers "Is someone attacking right now?" Together, they cover both proactive assessment and real-time defense. - [ ] Scanner is more effective than Guard because it tests the model directly > Scanner and Guard serve complementary purposes. Neither is "more effective" -- they operate at different stages and address different aspects of the prompt injection defense. ## The continuous loop has four phases: Scan, Protect, Validate, and Improve. A security team notices that AI Guard is catching an unusual number of novel injection patterns not present in Scanner's original assessment. Which phase does this trigger, and what happens? > Hint: Think about what it means when Guard catches patterns that Scanner didn't test for. - [ ] SCAN phase -- Scanner needs to re-run its entire assessment > While the finding will eventually feed back to Scanner, the immediate phase triggered by Guard catching novel patterns is about analyzing and updating. - [ ] PROTECT phase -- Guard needs additional rules deployed > Guard is already catching these patterns. The question is about what happens when Guard's blocking data reveals gaps in the overall defense posture. - [x] IMPROVE phase -- Guard's blocked patterns are analyzed and fed back to Scanner's test library, Guard rules are refined to reduce false positives, and the next scan cycle will include these new patterns > Correct! When Guard catches patterns that weren't in Scanner's library, the IMPROVE phase activates. Guard's blocked patterns become new entries in Scanner's testing library. Guard rules are refined based on analysis of what was caught. False positive rates are reviewed. And the updated intelligence feeds back to the SCAN phase -- the next assessment will include these newly discovered attack patterns, closing the loop. - [ ] VALIDATE phase -- the team monitors whether Guard is catching real attacks or false positives > VALIDATE monitors Guard's overall effectiveness. The scenario describes specific novel patterns feeding back into the improvement cycle, which is the IMPROVE phase. ## The Scanner/Guard cross-layer integration table shows how both tools contribute to each Blueprint layer. For Layer 5 (Secure Access to AI Services), what is AI Guard's specific contribution? > Hint: Think about where Layer 5's AI Gateway operates and what runtime protection means in that context. - [ ] Guard assesses Layer 5's configuration for misconfigurations > Configuration assessment is AI-SPM's role (Layer 3). Guard provides runtime protection, not configuration assessment. - [x] Guard provides the runtime filtering that Layer 5's AI Gateway depends on for prompt/response inspection -- it is the enforcement engine within the access layer > Correct! The cross-layer table identifies Guard's Layer 5 contribution as providing "the runtime filtering that Layer 5's AI Gateway depends on for prompt/response inspection." Guard is the operational engine within the AI Gateway architecture -- it performs the actual prompt inspection, injection blocking, and response filtering that the Gateway orchestrates. Without Guard, the Gateway would route traffic but couldn't inspect or filter it. - [ ] Guard monitors user access patterns to detect unauthorized AI service usage > User access monitoring is a Layer 4 (Users) function. Guard operates on the content of prompts and responses, not on user access patterns. - [ ] Guard blocks network-level exploits targeting AI service endpoints > Network-level exploit blocking is a Layer 6 (Zero-Day) function through IDS/IPS. Guard operates at the application/API level, filtering prompt and response content. ## An organization is choosing between Trend-hosted and self-hosted deployment for AI Scanner and AI Guard. They handle classified government data in an air-gapped environment. Which deployment option is required, and why? > Hint: Consider what "air-gapped" means for data flow. - [ ] Trend-hosted -- the cloud infrastructure provides better scanning capabilities > In an air-gapped environment, data cannot leave the network. Trend-hosted deployment requires sending model endpoints or traffic to Trend's cloud, which is impossible in an air-gapped network. - [x] Self-hosted -- Scanner and Guard must run within the organization's own infrastructure because model data and AI traffic cannot leave the air-gapped network > Correct! Air-gapped environments have no connection to external networks by design. Self-hosted deployment runs Scanner and Guard entirely within the organization's infrastructure, ensuring that model artifacts (for Scanner assessment) and AI traffic (for Guard filtering) never leave the secure network. This is explicitly why the section identifies self-hosted as "required for organizations with strict data residency or air-gapped environments." - [ ] Either option works because both encrypt data in transit > Encryption doesn't solve the fundamental constraint of an air-gapped network. No data leaves the network regardless of encryption. Self-hosted is the only viable option. - [ ] A hybrid approach -- Scanner cloud-hosted for pre-deployment, Guard self-hosted for runtime > In an air-gapped environment, even pre-deployment assessment data cannot leave the network. Both Scanner and Guard must be self-hosted. ## The GitHub Copilot CVE-2025-53773 breach narrative describes how hidden instructions in code repositories caused Copilot to generate malicious code. How does the continuous loop's VALIDATE phase contribute to catching this type of evolving attack? > Hint: Think about what the VALIDATE phase monitors and what changes over time in code repositories. - [ ] VALIDATE re-scans the model monthly to catch new injection patterns > Periodic re-scanning is part of VALIDATE, but the more relevant contribution for this scenario is ongoing monitoring of Guard's effectiveness against the evolving attack surface. - [x] VALIDATE monitors Guard's detection rates and false positive rates -- if novel injection patterns from code repositories bypass Guard's initial rules, VALIDATE's monitoring detects the gap (new injection patterns succeeding, or anomalous code generation patterns) and triggers the IMPROVE phase > Correct! Code repositories change constantly -- new commits introduce new injection opportunities. VALIDATE continuously monitors whether Guard is catching attacks effectively. If attackers evolve their hidden instruction patterns to bypass Guard's current rules, VALIDATE detects this through declining detection rates, increasing anomalous output patterns, or user reports of suspicious code suggestions. This detection triggers IMPROVE, which updates Guard rules and Scanner's test library to address the new patterns. - [ ] VALIDATE runs AI Scanner against every code commit in the repository > Scanner assesses the AI model, not individual code commits. Code repository scanning is a separate code security function. - [ ] VALIDATE alerts the security team whenever Copilot generates code suggestions > Alerting on every code suggestion would be overwhelmingly noisy. VALIDATE monitors patterns and effectiveness metrics, not individual interactions. ## AI Scanner contributes to Layer 2 (Models) by "assessing models for adversarial robustness, backdoor indicators, and safety alignment." AI Guard's contribution to Layer 2 is listed as "N/A." Why doesn't Guard contribute to Layer 2? > Hint: Think about what Layer 2 protects and when Guard operates. - [ ] Guard is not compatible with Layer 2's container security tools > Guard's compatibility with other tools isn't the issue. The question is about the nature of what Layer 2 protects. - [ ] Guard cannot detect model-level vulnerabilities because it only sees prompts > While Guard does operate on prompts and responses, the deeper reason is about what Layer 2 is securing. - [x] Layer 2 secures model artifacts (weights, containers, supply chain) -- these are static assets that exist before and outside of runtime. Guard operates in the live request path on prompts and responses, which is a Layer 5 function, not a model artifact protection function > Correct! Layer 2 is about securing the model as an artifact -- its weights, container, integrity, and provenance. These are static properties that exist before the model serves any requests. Guard operates on dynamic traffic -- inspecting prompts and filtering responses in real time. Guard's protection is at the access layer (Layer 5), not at the model artifact layer (Layer 2). Scanner can assess the model artifact itself, which is why Scanner does contribute to Layer 2 while Guard does not. - [ ] Guard only contributes to Layers 5 and 6, not to any other layers > The cross-layer table shows Guard contributing to Layers 1, 3, 4, 5, and 6. Layer 2 is the exception because it protects static model artifacts, not runtime traffic.