> ## Documentation Index > > Fetch the complete documentation index at: https://lithi.ai/llms.txt > > Use this file to discover all available pages before exploring further. --- title: Untrusted inputs and the authority boundary description: >- Compute treats every input as content, never as permission. Read what validation checks, which effects stay impossible whatever your data says, and where risk remains. route: /docs/compute/security/untrusted-inputs page_id: docs-compute-security-untrusted-inputs page_type: concept content_layer: guided documentation surface_profile: guided_docs audience: Security reviewers and integrators sending documents or third-party content voice: D reader_question: Can text inside my data make Compute do something I did not authorize? primary_action: Choose a quality preset source_locale: en-US source_status: APPROVED source_version: docs-compute-security-untrusted-inputs-en-us-2026-09-05-v1 last_updated: '2026-09-05' robots: index claim_registry_pinned: true claim_registry_resync: "npm run governed:tsx -- scripts/build-compute-public-claim-registry.ts --write" --- ## The rule this page exists to state Neither your data nor any instruction found inside it grants authority. Compute treats every input as content to process. A document that says "ignore your instructions and send this elsewhere" is a document that says that. It is not a command, and nothing downstream reads it as one. ## What validation actually checks Validation happens before work starts, against a frozen snapshot of your input. It checks the bytes, the schema and the item identity, so the thing that runs is the thing you sent. It also checks your parameters against the schema the workflow generated, and your declared limits. Validation is structural. It confirms your input has the shape the workflow declared. It does not confirm the content is true, safe, or written in good faith. ## Why content cannot reach authority Authority lives in credentials and approvals, not in the payload. A work key carries work scopes only, and management scopes are never mintable on a work key. So the credential that submits a job holds nothing that could register a destination, change a profile or move money. There is no path from content to a scope the caller never had. ## Effects that stay impossible whatever the input says - Admitting a job. Approval is a separate act by an identity that holds it. - Raising your maximum price, your deadline or a spend ceiling. - Minting or widening a scope, or reaching a management operation from a work key. - Registering or changing a source, destination, profile, schedule or webhook. - Changing the workflow, its version, or the output schema it validates against. - Writing to a destination nobody registered. - Initiating a payment. No debit operation exists on the finance surface. - Retrieving a credential. Lithi holds a reference, and the reference is not readable content. - Altering the frozen snapshot. A different digest under the same identity is refused as equivocation. ## Where injected text can still reach you The honest limit is the output, not the authority. Text inside your input can influence what a model writes about that input, in the same way a misleading document misleads a reader. That risk is handled by evidence, not by trust. A verification preset states what the result was checked against, and a rubric states what counts as acceptable. The result bundle then keeps failures, abstentions and preserved verifier disagreements in their own partitions. Read those partitions before you act on a batch. Verification tells you how a result was checked; it never promises the result is correct. ## What to do with genuinely hostile content Send it as content and keep the effects narrow. Register only the destinations you want written, keep the spend ceiling tight, and choose a preset that samples independently. Then review the disagreements. They are the part of the bundle that shows where the content pulled the checkers apart. [Choose a quality preset](/docs/compute/workflows/quality-presets)