## Problem

`skip_system_message_in_guardrail` / `skip_tool_message_in_guardrail` are documented, generic guardrail config options (per-guardrail field on `BaseLitellmParams`, plus a global `litellm.skip_system_message_in_guardrail` / `litellm.skip_tool_message_in_guardrail` fallback). They work correctly for any guardrail routed through the unified translation framework (`UnifiedLLMGuardrails` / `apply_guardrail()`), because that framework calls the shared `effective_skip_system_message_for_guardrail` / `effective_skip_tool_message_for_guardrail` helpers before building the text sent to the external guardrail API.

The Lakera v2 guardrail (`litellm/proxy/guardrails/guardrail_hooks/lakera_ai_v2.py`) implements `async_pre_call_hook`/`async_moderation_hook` directly (a "bespoke hook" guardrail, not routed through the unified framework) and never calls those helpers. Setting `skip_system_message_in_guardrail: true` on a Lakera guardrail config has zero effect — system prompts (and, with the tool flag, tool messages) are still sent verbatim to Lakera's `/v2/guard` API on every request.

This causes two real problems: 1. Data exposure — a system prompt a team wants kept out of a third-p…