An internal AI assistant can speed up access to procedures, policies, and operational data. However, connecting it to every folder, email, and knowledge base does not make that material reliable information. The problem arises when it answers using a draft, a version that has already been replaced, or a document that the person asking should not be able to access.

The priority is not for the assistant to answer at all times, but for it to respond with authorized, current, and verifiable information. To achieve this, it is advisable to create a source admission list before launching the automation: each source must have an owner, a trust status, defined permissions, and a rule for being updated or withdrawn.

The risk is not only making up an answer

An incorrect answer does not always result from an invention by the model. It can also arise from retrieving real but inappropriate content: a historical procedure, an informal email that contradicts a policy, or restricted data from another team. In systems based on document retrieval, weaknesses in vectors and embeddings may include misaligned access controls, leaks across contexts, conflicts between sources, and contaminated content. [3]

Therefore, the scope should be defined before choosing a tool. Decide which queries the assistant can handle, which repositories are out of scope, and which actions it cannot carry out on its own. If an answer can approve, modify, or send something with an operational impact, the assistant should be limited to preparing information and referring the decision to an authorized person.

  • Treat approved and current procedures as priority sources.
  • Classify drafts, historical documents, and external material as lower-trust content, or exclude them.
  • Prevent the assistant from carrying out sensitive actions without human review.

Apply an admission list to every source

The first practical step is to inventory every folder, knowledge base, CRM, or shared mailbox that is intended to be connected. For each source, record the business owner, its purpose, the date of its last review, its status—approved, draft, historical, or external—the groups with access, and the archiving or withdrawal criterion. If no one can identify who maintains a document, it should not feed automated responses.

This classification prevents the repository from being treated as a homogeneous block. A procedure published by the responsible department can answer an operational question; a forwarded email can serve, at most, to locate context that a person validates. Hypothetical example: if a company retains two travel policies, the assistant must prioritize the one marked as current and display its version, rather than combining both to produce a new rule.

  • Assign a functional owner, not just a technical administrator.
  • Define a review date and an expiry date for critical sources.
  • Clearly separate approved content from historical, provisional, or third-party material.

Preserve permissions when retrieving documents

Permissions from the source application must accompany the content through to the search index and be applied to every query. A security filtering pattern uses the person's identity and groups to exclude unauthorized documents, but that filtering does not replace the application's overall authentication and authorization. [2]

Hiding links in the interface is not enough. Test retrieval with real, distinct profiles, for example administration, operations, and management. Ask the same question from each profile and review which documents are retrieved before generating the answer. The aim is for the assistant not to expand existing permissions or use a source that the user would not have direct access to.

  • Index user, group, and access-level metadata when needed for filtering.
  • Review joiners, leavers, and team-movement changes in source permissions.
  • Record failures found in testing and correct the permission source, not only the visible answer.

Prevent untrusted content from becoming instructions

Emails, user-uploaded files, copied web pages, and third-party documents may contain text intended to change the assistant's expected behavior. They must be treated as data to analyze, never as control instructions. OWASP recommends separating and identifying untrusted content, applying least privilege to connected tools, and requiring human approval for high-impact actions. [1]

Protection also depends on updates. A change in a document or its labels may not be reflected in an index until a new, correct indexing process has been completed. Therefore, define a synchronization frequency that matches the source's criticality and a rule for withdrawing obsolete content while it is being updated. [5]

  • Keep system instructions separate from retrieved documents.
  • Limit tools and data to what is strictly necessary for each use case.
  • Label external or user-uploaded content so that it does not compete with approved sources.

Require evidence and design an abstention path

For queries about internal processes, the answer should include a brief explanation, the name of the document or record used, and its date or version. If there is insufficient evidence, the appropriate output is to indicate that no current source has been found. This traceability allows the person to spot an old reference and enables the responsible team to correct the document source.

Before opening the assistant to the entire company, create a small, repeatable test suite: questions involving current procedures, outdated versions, conflicting sources, data that a profile should not access, and topics with no documentation. Measure whether it cites a valid source, whether that source actually supports the answer, whether it abstains when appropriate, and whether it refers sensitive cases. NIST proposes documenting human oversight and establishing repeatable testing, evaluation, verification, and validation processes. [4]

  • Display the source, version, and date when the assistant answers about a process.
  • Configure referral to a person in the event of conflicts, insufficient evidence, or sensitive information.
  • Repeat testing after relevant changes to sources, permissions, the model, or workflows.

Frequently asked questions

Does a RAG system prevent an internal assistant from using incorrect information?

Not on its own. Document retrieval can provide context, but quality depends on the admitted sources, their permissions, their currency, and evaluation of the results. It must also separate untrusted content and provide for human review in sensitive cases.

What should the assistant do if it finds two contradictory documents?

It should not select a rule based on appearance or inferred age. It must show the conflict, identify the available sources, and refer validation to the owner defined for that process. Afterwards, it is advisable to correct the classification or withdraw the source that no longer applies.

How often should the assistant's sources be reviewed?

It depends on how much each process changes and on its operational impact. At a minimum, assign each source a responsible person, a review date, and an expiry rule. Critical sources also require controlled synchronization and testing after relevant changes.

Primary sources

  1. LLM01:2025 Prompt Injection - OWASP Gen AI Security Project
  2. Security Filter Pattern - Azure AI Search | Microsoft Learn
  3. LLM08:2025 Vector and Embedding Weaknesses - OWASP Gen AI Security Project
  4. AI RMF Core - AIRC
  5. Use Indexers to Ingest Microsoft Purview Sensitivity Labels - Azure AI Search | Microsoft Learn
  6. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile | NIST