https://example.org/chapter3/s7/activity/index.html Test Your Knowledge: Layer 5 - Secure Access to AI Services Let’s see how much you’ve learned! This quiz tests your understanding of AI Gateway architecture, Zero Trust Secure Access for AI, prompt and response filtering, rate limiting, and how Layer 5 serves as the primary runtime defense. --- shuffle_answers: true shuffle_questions: false --- ## An AI Gateway processes a user request through four security checkpoints: Authenticate, Filter Input, Route, and Filter Output. A sophisticated prompt injection bypasses the input filter by using an encoding technique the filter doesn't recognize. What prevents the attack from succeeding? > Hint: Think about the dual-direction filtering in the AI Gateway and what happens when the model generates its response. - [ ] The routing stage detects the encoded injection and blocks the request > The routing stage handles model selection and load balancing, not security inspection. It directs the request to the appropriate model but doesn't analyze content. - [ ] The authentication stage detects that the user is attempting injection > Authentication verifies identity and API key validity. It doesn't inspect prompt content for injection patterns. - [x] Even though the injection reaches the model, the output filter catches the result -- if the model produces PII, harmful content, or system prompt fragments in response to the injection, the output filter blocks the response before it reaches the attacker > Correct! The AI Gateway's four-checkpoint architecture creates defense in depth within Layer 5 itself. The input filter is the first line, but the output filter provides a second check. If an encoded injection bypasses input filtering and manipulates the model into generating sensitive content, the output filter scans the response for PII, harmful content, system prompt leakage, and encoded exfiltration patterns before the response reaches the user. The attacker bypassed one checkpoint but faces another. - [ ] The model's internal safety alignment prevents it from responding to the injection > Model safety alignment provides some defense but is not reliable against sophisticated injection. The AI Gateway's output filtering operates independently of the model's judgment. ## A ZTSA policy for an AI service includes six components: Identity, Device Posture, Context, Data Scope, Action Scope, and Token Budget. A customer support agent needs to use an AI chatbot that accesses a product knowledge base. Which ZTSA policy configuration is most appropriate? > Hint: Apply the principle of least privilege across all six ZTSA components. - [ ] Full access to all data sources and actions, with a large token budget to avoid interrupting support conversations > Full access violates least-privilege. A support agent doesn't need access to HR records, financial data, or code execution capabilities. - [x] Identity: support-team group with MFA; Device: managed endpoint; Data scope: product-docs and public-kb only (deny HR, financial, source-code); Action scope: text-generation only (deny code execution and tool invocation); Token budget: appropriate daily limit > Correct! This configuration applies least-privilege across all six dimensions. The support agent only needs access to product documentation, only needs text generation (not code execution or tool invocation), and should have a reasonable token budget. Denying access to HR records, financial data, and source code prevents the AI from being used to access data outside the agent's role -- even if the user crafts a clever prompt requesting it. - [ ] Identity: any authenticated user; Device: any; Data scope: all knowledge bases; Action scope: all actions; Token budget: unlimited > This configuration provides no meaningful access control. ZTSA's value comes from constraining each dimension to the minimum required for the use case. - [ ] Identity: support-team group; Device: managed; Data scope: all knowledge bases to provide comprehensive answers; Action scope: text-generation only; Token budget: 1000 tokens per day > While action scope is correctly limited, data scope should also be restricted. "All knowledge bases" includes HR and financial data the support agent doesn't need. The token budget of 1000/day is also likely too restrictive for a support role. ## The prompt filtering pipeline has three stages: Injection Detection, Content Policy Check, and Instruction Hierarchy. An attacker sends a prompt in obfuscated Unicode that says "disregard your safety guidelines." Which filtering stage catches this? > Hint: Think about what each stage detects and which one understands meaning rather than just patterns. - [ ] Injection Detection -- it matches the "disregard" keyword pattern > Pattern-based injection detection catches known keyword patterns in standard text. Obfuscated Unicode may bypass keyword matching because the characters don't match the pattern library's standard text entries. - [x] Injection Detection using semantic analysis -- the ML-based classifier evaluates the intent of the prompt even when the text is obfuscated in Unicode, detecting the meaning rather than just matching keywords > Correct! The section describes two injection detection approaches: pattern-based and semantic analysis. When obfuscated Unicode bypasses keyword matching (pattern-based), the semantic analysis classifier evaluates the prompt's intent. An ML classifier trained to recognize "disregard safety guidelines" will detect that meaning regardless of whether the text uses standard characters or Unicode substitutes. This is why the pipeline uses both approaches. - [ ] Content Policy Check -- it flags the prompt as violating content policies > The Content Policy Check evaluates against prohibited topics and data sensitivity rules. While "disregard safety guidelines" might trigger content policy rules, the primary detection mechanism for injection attempts is the Injection Detection stage. - [ ] Instruction Hierarchy -- it enforces system prompt priority over user input > Instruction Hierarchy ensures that system prompt instructions take priority over user inputs. This is a defense mechanism that operates after the prompt reaches the model, not a detection mechanism for catching injection attempts in the filtering pipeline. ## A financial services company runs an AI assistant that helps traders analyze market data. The assistant has access to real-time pricing APIs and can execute analytical queries. Which rate limiting dimension should the security team prioritize FIRST to prevent the greatest financial damage from a compromised or hijacked session? > Hint: Consider the 5 rate limiting dimensions (request rate, token budget, cost ceiling, concurrent sessions, tool execution limits) and think about which one prevents the most expensive abuse scenario for this specific use case. - [ ] Request rate -- limiting requests per minute prevents rapid-fire abuse > Request rate limiting prevents volume-based abuse, but a sophisticated attacker can cause enormous financial damage with very few requests. A single carefully crafted request to a pricing API could execute an expensive analytical query or trigger costly data retrieval. For financial services, the damage per request matters more than the number of requests. - [ ] Concurrent sessions -- limiting parallel sessions prevents multi-session abuse > Concurrent session limits prevent an attacker from opening many sessions simultaneously, but the primary financial risk comes from what happens within a single compromised session. A single hijacked session with no cost controls can consume unlimited API and compute resources. - [x] Cost ceiling -- a per-session and per-day dollar cap directly bounds the maximum financial exposure from any abuse scenario, regardless of whether the abuse uses many small requests or few large ones > Correct! Cost ceiling is prioritized because it directly caps financial damage -- the primary concern for a financial services deployment. The judgment framework: (1) damage prevention -- cost ceiling is the only dimension that directly bounds dollar exposure; request rate and token budget limit activity volume but don't directly translate to dollar amounts (a single expensive API call can cost more than 1,000 cheap requests); (2) scenario coverage -- cost ceiling catches both high-volume abuse (many cheap requests) and high-value abuse (few expensive requests), while request rate only catches the former; (3) blast radius containment -- when a session is compromised, cost ceiling ensures the attacker cannot run up unlimited charges regardless of their technique. Token budgets and request rates are important supporting controls, but cost ceiling is the financial backstop. - [ ] Token budget -- limiting tokens per hour prevents expensive context window abuse > Token budgets prevent context window abuse, but tokens are only one component of cost for a financial services AI assistant. The real expense comes from pricing API calls, analytical queries, and compute resources -- none of which are measured in tokens. Cost ceiling captures all cost sources, not just token consumption. ## Multi-dimensional rate limiting operates on five dimensions. An organization sets a 10-request-per-minute limit and a 100,000-token-per-hour limit. An attacker sends 5 requests per minute (under the request limit) but each request contains 50,000 input tokens. Which rate limiting dimension catches this abuse? > Hint: Consider which dimension measures the actual resource consumption per request. - [ ] Request rate -- 5 requests per minute is under the 10-request limit > The attacker deliberately stays under the request rate limit. Request rate limiting alone doesn't catch this abuse pattern because it counts requests, not resource consumption. - [x] Token budget -- 5 requests x 50,000 tokens = 250,000 tokens per hour, which exceeds the 100,000 token-per-hour limit > Correct! This is exactly why multi-dimensional rate limiting is necessary. A single 50,000-token request consumes far more resources than a typical short prompt. Token budget limiting catches abuse patterns that stay under request rate limits but consume disproportionate resources. Without token budgets, an attacker could consume $1,000 in compute with just 5 carefully crafted requests. - [ ] Cost ceiling -- the dollar cost exceeds the daily budget > Cost ceilings are another important dimension, but the question asks which dimension catches this specific abuse. Token budget is the direct catch -- it measures the tokens consumed and compares against the hourly limit. - [ ] Concurrent sessions -- the attacker is using multiple sessions > The scenario describes a single user making sequential requests, not multiple concurrent sessions. Concurrent session limits address a different abuse pattern. ## The section states that Layer 5 "maps to the largest number of OWASP categories" of all six Blueprint layers. Why is this the case? > Hint: Think about what Layer 5 sits between and what passes through it. - [ ] Layer 5 is the most expensive to implement, so it needs to justify its cost by covering more categories > OWASP category coverage is determined by what the layer protects, not by implementation cost or justification needs. - [ ] Layer 5 was designed after the other layers to fill gaps in their coverage > The Blueprint layers were designed as a coherent system. Layer 5's broad OWASP mapping reflects its position in the architecture, not its design sequence. - [x] Layer 5 sits in the live request path between users/agents and AI services -- every prompt and every response passes through it, making it the interception point for injection, data leakage, output handling, system prompt leakage, agent hijacking, and more > Correct! Layer 5 is the front line of runtime AI security. Every user prompt, every model response, every agent action, and every tool call passes through the access layer. This means prompt injection (LLM01), sensitive information disclosure (LLM02), improper output handling (LLM05), system prompt leakage (LLM07), and agent goal hijacking (ASI01) are all intercepted at Layer 5. No other layer sees as much AI traffic as the access layer. - [ ] The OWASP framework was designed with Layer 5 in mind > The OWASP LLM Top 10 was developed independently of any specific vendor framework. The mapping reflects Layer 5's architectural position, not coordination between OWASP and the Blueprint. ## The conceptual ZTSA policy example in the section includes an `input_filtering` section with `blocked_patterns`. The policy blocks "ignore previous", "system prompt", and "developer mode". A skilled attacker avoids these exact phrases. What other defense in the ZTSA policy catches their injection attempt? > Hint: Look at the input_filtering section of the conceptual policy beyond just blocked_patterns. - [ ] The `identity` section -- authenticated users can't perform injection > Authentication verifies who the user is, not what they're asking. Authenticated users can absolutely attempt prompt injection. - [ ] The `rate_limits` section -- limiting requests prevents injection attempts > Rate limiting prevents abuse through volume but doesn't analyze the content of individual prompts for injection patterns. - [x] The `injection_detection: enabled` setting -- this activates semantic analysis and heuristic-based injection detection beyond the simple blocked_patterns list > Correct! The conceptual ZTSA policy has both `injection_detection: enabled` and `blocked_patterns`. The blocked patterns are a simple keyword blocklist -- the first line of defense. The injection detection setting enables the more sophisticated semantic analysis and ML-based classifiers described earlier in the section. These detect injection intent regardless of the specific phrases used, catching novel injection attempts that avoid known keyword patterns. - [ ] The `output_filtering` section -- even if injection succeeds, the output is filtered > Output filtering is a defense-in-depth backup, not an input-side catch. The question asks what catches the injection attempt at the input stage, which is the injection_detection setting. Hugo en-us