[EAAPL-SEC005] LLM Input Sanitisation

Category: Security / Data Protection Sub-category: Pre-Processing Pipeline Version: 1.2 Maturity: Proven Tags: pii-detection data-redaction input-validation token-budget schema-validation content-inspection privacy Regulatory Relevance: Australian Privacy Act 1988, GDPR Art. 25 (Privacy by Design), APRA CPS234, EU AI Act Art. 10, NIST AI RMF MAP 1.5

1. Executive Summary

LLM Input Sanitisation is a pre-processing pipeline that transforms raw application inputs into safe, compliant, and policy-conformant prompts before they reach a large language model. Where the Prompt Firewall (EAAPL-SEC002) focuses on adversarial intent detection, Input Sanitisation focuses on data governance: ensuring that sensitive information, PII, and confidential context does not reach model providers without appropriate controls.

For organisations in regulated industries, the business imperative is clear: sending personally identifiable information, protected health information, or financial account details to a commercial LLM API may constitute an unauthorised disclosure under privacy legislation. Input sanitisation enforces privacy by design at the AI layer — detecting and redacting sensitive data fields before they leave the organisation's security boundary.

Beyond privacy, this pattern provides: token budget enforcement (preventing prompt bloat that drives cost overruns), schema validation (ensuring prompts conform to expected structure, preventing context injection), and malicious content detection (detecting attempts to smuggle harmful content into the model's context through user-provided data). The pattern is deployed as a pipeline stage within the AI Gateway and operates on assembled prompts, after application-level prompt construction but before model provider submission.

2. Problem Statement

Business Problem

Organisations building AI features routinely construct prompts that include user data: customer names, email addresses, account numbers, medical histories, financial transactions. In many implementations, this data flows directly into model API calls without sanitisation. The consequences:

• Privacy breaches when PII is included in prompts sent to commercial model providers whose data handling agreements may not cover the specific use.
• Regulatory violations (Privacy Act, GDPR) if personal information is disclosed to third parties without appropriate consent or contractual protection.
• Confidential business information in prompts potentially available to model provider staff during safety review processes.
• Token waste from verbose, unsanitised prompts inflating costs.

Technical Problem

Application developers building AI features rarely have deep expertise in PII detection or data classification. They construct prompts using string templates that include whatever fields are available in the data object — often including fields that should not be sent to the model. Without a centralised sanitisation layer, each application team must independently implement PII detection, which leads to inconsistent coverage and inevitable gaps.

Additionally, prompts can grow unboundedly through: accumulated conversation history, large document chunks from RAG systems, verbose user inputs, and multiple context injections. Without token budget enforcement, prompts exceed model context windows (causing errors) or consume excessive tokens (driving cost overruns).

Symptoms

• Customer PII appearing in model provider usage logs (discovered during vendor audit).
• Prompts regularly exceeding model context limits, causing application errors.
• Different applications sending different categories of data to models with no central policy.
• No mechanism to audit what data has been sent to model providers.
• Token costs unexpectedly high due to verbose, unsanitised prompts.

Cost of Inaction

3. Context

When to Apply

• Any AI application that constructs prompts including user-provided data, database records, or document content.
• Applications sending prompts to external (commercial) model provider APIs.
• RAG systems where document chunks are injected into prompts.
• Conversational AI systems accumulating multi-turn context.
• Regulated industries where data handling obligations apply to AI pipelines.

When NOT to Apply

• Fully offline inference where the model is deployed within the organisation's own security boundary and no data leaves.
• AI applications processing only non-sensitive, fully public data with no user context.
• Development/sandbox environments processing synthetic data only.

Prerequisites

Industry Applicability

4. Architecture Overview

The LLM Input Sanitisation pipeline operates on the fully assembled prompt — after application code has constructed it but before it is forwarded to the model provider. This placement is intentional: sanitisation must occur at a point where the complete prompt context is available (system message + conversation history + user input + RAG context), not in the application before assembly, because PII can appear in any component.

Stage 1: Structural Analysis

The pipeline begins by parsing the prompt structure: identifying system message, user turns, assistant turns, and injected context blocks. This structural awareness is critical because different prompt components warrant different sanitisation policies — system messages may intentionally contain structured data while user inputs should be more aggressively sanitised.

Stage 2: Entity Detection and Classification

The PII detection engine runs structured entity recognition across all prompt components. Detection uses multiple techniques in combination:

• Pattern-based detection: Regular expressions for highly structured PII (credit card numbers, Australian Tax File Numbers, Medicare numbers, phone numbers, email addresses, IP addresses).
• NER-based detection: Named Entity Recognition models (spaCy, Presidio) for names, organisations, addresses, dates.
• Context-aware detection: Recognising that "My name is [X]" followed by a word in a name format context is likely a personal name.
• Custom entity types: Organisation-specific entity types (internal account numbers, employee IDs, proprietary codes) registered in the detection configuration.

Detected entities are classified by type and sensitivity. Not all PII is treated identically — a first name in a customer service context may be acceptable while a full name combined with account number and DOB constitutes high-sensitivity data.

Stage 3: Redaction Strategy

Detected sensitive entities are processed according to the configured redaction strategy per entity type:

• Replacement: Entity replaced with a type label [PERSON_NAME], [ACCOUNT_NUMBER], [EMAIL_ADDRESS]. The model can still understand the structure of the prompt without the sensitive value.
• Pseudonymisation: Entity replaced with a consistent pseudonym (same entity gets the same pseudonym within a session), allowing the model to reason about relationships without knowing the actual value. Pseudonym mapping stored server-side, not in the prompt.
• Hashing: Entity replaced with a short hash for entity correlation without disclosure.
• Removal: Entity removed entirely (for very high-sensitivity fields that add no reasoning value).

Redaction decisions are logged for audit: which entities were detected, which redaction strategy was applied, and a hash of the original value for post-hoc investigation if needed.

Stage 4: Token Budget Enforcement

After PII detection, the sanitised prompt is tokenised and measured against the configured token budget for the request type. If the prompt exceeds the budget:

• Conversation history is truncated (oldest turns removed first) while preserving the system message and current user turn.
• RAG context blocks are truncated (lowest-relevance chunks removed first, if relevance scores are available).
• If the prompt still exceeds budget after truncation, the request is rejected with a clear error to the calling application.

Token budget enforcement protects both cost (over-budget requests waste tokens) and model performance (prompts near the context limit produce degraded outputs).

Stage 5: Schema Validation

The final sanitised prompt is validated against a schema for the specific use case. Schema validation catches context injection attempts: if the application template expects {user_question} but the user has provided content that looks like an additional system instruction, schema validation detects the structural anomaly. This is a lightweight but effective complement to the Prompt Firewall's semantic injection detection.

5. Architecture Diagram

6. Components

7. Data Flow

Primary Flow

Error Flow

8. Security Considerations

Authentication & Authorisation

• Sanitisation pipeline is an internal component; access controlled by AI Gateway (not exposed directly to applications).
• Pseudonym mapping store access restricted to the sanitisation service; no application can retrieve original values from pseudonyms.

Secrets Management

• Commercial PII detection API credentials (if used) managed per EAAPL-SEC008.
• Pseudonym mapping keys encrypted at rest; scoped to session TTL.

Data Classification

• Sanitisation policies are classification-aware: data at higher sensitivity levels triggers more aggressive redaction.
• Prompt classification label is attached after sanitisation (indicating residual sensitivity after redaction).

Encryption

• All pipeline communication in transit over TLS 1.3.
• Sanitisation audit log encrypted at rest; includes entity type and value hash but not original sensitive values.
• Pseudonym store contents encrypted at rest.

OWASP LLM Top 10 Coverage

9. Governance Considerations

Responsible AI

• Privacy by design: PII is removed from AI inputs by default, not as an afterthought.
• Redaction decisions must be reviewed for fairness: aggressive redaction that removes cultural names or non-Western name formats may degrade AI quality for certain users disproportionately.

Governance Artefacts

10. Operational Considerations

SLOs

Incident Management

• PII detected in model provider response (indicating sanitisation miss) → P1: Privacy incident; investigate detection gap; notify privacy team.
• Sanitisation pipeline degraded (PII detection unavailable) → P2 if fail-open; P1 if regulated data pathway.
• Unusual spike in redaction volume → Investigate: may indicate a new data integration sending unexpected PII.

11. Cost Considerations

Cost Drivers

Indicative Cost Range

12. Trade-Off Analysis

Option Comparison

Architectural Tensions

13. Failure Modes

14. Regulatory Considerations

15. Reference Implementations

AWS

Azure

On-Premises

16. Related Patterns

17. Maturity Assessment

Overall Maturity: Proven

18. Revision History