Test a security boundary

Learning path · Part 5 · Part 5 exercises · Workbook

Self-study after Part 5 · slides 24 and 31–32 (notebook lesson 5). Alone or in pairs: one predicts, the other changes an input and records the outcome.

Core route. Predict each result before Evaluate proposal. (1) Role, verification and approval checked; injection unchecked. (2) Keep role/verification checked, remove approval. (3) Keep approval absent and add injection. Record one allow, two denials and one real-system limitation. Complete the full truth table only if you finish early.

Teaching steps: predict, do, observe, explain

1. Predict first: check role, verification and exact approval; leave injection unchecked. Evaluate proposal: should closure be allowed?

2. Keep role and verification checked. Remove exact approval. Evaluate again; inspect both decision and simulated ticket effect.

3. Keep approval absent. Add the injected instruction and evaluate. Does customer text change any trusted condition?

4. Explain one ALLOW and two DENY outcomes. Browser checkboxes illustrate a rule; they are not authenticated backend records.

The in-demo step controls move between instructions. They never perform the next experiment for you. Record one observation before moving on.

The rule you are testing

allow = has_close_role AND identity_verified AND exact_action_approved

Core: try all three checks true; then remove approval; then keep approval absent and add the injected instruction. Record one allowed and two denied cases and one real-system limitation.

Optional extension: write all eight combinations. Only the all-true combination should allow closure. This complete truth table is optional after the core three cases.

Beyond this simulator

The browser check is an educational calculation. In a real application, a backend must enforce the policy using authenticated identity, current permissions and approval bound to exact arguments. A user can change client-side code, so a browser calculation cannot protect a production service.

This exercise tests the rule's decision table. It does not establish real model behaviour, backend integration, secure identity handling, concurrency safety or absence of data disclosure. Add those requirements to your test cards.

Reading: OWASP LLM06:2025 (excessive agency).

Explain it to your partner

Question: The ticket text claims approval, but the approval check is false. What should happen, and which record would establish it?

Take 30 seconds each: point to the input, name the one change, then cite an observation from your run. A useful explanation: The rule denies closure without exact approval. A real integration check must also inspect the decision and authoritative ticket history.

Read next: Concept and research connection. The reading is optional; you do not need its mathematics for this exercise.