Input Validation

Whitelist (allowlist) validation defines a set of explicitly permitted characters, patterns, or values, rejecting everything else. This is the preferred, more secure approach.

Blacklist (denylist) validation defines a set of known malicious patterns to reject. This is less secure as it's impossible to anticipate all attack vectors.

• Example: For a username field, a whitelist might permit only alphanumeric characters and underscores ([a-zA-Z0-9_]), while a blacklist might attempt to block SQL keywords like SELECT or DROP.

This technique verifies that input data matches the expected primitive type (integer, string, boolean) and falls within defined logical boundaries.

• Type Checking: Ensures a field expecting an integer doesn't receive a string.
• Range Checking: Validates that a numerical value is within minimum and maximum limits (e.g., age between 0 and 150).
• Length Checking: Enforces minimum and maximum character lengths for strings (e.g., password must be 8-128 characters).
• Format Validation: Uses regular expressions or parsers for structured data like email addresses, phone numbers, or UUIDs.

Goes beyond syntax to check the logical meaning and business context of the input. This often requires application-level logic.

• Cross-Field Validation: Ensures relationships between fields are logical (e.g., end_date must be after start_date).
• Business Rule Enforcement: Validates against domain-specific rules (e.g., a transfer_amount cannot exceed the account balance).
• State-Dependent Checks: Input validity may depend on the current system state (e.g., can only cancel an order if its status is pending).

Canonicalization reduces input to its simplest, standard form before validation. Sanitization modifies or escapes input to make it safe.

• Canonicalization: Converting text to a standard character encoding (UTF-8), normalizing URLs, or resolving relative paths to absolute ones. Attackers often use encoded characters (e.g., %2e for .) to bypass checks.
• Sanitization: Escaping HTML characters (< to <) to prevent Cross-Site Scripting (XSS) or escaping quotes in SQL strings. Crucially, sanitization is a secondary defense; primary validation should reject invalid data.

In multi-agent systems, validation must account for the unique risks of agent communication and tool calling.

• Structured Output Parsing: Validating that an LLM agent's output strictly adheres to a defined schema (e.g., using Pydantic or the Model Context Protocol) before it's passed as input to another agent or tool.
• Tool Argument Validation: Each tool exposed to an agent must rigorously validate its own parameters, enforcing the principle of least privilege for agent actions.
• Inter-Agent Message Validation: Messages between agents should be validated against a shared communication protocol schema to prevent malformed or malicious state corruption.

Data sanitization is the process of cleansing or neutralizing potentially dangerous data that has passed initial validation. While validation rejects malformed input, sanitization transforms accepted input into a safe format.

• Example: An agent receives a user-provided string for a database query. Validation ensures it's a string; sanitization escapes special characters (e.g., turning ' into \') to prevent SQL injection.
• Key Distinction: Sanitization acts as a secondary defense layer, often applied to data before it is used in a sensitive context like system commands, database queries, or rendered outputs.

Schema validation is a formal, declarative approach to input validation where data is checked against a predefined schema or data contract. This is especially critical for structured communication between agents.

• Mechanism: Uses schemas (e.g., JSON Schema, Protobuf, Pydantic models) to define the expected structure, data types, constraints, and optional/required fields of a message.
• Agent Communication: Ensures that inter-agent messages (like those in an Agent Communication Protocol) are well-formed before processing, preventing crashes or unintended behavior due to malformed payloads.
• Automation: Often automated within framework serialization/deserialization layers, providing consistent validation across all agent interactions.

These are two opposing strategies for defining acceptable input.

• Whitelisting (Allowlisting): Defines a set of known-good patterns (e.g., specific characters, formats, or values). Anything not on the list is rejected. This is the preferred, more secure approach for validation. Example: Validating a US state code against a list of 50 valid two-letter codes.
• Blacklisting (Denylisting): Defines a set of known-bad patterns (e.g., specific SQL keywords or script tags). It only blocks what's on the list. This is less secure as it's impossible to anticipate all malicious inputs. Example: Filtering out the string <script> from text, which can be easily bypassed with obfuscation.

Boundary checking is a specific type of input validation that ensures numerical or sequential values fall within acceptable minimum and maximum limits. Failure to perform this can lead to buffer overflows, integer overflows, or logical errors.

• Numerical Ranges: Validating that a temperature parameter for a control agent is between -50 and 150 degrees.
• Array/Index Bounds: Ensuring an agent's request for item index n is less than the length of a list to prevent out-of-bounds memory access.
• Resource Limits: Checking that a requested file size or computational budget is within allocated quotas to prevent denial-of-service (DoS) attacks.

Regular expression validation uses pattern-matching rules to determine if a string conforms to a specific format. It is a powerful but complex tool for syntactic validation.

• Common Use Cases:
  • Validating email addresses, phone numbers, or UUIDs.
  • Ensuring a string matches a specific pattern (e.g., YYYY-MM-DD for dates).
• Considerations: Complex regex can be performance-intensive and difficult to maintain. It is prone to errors that may allow bypasses. It should be combined with other validation methods and never used as the sole security control.

Context-aware validation tailors validation logic based on the source, destination, or intended use of the data within the multi-agent system. This moves beyond simple syntactic checks to semantic and business-logic validation.

• Agent Role: Data from a high-privilege orchestrator agent may be subject to different validation rules than data from a newly registered worker agent.
• Execution Stage: Input for a database query is validated differently than input for a command-line tool execution or prompt construction.
• System State: Validation may change based on the current operational mode (e.g., training vs. inference, high-alert vs. normal). This is a key component of a Zero-Trust Architecture for agents.