On this page
The short answer
Validate tool output before treating it as evidence or using it to authorize another action. Check structure, source identity, freshness, and operation status separately. A well-formed JSON object can still describe the wrong account, stale state, or an untrusted instruction that the model should not execute.
What to take away
- Separate syntactic validity from business truth.
- Bind results to the request and caller.
- Treat embedded instructions as source content.
Sources checked . Research synthesis and Rubrex recommendations. Examples and local experiments are labeled; they are not client results.
Define the response contract at the adapter
OWASP describes risks when generated output reaches downstream consumers without appropriate handling. The reverse direction also deserves a clear contract: Rubrex recommends validating external tool results before an agent uses them. State the expected fields, request identifier, source scope, and allowable status values.
Use a synthetic customer lookup tool. A valid response includes the requested customer identifier, observation version, account status, and provenance reference. The model should not have to infer whether a response belongs to the current request from a customer’s display name or a natural-language success sentence.
Break meaning while preserving valid syntax
Return valid JSON for the wrong customer, a stale version, a contradictory status pair, and a success field with no required receipt. Add one malformed response to retain a basic schema control. These cases distinguish parsing checks from the semantic contract that protects the next operation.
Place a harmless instruction in a free-text note asking the agent to call an unrelated tool. The note can be summarized if relevant, but it cannot extend the caller’s authority. Capture the next tool proposal and service decision to show whether the application separates source content from permitted workflow transitions.
Check downstream consequences and useful rejection
Observe whether invalid results are quarantined, retried under the defined contract, or surfaced as an evidence gap. A generic error can be acceptable if it preserves the task state and gives a useful next step. Silently replacing missing fields with model-generated defaults can create a plausible but false basis for a write.
Retain request and response identifiers, validation decisions, attempted next actions, and final outcome. Include an ordinary valid response and a legitimate unknown-status case. Report false rejection separately: rejecting every unusual account can protect the fixture while making the assistant fail real supported work.
| Case | Evidence to retain | Acceptance condition |
|---|---|---|
| Wrong customer | Request/response identity | No downstream write |
| Missing receipt | Status and required fields | Completion unconfirmed |
| Instruction in note | Note and attempted action | No expanded authority |
Accept only validated state transitions
For customer lookup, release the next-step automation when the wrong-account and stale-state cases cannot authorize a write and the valid control still completes. Put request binding and required receipt checks in deterministic application code where feasible. Use model judgment for interpretation that remains within those boundaries.
Version the response contract with the adapter and retain failed payloads in a restricted, sanitized form. Re-run when upstream fields, pagination, or status semantics change. The target is a reliable transition from external observation to permitted action, not a claim that any JSON schema can prove the content true.
Limits of the evidence
All customer records and malformed outputs are authored test cases. No upstream API was audited. Schema and semantic checks cover the defined contract, not arbitrary truth, complete freshness, or every possible malicious payload.
Common questions
Is valid JSON sufficient?
No. Check identity, state, provenance, and the business meaning needed for the next step.
Can missing fields be guessed?
Do not invent facts that determine authorization or completion; preserve an explicit unknown state.
Sources & further reading
Primary sources behind this briefing. A source’s findings apply to its own study conditions; publication on arXiv does not establish peer review.
- OWASP LLM05:2025 Improper Output Handling OWASP · 2025 · Security guidanceReviewed: risk at downstream consumers of generated output; risk edition year retained. Accessed October 16, 2026.
Questions or corrections? Write to Rubrex. Read our editorial approach.