Input Validation

Input validation treats incoming data as untrusted until it passes checks appropriate to the operation. Inputs include API requests, uploaded documents, queue messages, retrieved content, user prompts, and arguments generated by a foundation model for a tool call. Validation should occur at each trust boundary: a request accepted by an API gateway may still be invalid for a business operation or unsafe for a downstream tool.

Structural validation checks required fields, data types, lengths, nesting depth, enumerated values, and permitted properties. Semantic validation checks meaning and relationships, such as whether a start date precedes an end date or a requested refund is within an order's refundable balance. Use explicit schemas and allowlists where feasible. Decode and normalize data consistently before evaluating relevant rules, and reject ambiguous representations rather than allowing different components to interpret the same input differently.

Generative AI applications also need content safety checks before sending user input to a foundation model. These can detect policy-defined harmful content, prohibited topics, sensitive information, and prompt attacks. Amazon Bedrock Guardrails can provide configured content safety controls, while application code supplies domain-specific rules. Moderation is probabilistic and can produce false positives and false negatives; it does not prove that an input is harmless. Retrieved documents and tool responses also require careful handling because they can contain instructions that attempt to override the application's intended behavior.

A practical real-time workflow first enforces request size and schema constraints, then applies content moderation and domain checks before model invocation. AWS Step Functions can coordinate Lambda-based validators and moderation calls, branching to rejection, an approved processing path, or human review. Define what happens when a required validator times out or becomes unavailable. For sensitive operations, fail closed by preventing the action until validation succeeds rather than silently bypassing the check.

Agentic applications must validate every proposed tool invocation independently of the model's reasoning. Standardized function definitions describe parameter names, types, required fields, and intended behavior, but a schema supplied to a model is not an execution-time security boundary. With the Strands Agents SDK, custom tools and lifecycle hooks can support validation behaviors; the tool implementation should still enforce its own contract. For example, a transfer tool can reject negative amounts, unsupported currencies, and unexpected parameters before any side effect occurs. Separately, authorization must establish whether the caller may use the specified account.

A Lambda tool handler can return a structured validation error identifying an invalid field without exposing credentials, internal stack traces, or unnecessary sensitive data. An agent may then request clarification or repair its arguments within bounded attempts. Invalid arguments should not trigger blind retries, and retries of side-effecting operations require idempotency protection. Recheck mutable business conditions immediately before execution because an earlier valid balance or resource state may have changed.

Validation is not sanitization, authorization, or a substitute for parameterized queries and context-aware output encoding. Removing suspicious characters can corrupt legitimate data while leaving other attack paths open. Layer inexpensive deterministic checks ahead of costlier moderation where practical, and measure rejection rates, latency, and policy effectiveness using privacy-conscious logs. Validate model outputs before presenting them or using them as downstream inputs; filtering the original prompt alone does not guarantee safe responses or actions.