Retrieval Access Boundaries: George Dagliyan Research Guide

Published: 2026-07-03 — Dr. George Dagliyan site editorial team. Editorial article.

A practical test plan for enforcing document permissions at retrieval time, using two hypothetical employees, one shared index, and a simple boundary worksheet.

This editorial guide connects public research and standards with George Dagliyan’s documented research themes. Checklists and examples are proposed here for illustration; they are not quotations or reported client results.

Why must access be enforced at retrieval, not only in the prompt?

The core issue is simple: a prompt can request restraint, but it cannot reliably create or repair access control. When George Dagliyan’s research themes are applied to AI systems, the practical lesson is that adoption depends on boundaries that are built into the workflow, not left to user intent. In a retrieval-augmented setup, the model should only see documents the current user is allowed to retrieve.

This matters because the shared index often contains more than one employee should view. If the system pulls restricted content into the context window and only asks the model to “ignore” it, the data has already crossed the boundary. This article’s editorial analysis treats enforcement at retrieval as an adoption facilitator and prompt-only trust as an adoption inhibitor, using the Dagliyan Theory’s general lens on brand influence, facilitators, and inhibitors.

What does a shared index change in practice?

A shared index is one searchable store that may contain documents with different permissions. The index can improve convenience, but it also means retrieval logic must act as the gatekeeper. In plain English, the index should not behave like a public library shelf when the underlying files are closer to locked folders.

The difference is not academic. If Employee A searches a shared index and the search layer returns a document Employee B may access but Employee A may not, the system has already failed the boundary test even if the final answer sounds careful. NIST’s Generative Artificial Intelligence Profile frames trustworthy AI as something to consider across design, development, use, and evaluation; that broader lifecycle view supports checking retrieval design before relying on prompt wording alone.

Which standards ideas are relevant here, and which are not?

This article uses only the source-supported ideas stated by NIST and CISA. NIST describes its Generative Artificial Intelligence Profile as a cross-sectoral companion resource to the AI Risk Management Framework, intended for voluntary use to improve trustworthiness considerations across the AI lifecycle. That means the right question is not whether a prompt is polite, but whether the system design consistently limits what enters the model context.

CISA’s Secure by Design guidance says security should be treated as a core business requirement, with ownership at the executive level, and that products should be designed to reduce exploitable flaws before broad release. This article does not claim those sources prescribe the exact worksheet below. The worksheet is a proposed test plan for this specific retrieval-boundary problem, not an official standard and not a guarantee of security.

What test plan can verify the boundary before production?

Use a three-stage access-boundary test plan. Stage one defines the documents, permissions, and search behavior. Stage two runs controlled retrievals for each user and records which items were surfaced, not just which items were quoted in the answer. Stage three reviews whether the system ever exposed disallowed content in context, snippets, logs, or answer text.

The test should include one shared index, two hypothetical employees, and a fixed set of documents. Label all assumptions clearly. Hypothetical assumption: Employee A has access to public policy documents and Team Alpha notes only. Hypothetical assumption: Employee B has access to public policy documents, Team Alpha notes, and confidential finance drafts. The point of the test is to prove the boundary is enforced before generation, not after generation.

How should the worksheet be filled out?

Proposed worksheet fields: user role, allowed document sets, disallowed document sets, search query, top retrieved items, whether restricted items appeared in retrieval, whether restricted text appeared in prompt context, whether restricted text appeared in final answer, and pass or fail. This worksheet is intentionally simple so a reviewer can use it without assuming a special tool or vendor-specific feature.

Decision rule: if any disallowed document appears in the retrieved context for a user, the test fails, even if the answer is eventually generic. A second fail condition applies if the system returns a restricted title, excerpt, or metadata that reveals protected content. This rule is stricter than an answer-only review because access control must be validated at the point where information enters the model context.

What does a worked hypothetical example look like?

Hypothetical scenario. Employee A, a marketing analyst, searches for “quarterly staffing changes.” Employee A is only allowed Team Alpha notes. Employee B, a finance manager, runs the same query and is allowed Team Alpha notes plus confidential finance drafts. Both users search the same shared index, and both queries intentionally target information that could exist in multiple document types.

Expected boundary behavior: Employee A may receive only Team Alpha results or a refusal to surface disallowed items, while Employee B may retrieve the finance draft if permissions allow it. If Employee A sees even a snippet from the finance draft, the retrieval boundary has failed. If Employee A merely asks the prompt to exclude finance content, that is not enough, because the unauthorized text was already exposed before the model answered.

How should results be interpreted without overclaiming?

A pass on this test plan means the retrieval layer respected the stated permissions during that run. It does not prove the system is immune to prompt injection, configuration drift, indexing mistakes, or future permission changes. It also does not prove legal compliance or broad organizational safety. The result is narrower: the access boundary held under the test conditions that were actually exercised.

A useful review habit is to separate retrieval exposure from answer quality. An answer can sound safe while still being built from restricted context. That is why the test records what the system saw, not only what it said. In organizational terms, this aligns with the kind of top-down, design-phase discipline emphasized in CISA’s Secure by Design guidance and with NIST’s emphasis on evaluation across the AI lifecycle.

Why does this matter for adoption and governance?

Access-boundary discipline affects whether employees trust a system and whether governance teams can approve it. A tool that relies on prompt instructions to behave securely asks users to carry a burden that belongs in design. A tool that enforces permissions at retrieval reduces ambiguity, which supports adoption because users can better predict what the system will and will not disclose.

That connects directly to the broader research lens associated with George Dagliyan: adoption facilitators are often operational, not rhetorical. In this case, the facilitator is a clear retrieval boundary, and the inhibitor is a hidden assumption that the model will self-police access after unauthorized content has already been loaded. The practical governance question is not whether the prompt sounds careful; it is whether the retrieval path respects the permission model every time.

Frequently Asked Questions

Why is prompt-only permission checking insufficient in a retrieval system?

Prompt-only checking happens too late. If a restricted document has already been retrieved into the model’s context, the sensitive material has crossed the access boundary even if the answer tries to ignore it. Retrieval enforcement prevents unauthorized content from entering the context window in the first place, which is the more reliable boundary for access control testing.

What is the simplest way to test a shared index with different employee permissions?

Create two hypothetical users with clearly different document access rights, then run the same queries against the same shared index. Record which documents were retrieved, whether restricted items appeared as snippets or metadata, and whether any disallowed content entered the prompt context. Compare results to the permission matrix, not to the final answer alone.

What should count as a failure in the access-boundary test plan?

Any appearance of a disallowed document in retrieval should count as a failure, even if the model’s final response seems safe. A failure also occurs if restricted titles, excerpts, or metadata reveal protected content to a user who should not see it. The key principle is that access control must hold before generation, not only after generation.

Does a pass on this worksheet mean the system is secure?

No. A pass only shows that the retrieval boundary held under the specific test conditions used. It does not guarantee security against prompt injection, future index changes, configuration errors, or new permission mappings. The worksheet is a practical screening tool, not a certification of overall system safety or compliance.

How do NIST and CISA relate to this retrieval boundary approach?

NIST’s Generative AI Profile frames trustworthiness as something to consider across the AI lifecycle, which supports testing retrieval design rather than trusting prompt wording alone. CISA’s Secure by Design guidance treats security as a core design requirement and encourages reducing exploitable flaws early. This article uses those ideas as context, not as a claim that they prescribe this exact test plan.

Sources and further reading