Input Output Handling

An agent receives an input payload with a missing or null field and silently substitutes what it assumes is a "safe" default (zero, empty string, current date, `false`, the first enum value) instead of treating the absence as an error or asking for clarification. The assumed default is often wrong for the specific business context — a missing `discount_percent` treated as `0` when it should have blocked the order, or a missing `region` treated as `"US"` when the request originated elsewhere — and the agent proceeds to act on that fabricated value as if it were provided.

An agent reads input bytes assuming one character encoding (typically UTF-8) while the actual source encoded the text differently (Latin-1/ISO-8859-1, Windows-1252, UTF-16, or a legacy code page), producing mojibake — visually garbled or silently wrong characters — in names, addresses, and free text. Because most bytes in Latin-1 and Windows-1252 are also valid (but differently-meaning) UTF-8 continuation sequences for a wide range of inputs, the decode frequently "succeeds" without throwing an error, so the corruption passes silently into storage and downstream processing.

An agent interprets a date, number, or currency value using the wrong locale convention — reading "03/04/2026" as March 4th when the source used day-month-year, or parsing "1.234,56" as one-point-two-three-four instead of one thousand two hundred thirty-four point five six. The value parses without error under the wrong locale's rules, so the agent proceeds confidently with a value that is silently different from what the source intended.

An agent accepts input containing embedded null bytes (`�`) — whether from malicious crafting, corrupted upstream data, or binary content misrouted into a text field — and passes it to a downstream layer (a C-based library, a filesystem call, a database driver, or a validation regex) whose string handling treats the null byte as a terminator. The agent's own validation logic sees the full string and approves it, but the consuming layer only sees the truncated prefix, creating a gap between what was validated and what was actually acted on.

An agent's parser (JSON, XML, YAML, or a custom nested-structure format) receives an input with excessive nesting depth — either from a legitimately complex source, a buggy upstream serializer that loops, or a deliberately crafted payload — and the recursive-descent parsing logic exceeds the language runtime's call-stack limit or the parser's own recursion guard, crashing the process rather than rejecting the input gracefully. Because the crash happens inside the parsing library itself, it often takes down the whole request-handling worker rather than failing just the one bad input.

An upstream system that feeds an agent changes its data schema — renaming a field, changing a type, adding a required field, deprecating an enum value — without a coordinated update to the agent's input parser, so the agent either silently misreads the new shape (treating a renamed field as missing and falling back to a default) or crashes on fields it no longer recognizes. Because the agent's own code didn't change, the failure looks like a regression with no corresponding commit, making it unusually hard to diagnose.

An agent accepts an input payload (a document, a file upload, a JSON body, an attachment) without checking its size against any reasonable bound before processing it, so an unusually large input — whether legitimate, accidental, or adversarial — is loaded fully into memory, tokenized in full, or passed whole into a downstream call, causing memory pressure, request-latency spikes, or costly API usage that a small size check would have caught in microseconds.

An agent's input parsing or downstream rendering logic breaks when the input contains characters with structural meaning in some layer of the pipeline — quotes, backslashes, delimiters (commas, pipes, tabs), markup characters (`<`, `>`, `&`), or control characters — and that layer wasn't written to treat them as literal data. A customer name containing an apostrophe, a product description containing a comma inside a CSV field, or free text containing an unescaped `<` breaks parsing, corrupts a field boundary, or renders incorrectly, independent of any encoding issue.

An agent receives a timestamp or time-of-day value with no explicit timezone, or with a timezone abbreviation that is genuinely ambiguous (e.g. "CST" meaning Central Standard Time or China Standard Time), and interprets it using an assumed timezone — usually the server's local time, UTC, or the timezone of whichever user the agent most recently interacted with — that doesn't match what the source actually meant. The resulting timestamp is a valid, well-formed datetime that is simply wrong by however many hours separate the assumed and actual timezones.

An agent's input validation rule checks the input's surface form (a regex, a length check, an allowlist match) but the check can be satisfied by an encoding, formatting, or representation variant that is semantically equivalent to a blocked value while syntactically different enough to slip past the check. Unicode homoglyphs, alternate encodings, case variations, whitespace insertion, or double-encoding let disallowed content — a blocked word, a malicious path, an injection payload — pass a validator that was written to catch only the literal, canonical form.

An agent generates output text and serializes it in one encoding while the downstream consumer (an API client, a file writer, a terminal, an email client) expects or declares a different one, corrupting non-ASCII characters — accented letters, currency symbols, emoji, non-Latin scripts — before the text reaches its destination. Unlike an input encoding mismatch, the corruption is introduced by the agent's own serialization step rather than inherited from a source, and it typically affects every non-ASCII character the agent itself generates or passes through, not just specific fields.

An agent produces output intended to conform to a specific schema (JSON with required fields, a fixed CSV column set, an API response contract) and hands it directly to a downstream consumer without verifying it actually matches that schema first. Because LLM-generated output is probabilistic rather than mechanically guaranteed, a small but nonzero fraction of responses have a missing field, wrong type, extra field, or malformed structure — and without a validation gate, that malformed output reaches the consumer exactly as if it were valid, causing it to fail unpredictably rather than being caught at the source.

