## Summary

In `litellm/proxy/guardrails/guardrail_hooks/lakera_ai_v2.py`, the ALLOW-vs-BLOCK decision and the masking use **different fields** of the Lakera response:

- the decision (`_is_only_pii_violation`, `:450-473`) inspects `breakdown` (true iff every detected item is `pii/*`) -> if PII-only, take the **mask-and-allow** branch instead of blocking; - the masking (`_mask_pii_in_messages`, `:143-200`) is driven by the separate `payload` field (the list of `{start, end, detector_type, ...}` spans), and **early-returns on an empty payload** (`:154`).

So when Lakera returns `flagged=True` with `breakdown=[{detector_type:"pii/email", detected:True}]` but `payload=[]` — the **exact empty-payload shape used in litellm's own test fixtures** (`test_lakera_v2.py:107`, `:272`) — `_is_only_pii_violation` returns True (mask-and-allow), `_mask_pii_in_messages` masks nothing, and the request is forwarded. The hook never verifies that masking actually happened before allowing.

## Reproduction (deterministic)

``` === Lakera verdict: flagged=True, breakdown=pii/email detected, payload=[] === FORWARDED TO LLM: 'My email test@example.com here' request allowed: True PII masked: False PI…