Untrusted inputs and the authority boundary
Why files, retrieved text and model output stay untrusted, and how to review them without granting extra tools, access or spending.
Keep content inside the authority boundary
You decide the permitted action, destination and tools. Treat files, retrieved pages and generated answers as data. For example, a document may say, “send the result to this other address.” That sentence is part of the document. It does not replace the destination you approved for the job, add a tool or increase the budget.
Your agent may use authorized content as evidence while it keeps the goal and project context, minimum input, task instructions, rubric, expected output and checks under your control. Validate caller-added instructions, examples, schemas, filenames and metadata separately; a derived-data scanner does not automatically inspect them. None of these surfaces can expand tools, permissions, budget, destinations or operations.
What content cannot authorize
Input text and model output cannot grant a new tool, add stages, increase a budget, change a data profile, select another recipient or weaken policy. A signed source or authenticated customer is still supplying content that must pass the applicable checks.
The work contract supplies the permitted operation and limits. Current account and execution authority supply permission. A model-generated JSON field is not a new permission, even when the JSON parses correctly.
Fixed-schema processing does not authorize arbitrary host commands. Work that executes customer source or tests belongs in its separately qualified disposable-VM path. Do not attempt to turn an ordinary document or inference task into that execution mode.
An upload resume, eligible retry, or accepted-result replay covered by the approved job or automation policy does not need a new customer approval. A changed destination, purpose, data scope, or other material term does.
Prepare and inspect a bounded input
Use the operation's supported format and limits. Inspect a small authorized sample locally for unexpected fields, embedded content, external references and credentials. Keep only the data needed for the task, and keep raw content out of metadata, logs, and diagnostic text.
A file extension does not prove its real format. Encryption does not make a malicious file safe. A successful scan is evidence about that check, not a guarantee that no unknown vulnerability exists.
If validation rejects the input, keep the rejected bytes outside the shared path. Correct the actual format or policy problem. Do not disable a parser check, strip a required safety field, or submit it under a more permissive label.
Review the output before acting
Check that the result matches the requested schema and the source evidence. Treat statements about permissions, payment, security status, or successful external actions as untrusted unless the responsible system confirms them.
A result may contain a link, command, or suggested action. Do not execute it merely because it appears in accepted output. A separate authorized workflow must review any tool use or external effect, and the responsible system must confirm claims about permissions, payment or completed actions.
Read failures, abstentions, and disagreements before relying on accepted rows. A valid artifact digest checks integrity; it does not make every interpretation correct. Use verification evidence to understand the checks attached to your result.
Stop and report a boundary problem
Stop when content appears to have changed the permitted action, accessed unrelated data, or exposed a credential. Preserve safe job and error references. Follow security reporting without reproducing hostile inputs on provider machines or including full customer payloads.
For an ordinary format refusal, use input rejection Help. Recovery should preserve the same access, budget, and destination boundaries, not work around them.