Generative AI / Editorial solution guide

Untrusted source changes the task: protect tool and data boundaries

Diagnose instruction-like source content and unauthorized proposals with deterministic policy checks, safe evidence, and no real tool execution.

About 4 min readContent reviewed

Read-only knowledge base · No public comments

Recognize the symptoms

After reading a document or tool result, a system changes destination, requests another tenant’s data, proposes an unsupported action, or treats source text as a new approval. These are possible trust-boundary failures.

Understand the likely causes

  • Typical causes include mixing instructions with evidence, letting generated arguments define authority, trusting source-supplied role labels, broad tool credentials, and failing to check outputs or logs. A phrase filter can miss alternative wording and overblock harmless quotations. Privacy and actual tool effects must be inspected separately from apparent model compliance.

Preserve the authorized task and safe trace

Record the original user goal, trusted actor scope, source provenance, selected tool capabilities, safe proposal shape, and verified outcome class. Do not copy credentials or protected content into a reproduction. Distinguish source text, model proposal, policy decision, and actual effect. A generated claim that a message was sent is not delivery evidence. Use public synthetic fixtures first; this guide contacts no model, external page, account, shell, email system, or cloud tool.

Locate the data-to-authority crossing

Ask which component allowed a document, search result, or tool response to change the task, actor, approval, or destination. Delimiters and prompt reminders can help organization but do not enforce permission. The first offline gate rejects an unsupported tool and an excluded source regardless of valid object shape. It tests a deterministic consumer boundary, not whether a model resists every malicious instruction. If a denied proposal still leaks protected text in the answer or logs, the blocked tool alone does not establish containment. Inspect all output paths.

python Offline consumer-boundary regression 
def gate(proposal, allowed_sources):
    if set(proposal) != {"tool", "source_id"} or proposal["tool"] != "lookup":
        return "denied_tool_or_shape"
    if proposal["source_id"] not in allowed_sources:
        return "denied_scope"
    return "allowed_synthetic_read"
print(gate({"tool": "lookup", "source_id": "lab-a"}, {"lab-a"}))
print(gate({"tool": "publish", "source_id": "lab-a"}, {"lab-a"}))
print(gate({"tool": "lookup", "source_id": "lab-b"}, {"lab-a"}))
Expected output
allowed_synthetic_read
denied_tool_or_shape
denied_scope

One synthetic read is allowed and two unauthorized proposals are denied. The function performs no lookup, message, write, network request, or model invocation.

Restore trusted policy outside generation

Keep identity, tenant, tool registry, argument schema, destination rules, and approval state under application ownership. Approval must come from an authorized independent decision and bind to exact reviewed arguments. Do not repair the problem by asking the model to promise harder or by broadening access until the task succeeds. The second record separates a public source instruction from an application policy and requires a denied or reviewed outcome for unauthorized change. Its labels are server-owned assumptions in a fictional review record, not assertions parsed from untrusted content.

yaml Synthetic trust-crossing review record 
original_task: answer-from-authorized-public-policy
source_origin: untrusted-retrieved-text
source_claim: change-destination-and-approval
trusted_policy_owner: application
authorized_destinations: separately-reviewed-allowlist
required_outcome: deny-or-review-unapproved-change
status: synthetic-record-no-action-executed

Source content cannot grant its requested authority. The record is not a prompt-injection detector or proof of model obedience and is never sent to a model or tool.

Review data exposure and uncertain effects

Check authorized source filtering, model-facing fields, caches, citations, errors, traces, and retained evaluation artifacts. Derived summaries or embeddings can retain sensitive information after original text is removed. If a real external operation may have occurred, use its verified identity and reconciliation path; a lost response is not proof of no effect. Do not repeat writes blindly or perform an unreviewed purge. Keep containment, credential response, user communication, and residual tasks with the responsible owners under the actual incident process. None of those real actions is executed here.

Verify protection and ordinary usefulness

Use a regression matrix covering authorized reads, wrong tenants, unknown tools, forged approval fields, instruction-like quotations, alternate source positions, and benign tasks. Assert denied effects and absence of protected data, while verifying allowed tasks still work. Record model proposals and application enforcement separately. A finite passing suite does not prove universal injection resistance, so state configuration, scope, limitations, and triggers for re-evaluation when the system changes.

Verify the fix

The repaired path should preserve the original authorized task, deny prohibited actions, and keep protected material absent from all consumer paths. Verify both malicious-looking and benign fixtures with independent trusted policy. Keep actual effect evidence separate from narrative claims and report any residual privacy or recovery uncertainty.

Keep it from recurring

  • Minimize model-visible data, enforce scoped tools and approvals, preserve provenance, and maintain privacy-safe regression evidence. Reassess the whole bundle after model, prompt, source, or policy changes. Treat injection resistance as a maintained system boundary rather than a secret prompt or one suspicious-word filter.

Official references