Research teams often work across departments, institutions and external partners. That makes collaboration valuable and access decisions specific. A paper may be public while the supporting working files remain restricted. A collaborator may participate in one project without being entitled to inspect another. An AI assistant that retrieves across these collections must preserve those distinctions throughout the answer process.
The question is broader than where the model runs. A privately hosted model can still receive context that the requesting person should not see. Conversely, a well-designed access policy is ineffective if indexing, caching or exports ignore it. Define the complete route from the source repository to the final answer, then test the boundaries at each step with representative research roles.
Step 1
Model access around resources and roles
List the collections in scope, their owners and the rules that govern access. Include project membership, partner access, publication status and any time-limited permissions. Distinguish permission to discover that a record exists from permission to read its content. Even a title, filename or result count can reveal information if the collection itself is sensitive. Make those decisions explicit with the responsible institutional teams.
NIST's Zero Trust Architecture describes an approach focused on resources and authorization rather than implicit trust in a network location. For research retrieval, a practical consequence is that being inside an institutional network should not automatically grant access to every indexed project. Resolve the requesting identity and its applicable permissions before restricted content is made available to the model or presented in a result.
Step 2
Follow permissions through derived information
A document can produce extracted fields, embeddings, summaries and cached answers. Each derived object needs an access policy consistent with the information it contains. A summary may reveal the same sensitive finding as the original report. Treating it as harmless because it is shorter creates a second route around the repository's controls. Record the source relationships needed to determine the appropriate boundary.
Plan what happens when a person leaves a project or a record changes status. Permissions and derived indexes need an update process with observable results. Review logs and operational exports as well: they may contain retrieved passages or prompts. Give administrators enough information to diagnose failures without assuming that everyone operating the service should have unrestricted access to research content.
Step 3
Test both permitted and denied questions
Construct a test matrix with actual role categories rather than only an administrator account. Ask the same question as a project member, an unrelated researcher and an external collaborator. Verify the retrieved evidence, the answer, the citations and any downloadable output. Include indirect questions that could expose restricted findings through comparisons or summaries, not just requests for a named confidential file.
Repeat the tests after changing membership, removing a source or changing its classification. An answer that correctly refuses access today is not evidence that revocation will work tomorrow. Keep an accountable owner for the test suite and for exceptions. Document which safeguards belong to the repository, the retrieval service and the model runtime so a change in one component does not leave an unowned gap.
How sDEN approaches it
Connected knowledge. Inspectable evidence.
Apply these principles to a defined collection and a practical decision.
Within this scope
An approved environment
sDEN supports private models on premise, in a private cloud or in a hybrid setup. Institutions define the environment and processing choices as part of the deployment boundary.
Within this scope
Governed context
A governed knowledge graph connects records while retaining their source relationships. Access rules follow the data so private AI retrieves context appropriate to the requesting user.
Within this scope
Operational ownership
The configuration, documentation and skills to operate the system belong with the institution. Explicit administration choices make ownership practical after the initial delivery.
A useful first delivery
What your team should be able to use
The deliverable should include a working retrieval service and evidence that its access rules behave as intended: a role matrix, representative allowed and denied questions, revocation checks and named operational owners. Researchers gain a useful path to permitted knowledge. The institution gains a clear account of where sensitive information travels and which controls must be maintained as projects and memberships change.
Questions
Institutions & research, answered.
Does private hosting solve access control?
Private hosting defines part of the processing boundary. It does not replace authorization inside the service. Retrieval, derived records, logs and exports still need appropriate access rules.
Can an assistant answer from public and restricted research together?
Yes, when the requesting user is authorized for all retrieved material. Results must preserve source status and permissions, including when the answer combines information from several collections.
Sources
