A workplace assistant can quote the right sentence and still fail the person asking. The source may belong to a restricted department, describe a retired procedure, or have lost its owner. A convincing citation does not resolve any of those problems.
For an internal knowledge manager, the first design decision is therefore the retrieval boundary: which approved document revisions may this person use now? The answer interface comes later. This is a proposed implementation guide, with synthetic records and evaluation scenarios, not a delivered enterprise system or a report of customer results.
Define the first corpus and its owner
Begin with a small collection of approved, low-sensitivity operating policies: room booking, equipment requests or publishing guidelines. Keep HR files, credentials, customer records and private correspondence outside this first scope. Name a document owner who can approve ingestion, correct content and retire it. “Available on the network” is not an approval state.
The NIST Generative AI Profile provides voluntary, cross-sector risk-management considerations across design, development, use and evaluation. That is a reason to establish an evaluation and ownership process; it is not a certification of the architecture proposed here. The access controls and tests below are engineering proposals that need implementation and review.
Preserve the document contract before making chunks
A connector should bring both content and the information needed to decide its use. Indexing text while dropping its permission model creates a second, less controlled document store. Keep source identity stable while revisions and access policies change.
| Proposed field | Why it travels with the content |
|---|---|
| document_id, source_uri | Stable identity and a route to the authoritative source |
| revision, superseded_by | Distinguish current content from a replaced version |
| owner | Responsible person or team for correction and retirement |
| acl_version | Revision of the source access policy, not a list inferred by the model |
| effective_from, review_due | When the policy applies and when its owner must review it |
| ingestion_time | When this system observed the source; not proof it is still current |
Store chunk identifiers against the document revision. Preserve heading or passage locators so a person can inspect the supporting section, not just a document title. If a connector cannot translate a source permission faithfully, keep that source out until a narrower, explicitly approved policy is possible.
W3C's PROV-Overview describes provenance through entities, activities and responsible agents. It is a non-normative overview of the PROV family. Here it informs a simple lineage record: which revision produced these chunks, through which ingestion job, with whose approval? Recording lineage does not prove that a document is true or that a requester is authorized.
Authorize retrieval, then authorize opening
An illustrative request path is:
- Authenticate the person and resolve their current organization and group memberships from the approved identity source.
- Establish the permitted document set using current access and publication state. Do not retrieve an unrestricted set and ask the model to hide forbidden passages afterward.
- Select current passages within that boundary. If none support the question, return a bounded “not found” response and the relevant owner route.
- Generate an answer restricted to the selected evidence. Show source title, revision, applicable date and passage link beside the supported statements.
- Check access again when the person opens a source. A link is a locator, not a bearer permission token.
- Treat a suggested action as a separate, reviewed workflow. A retrieval assistant should not silently modify policy or change group membership.
There is a race between authorization, generation and display. Define an access-policy epoch for the request, revalidate before returning an answer, and reject the result if its permitted sources have changed. This narrows the race but does not recall text someone already saw. Document that limit rather than promising that revocation can erase prior disclosure.
Work through a revoked-group example
Illustrative synthetic example. DOC-DEMO revision 4 is approved for the Facilities group under access revision 17. A cached answer uses two passages from it. The next access revision removes a person's group from the permitted set.
The access event should invalidate that person's cached answer and the affected retrieval entries. The source-open route must reject the request even if they kept an old URL. A worker should not continue serving revision 17 because its cache has not expired yet. If the permission-sync feed is unavailable, the agreed conservative behavior is to suspend affected retrieval rather than treat the last successful sync as permanent authorization.
Do not make caching depend only on the question text. Include the authorized context, source revisions and policy version, or avoid answer caching until the access model can support it. Shared caches are attractive for cost and latency, but require more careful invalidation than a per-request generation path.
Make stale and hostile documents visible failures
Access is only one eligibility condition. A retired procedure should not compete with its replacement because it has more matching words. Exclude superseded content from normal answers, while preserving an explicitly authorized history view if required. Decide whether a passed review date blocks use or flags it for the owner; show that policy in the interface.
Document text is data, including text that instructs the assistant to ignore its rules or reveal another file. Keep retrieved passages separate from system instructions, restrict tools and output destinations, and test adversarial documents. These measures need a threat model and independent engineering review; they are not a guarantee against prompt injection.
Observe ingestion failures by source and revision. A dashboard showing only successful jobs can conceal a policy that stopped updating. Give the source owner a queue for parsing failures, access-mapping failures and overdue reviews, with a manual lookup route when retrieval is suspended.
Evaluate permission and evidence separately
Prepare a reviewed answer set and a denied-document set before a pilot. Use fictional policies and accounts until the data-flow and authorization design is approved.
| Test fixture | Inspect before accepting the build |
|---|---|
| A user loses a permitted group during generation | Result is withheld or regenerated under the new access state; old cache is unusable |
| An old procedure is replaced | Current revision is retrieved, and old passage links are visibly historical or unavailable |
| The permitted corpus has no answer | Assistant abstains without inventing a policy |
| A document contains hostile instructions | It cannot change retrieval permissions or trigger an outbound action |
| A citation is relevant but does not support the sentence | Review records unsupported synthesis separately from retrieval relevance |
Measure cross-user disclosure attempts, citation support, abstention behavior and access/content refresh latency as separate results. Have owners agree acceptable thresholds and a stop condition before a limited pilot. A source link alone is not evidence that the answer follows from it or covers every exception. No evaluation results are claimed here.
What Remmly contributes, and what must be built
Remmly offers a personal capture-and-recall foundation. Its Ask documentation describes source-linked answers, transcript review and review of proposed library changes. The owned-product study explains those decisions and their limits. They inform the experience of inspecting evidence; they do not establish enterprise SSO, tenant isolation or document-level ACL synchronization.
Those controls, connector authorization, revocation handling, retention, injection defenses and source-owner operations are additional custom engineering. Remmly's privacy page says its backend and configured AI providers process content; it is not end-to-end encrypted. The operator setup page requires a source checkout, says the public repository and license are not announced, and requires an invitation for the optional shared media processor. The download page lists the web workspace as available and public mobile releases as forthcoming. None of these facts establishes suitability for confidential organizational records.
For a scoped build, start with an AI development discovery and discuss your source and permission model. Bring a representative approved policy, its access rules and a known failure case before choosing a model.
Sources and evidence limits
Public sources checked 5 November 2026: NIST AI 600-1 publication record, W3C PROV-Overview, and the linked Remmly product documentation. NIST is voluntary risk guidance; PROV-Overview is a non-normative provenance note. These sources inform the proposal, not proof of a completed security review, a functioning enterprise deployment or measured answer quality.