AI search security: keep retrieved content in the role of evidence

An AI search application reads material that your team did not necessarily write or control. That material may include ordinary facts, mistakes, misleading claims, or instructions designed to influence the application. The central security question is whether outside content can cross the boundary from evidence into authority.

This guide proposes a defensive review for a search-connected assistant. It focuses on limiting what retrieved material can cause the application to do, protecting sensitive information, and making source handling reviewable. It does not assume that a single prompt, filter, or citation mechanism can make every application safe. The appropriate controls depend on the actions and data your product exposes.

Map the trust boundaries

Draw the path from the user’s request to the final answer. Identify the search provider, retrieved documents, parsing layer, evidence packet, model, tools, and presentation layer. Mark which components are controlled by your organization and which accept outside input. Then identify where sensitive data or permissions enter the process.

A retrieved page may be useful evidence about a topic without being trusted to instruct the application. A provider response may be expected JSON without making every destination URL safe to fetch. A model output may be useful prose without being authorized to execute an action. Treat each boundary separately rather than granting trust to the entire workflow because one component is familiar.

Treat retrieved instructions as untrusted content

OWASP’s prompt injection guidance describes how malicious inputs can alter model behavior, including through content the application processes. The relevant design lesson is that outside text can attempt to influence more than the factual answer. It should not be able to redefine the user’s intent or acquire the authority of application instructions.

Keep evidence and instructions separate in your data model and in the model interface available to your implementation. Label retrieved text by source and purpose. Do not insert it into a privileged instruction field merely because it is convenient to concatenate strings. This separation is one control within a broader design, not a guarantee that the model will never respond incorrectly.

Minimize the authority available during answering

A read-only research assistant should have a read-only tool set. If the task is to explain documentation, it should not automatically receive the ability to send messages, modify files, purchase services, or run arbitrary commands. Removing unnecessary authority reduces the consequences of an incorrect interpretation of retrieved text.

Where the product genuinely needs consequential actions, separate the evidence-gathering stage from the action stage. Require a clear user instruction and an appropriate confirmation that identifies the action and its target. Do not treat a sentence found on a web page as the user’s request. Keep authorization checks in application code rather than delegating them entirely to generated prose.

Keep secrets out of the evidence path

Do not include credentials, internal tokens, or unrelated confidential records in a model’s context merely because the application can access them. Give each stage only the information needed for its task. Store privileged keys outside public static assets and avoid echoing them into diagnostic output, generated examples, or downloadable files.

Review logs and traces for the same risks as the main response. A failed request can reveal sensitive parameters, and a debugging view can expose content that the final interface hides. Define who can access detailed traces and how long they are retained. Redact or omit fields according to a documented policy rather than relying on every developer to remember which values are sensitive.

Constrain document retrieval

When an application follows result URLs, validate the destination according to the product’s threat model. A search result is not blanket permission to contact any address with the server’s network access. Restrict allowed schemes, apply appropriate network boundaries, and account for redirects and other changes between the initial URL and the final destination.

For a bounded documentation assistant, an approved source collection may be easier to manage than arbitrary browsing. Preserve the final retrieved URL and source identity. If a destination cannot be accessed safely or within the applicable permissions, mark that source unavailable and continue only within the remaining evidence. Do not let a failed fetch silently become an invented summary of a page that was never retrieved.

Handle content as data in the interface

Render untrusted text using methods that do not interpret it as executable markup. Validate URLs before creating links, and avoid taking generated HTML at face value. A model’s response is still input to your interface. It should pass through the same deliberate rendering and validation boundary as other externally influenced content.

For this site’s local demonstration, the JSON output is inserted as text rather than HTML. The examples contain no user-supplied input and make no remote requests. A live application would need a broader review of its rendering, authentication, and data flows. The security page describes the scope of this static site without presenting it as a security certification for a future product.

Make citations verifiable rather than decorative

Check that a generated citation refers to a source the application actually retrieved and that the cited passage supports the adjacent claim. Do not allow the model to invent source identifiers or substitute a familiar-looking URL. Keep source identifiers stable through retrieval, generation, validation, and display.

A valid citation does not make a source trustworthy or an interpretation correct. A source can itself contain an error, and a passage can be taken out of context. Preserve enough surrounding information for a reviewer to inspect the claim. Where sources conflict, represent the conflict rather than selecting one silently because it produces a cleaner answer.

Build defensive evaluation cases

Create a test collection that includes irrelevant instructions embedded in otherwise relevant documents, conflicting sources, malformed metadata, unexpected URLs, and requests that exceed the assistant’s authorized scope. The expected behavior should be written as an observable requirement: preserve the task, refuse unauthorized actions, avoid disclosing secrets, and identify insufficient evidence.

Use safe test fixtures rather than directing uncontrolled tests at third-party systems. Review the full application behavior, not only the final answer. An answer may look harmless while a tool call attempted an inappropriate action earlier in the workflow. Record the system version, test input, allowed tools, observed actions, and outcome so that regressions can be reproduced and corrected.

Establish an incident and correction path

Give users a way to report an unsupported answer or unsafe behavior without needing to expose sensitive information publicly. Identify who reviews the report, how the relevant evidence is preserved, and when affected functionality should be paused. A bounded system should have a deliberate stop mechanism, especially when it can perform actions beyond generating text.

Keep a correction log that distinguishes source errors, retrieval mistakes, model interpretation errors, and authorization failures. Each category suggests a different remedy. Updating a prompt may not fix an overly broad tool permission, and changing the source collection may not fix unsafe rendering. Investigate the boundary that failed rather than applying the same generic response to every incident.

Security is an application property

A search-connected model is only one component of the product. Its safety depends on source handling, tool permissions, secret management, rendering, evaluation, and operational ownership. No single instruction should be treated as a replacement for those controls.

Start with the narrowest useful scope and expand authority only when the task requires it and the controls are reviewable. Keep outside content in the role of evidence, not permission. For the data structure behind that boundary, read the LLM grounding guide and inspect the developer examples before designing a live integration.