SEAG の論文では、RAG クエリが外部 LLM に到達する前に機密エンティティのエイリアシングを提案しています

何が起こったのか

Five researchers posted a preprint describing SEAG, a framework that uses a small local model to find sensitive entities in a RAG pipeline, replace them with aliases, and forward only the disguised text to an external large language model. The authors report their own evaluation results on two datasets they built.

A preprint submitted on 13 August 2026 and listed as arXiv:2608.12675 describes the Sensitive Entity Alias Generator, or SEAG, a framework intended to let users send queries to powerful third-party language models without disclosing confidential details contained in those queries or in the documents retrieved to answer them. The listed authors are Saleh Almohaimeed, Saad Almohaimeed, Mousa Jari, Fahad Alotaibi and Khalid A. Alobaid. The paper is filed under Artificial Intelligence with a secondary listing in Cryptography and Security, and the submission comments state it has been submitted to the Knowledge-Based Systems journal. It has not been peer reviewed.

The authors frame the problem as one that existing RAG privacy research has largely skipped. That research, they write, has concentrated on preventing unauthorized users from reaching sensitive data in the first place. Their concern is the opposite end of the pipeline: in a retrieval-augmented setup where generation is performed by an external provider, both the user's question and the retrieved passages are transmitted to that provider, and may contain confidential information that could be misused or accessed for unintended purposes. The abstract does not name any provider or describe a specific incident.

SEAG's described mechanism is a lightweight model that runs before the external call. According to the abstract, it locates sensitive entities, generates a corresponding alias for each one, and assembles an entity replacement table. That table is then applied to substitute sensitive words in both the user's query and the retrieved documents before anything is forwarded to the external generator. The abstract does not spell out how the answer is restored to its original terms for the user, though the framework's stated goal of returning a correct response implies a reverse mapping step.

To evaluate the approach, the authors say they constructed two datasets: one used to fine-tune SEAG models so they produce entity replacement tables, and a second used to evaluate the framework end to end. Their headline result is expressed through what they call the User metric, which they define as the model's ability to give the user a correct response while keeping sensitive information hidden from the external generator. On that metric, the abstract states, all SEAG models achieved over 80% accuracy. No baseline comparison, dataset size, domain or language is given in the abstract.

A separate analysis measured whether the models could hide every sensitive entity in a given document. Here the abstract reports total accuracies of 77.83% for Qwen-3, 76.73% for LLaMA-3.2 and 74.91% for Phi-4, describing the outcome as good performance. The abstract does not state whether these figures are computed per document or per entity, nor how sensitivity was defined and labeled when the evaluation data was built. Every number above is the authors' own reported result; none has been independently reproduced, and the arXiv listing page does not indicate that code or the two datasets have been released.

ソースの詳細: arxiv.org ↗

なぜそれが重要なのか

Most published RAG privacy work addresses who may retrieve sensitive documents. This paper targets a different exposure: the retrieved text and the user's query are handed to whichever third-party model generates the answer. That is a routine, contractually managed part of enterprise AI deployments, and a technical mitigation at that boundary is a distinct approach from access control alone.

The exposure the paper describes is ordinary rather than exotic. Organizations that connect internal document stores to a hosted frontier model send chunks of those documents to the provider every time a question is asked. That transfer is usually governed by contracts, data processing terms and retention settings rather than by anything in the pipeline itself. A technique that strips identifying detail before the request leaves the perimeter addresses the same risk from a different direction, and does so in a way a customer can implement without the provider's cooperation.

Aliasing is also a meaningfully different design choice from redaction. Blanking out a name removes the information the model needs to reason about relationships between entities across several retrieved passages. Substituting a consistent placeholder keeps the grammatical and referential structure of the text intact, so the external model can still follow who did what, then the user's side maps the answer back. That is the argument for the approach; the cost is that the disguised text still carries surrounding context, which is exactly the material an attentive reader could use to guess what was hidden.

The reported concealment rates set the practical ceiling on how this could be used today. Between roughly a fifth and a quarter of cases, depending on the model, did not meet the bar of hiding every sensitive entity. In regulated settings such as health records, legal files or financial data, a single leaked identifier can constitute the disclosure that compliance regimes are written to prevent, so a figure in the mid-to-high seventies supports use as one layer among several rather than as a standalone guarantee. The paper's own framing is a research result, not a deployment recommendation.

More broadly, the paper is part of a visible shift in which the model provider itself is treated as part of the threat surface, alongside better-established work on retrieval access control and prompt injection. It also fits a pattern worth tracking on cost grounds: using a small, locally run model as a privacy shim in front of a large external one. If that pattern works, it changes the calculus for organizations that had assumed sensitive workloads must either stay entirely on self-hosted models or be sent out in full.

次に見るべきもの

Whether the reported numbers survive peer review at the journal the paper was submitted to, whether the two constructed datasets and any code are released, and whether the framework is tested against an adversarial external model that actively tries to re-identify aliased entities rather than one that simply answers the question.

The first thing to watch is peer review. The submission note says the paper has been sent to Knowledge-Based Systems, so reviewers will have the chance to probe how the two datasets were built, how sensitive entities were labeled, and whether the reported accuracies hold up under a stricter definition. Release of the datasets and any implementation code would matter as much, since neither the User metric nor the full-concealment measure can be independently checked without them.

The second is adversarial evaluation. The abstract reports how often SEAG hides entities from an external generator that is presumably just answering the question. It does not report what happens when that generator, or someone with access to its logs, actively tries to re-identify the aliases — through surrounding context, correlation across multiple queries from the same user, distinctive document structure, or knowledge of the underlying corpus. Accuracy under cooperative conditions and resistance under attack are separate properties.

Third is the practical overhead and the failure modes. Running an entity-detection and substitution pass before every external call adds latency and compute, and the abstract gives no measurements for either. It is also unclear how often aliasing degrades the external model's answer quality, how de-aliasing errors manifest when an alias collides with real text, and whether the results generalize beyond whatever domains and languages the constructed datasets cover.

Finally, watch for uptake. If aliasing gateways appear in enterprise AI middleware or in vendors' own privacy tooling, that would signal the approach is workable outside a research setting. The related question is how auditors and regulators treat pseudonymization applied at the API boundary — whether disguised text sent to a third party is judged materially different from the original, and at what measured concealment rate that judgment changes.

関連ガイドとクイズ