When an agent is required to produce output matching a fixed schema, it will sometimes fabricate a plausible-looking value for a field it has no actual basis for — inventing a tracking number, a confidence score, a source citation, or an ID — rather than leaving the field empty, marking it as unknown, or declining to complete the schema. The output is structurally valid and passes any format/type check, which makes the fabrication far more dangerous than a free-text hallucination: it looks exactly like a correctly-populated field to any downstream system or reviewer that trusts schema conformance as a proxy for correctness.

The same logical input, processed by an agent on separate occasions, produces output with a different structure, field set, ordering, or format each time — not because the underlying data changed, but because the generation process itself is nondeterministic and nothing constrains it to produce a stable shape. A consumer that parses the first call's output shape and hardcodes assumptions from it breaks on the next call, even though nothing about the request changed.

An agent constructs a downstream command, query, or markup document by directly interpolating its own generated text (or text derived from user/tool input the agent passed through) into a SQL statement, shell command, or HTML page without parameterization or escaping. Because the interpolated content can contain characters with special meaning in the target language, it can alter the structure of the command rather than being treated as inert data — the classic injection pattern, but with the agent's own generated or relayed text as the injection vector instead of a raw user form field.

An agent generates output without any hard cap on its length, and a downstream consumer with an actual limit — a database column with a fixed `VARCHAR` size, a UI element with a character budget, an SMS/notification channel with a payload cap, a third-party API with a field-length restriction — receives output that exceeds it. Depending on the consumer, this either causes a hard rejection (a database `INSERT` failing, an API returning a 400) or, worse, a silent truncation somewhere in the chain that the agent itself has no visibility into and cannot compensate for.

An agent returns a list or array whose element order varies from call to call for logically equivalent input, even though the consuming system depends on a stable order — for pagination cursors, for diffing successive results, for deterministic display, or for stable IDs derived from position. Because the list's *contents* are correct each time, the failure is easy to miss in isolated testing and only surfaces when two calls are compared against each other or when a consumer's assumption of stability is violated.

An agent generates or serializes a numeric value in a way that loses precision relative to the actual computed or intended value — rounding a currency amount that needed exact cent-level precision, formatting a large integer through a floating-point representation that can't represent it exactly, or truncating decimal places in a scientific/financial figure. The output looks like a reasonable number and passes any type check, but its value is subtly different from the correct one, and that difference compounds when the number feeds further calculation.

An agent generates text that must be embedded inside a structured format — a JSON string value, a CSV field, a shell argument, a string literal in generated code — and the content itself contains quote characters, apostrophes, or backslashes that need to be escaped for the target grammar. Because the model produces the escaped output as free-form text generation rather than by running a deterministic escaping function, it frequently gets the transform wrong: under-escaping (leaving a raw quote that terminates the string early), over-escaping (doubling an already-correct escape sequence), or escaping for the wrong target grammar entirely (JSON-escaping content destined for a shell command, or vice versa). The result is a downstream parse failure or a corrupted field, distinct from output injection in that no malicious input is required — the model breaks its own well-intentioned output on ordinary content like a customer's name containing an apostrophe.

A pipeline runs agent-generated output through a sanitization step — a blocklist filter, an HTML-stripping function, a pattern-based scrubber — before it reaches a downstream consumer, and the sanitizer genuinely runs and genuinely modifies output that matches its rules. The gap is that the sanitizer's rules cover a specific, enumerable set of dangerous patterns rather than the full space of ways the same underlying danger can be represented: an encoded or obfuscated variant of a blocked pattern passes through untouched because it doesn't match the literal pattern the sanitizer looks for, or content that was safe at the moment it was sanitized becomes dangerous again after a later transformation step (minification, template re-interpolation, client-side re-parsing) that the sanitizer never accounted for. This is distinct from having no sanitization at all — the defense exists, runs, and has a real but incomplete coverage boundary that a sufficiently different-looking payload slips past.

An agent's generated output — a chat completion, a streamed response, or a payload returned from a tool call — gets cut off mid-generation or mid-transmission (hitting a `max_tokens` cap, a proxy timeout, a streaming connection drop, or an intermediate buffer limit), and nothing in the pipeline detects or flags that the content is incomplete. The truncated fragment is syntactically plausible enough (a sentence that just stops, or JSON that's missing its closing braces) that it gets parsed, stored, or displayed as if it were the complete, intended output, rather than triggering a retry or an explicit incompleteness signal.

An agent produces output whose values are of one type — a string, a loosely-formatted number, a mixed-case boolean word — and the downstream system consuming that output performs an implicit type coercion while deserializing or ingesting it, silently converting the value into something semantically different rather than rejecting it. Because the coercion happens inside the consumer's parsing/deserialization layer rather than inside the agent, the agent has no visibility into the mismatch and no chance to correct it; the corrupted value simply propagates into the receiving system as if it were correct.