kakinang INSIGHTS · 2026-10-07
How can new staff find internal documents without exposing them to visitors?
A new colleague may need handoff notes, service rules and prior decisions at the same time. Making documents searchable can reduce hunting, but uploading a file does not make it private. Decide who the material is for, which signed-in role can use it, which assistant can cite it and who updates it. AI I want new staff to find internal guidance while keeping public and internal information separate. can help locate supported guidance; it cannot replace the access policy.
Decide who each document serves
Classify content by use and audience, not just filename. A public service description, an employee-only handling procedure, a customer case with personal details, and a contract need different readers. A new agent asking how to assess a return may need the rule and checklist, not another customer's phone number. Start with the twenty questions a newcomer is most likely to ask during the first three weeks. For each, note the current source, its owner and whether it is still in force. That is easier to check than importing an entire shared drive at once.
Microsoft's SharePoint search guidance explains that results are trimmed by the user's permissions. Treat this as a general design lesson; it does not mean kakinang automatically inherits SharePoint's per-file permissions. NIST defines least privilege as granting a person or a process only the access necessary for the task. Separate “can locate a document” from “can read its contents”. When AI retrieval is involved, inspect the answer for restricted excerpts as well as checking whether a file URL is hidden. A search result title and an answer paragraph can each disclose something.
A small inventory can list document name, purpose, public or internal status, allowed role, maintainer, effective date and review date. If the 2024 and 2026 pricing policies both appear, a new employee should not have to guess; the owner must designate the effective version and exceptions. Check redistribution rights for supplier documents. Teams often treat “stored in the console” as a complete protection, but the public assistant and signed-in staff may reach different knowledge paths. Follow the real entry points when evaluating exposure.
Separate signed-in knowledge checks from public answers
kakinang's console can hold extracted document knowledge and a signed-in knowledge question test for authorised roles. First upload curated files, inspect extracted text, then test the questions a newcomer actually asks, such as who can approve a non-standard delivery. If an answer omits a condition, improve the source heading, section and version rather than endlessly rephrasing the test prompt. Public FAQ and service knowledge used by a website assistant should have a separate approval decision so visitors receive only publishable content.
The critical check is which knowledge base a public agent is bound to. A file called “internal”, or a knowledge toggle, does not authenticate a person. The public agent is accessible from a visitor-facing conversation; its AgentPublicKey is not employee sign-in. Do not bind internal documents to that agent. Use the signed-in, role-restricted console test for internal questions. Website or IP restrictions apply only to the entry points and scope for which they are configured; they are not individual staff permissions. Ask the same question in an unauthenticated browser, a normal staff account and an administrator account before publication.
Authorised people do not all need every file. Assign console roles by job and distinguish content maintenance from routine consultation. Remove an account or role when someone changes responsibilities or leaves. De-identify customer examples used for training; where that is not possible, keep original cases in the authorised business system. Also test untrusted instructions inside uploaded files: a document is data, not an instruction to ignore rules or reveal other sources. A knowledge test should expose a misleading answer, not be taken as proof that the source is safe.
NIST Computer Security Resource Center
Use first-week questions as acceptance checks
Imagine a new service employee starting on Monday and asking when an expedited delivery requires manager approval. The owner prepares an approved short document naming applicable order types, checks to perform, the approval route and the dates that cannot be promised. In the signed-in workspace, the answer should state those conditions and the responsible person. If information is missing, it should say what must be checked rather than guaranteeing an early delivery. This is a hypothetical workflow, not a claim that the product creates a manager approval process.
Ask the same question through the public website assistant. A visitor may receive the published delivery policy and contact route, but must not see the internal approver list, private phone numbers or discount terms. If restricted details appear, stop the relevant public knowledge binding, identify the source and configuration, and test again. Making the phrasing vaguer leaves the information within reach. If a staff answer uses an obsolete rule, the document owner should correct the version and verify the indexed answer.
Keep ten real but de-identified newcomer questions from the first week. Record the expected source, actual answer, need for human judgement and person responsible for correction. Include routine questions, missing documents, conflicting versions and a question that should never receive an internal answer publicly. Repeat the checks after price or process changes. The acceptance record should also note the cited version, omitted conditions, accidental exposure of a manager's contact details and the handoff for human judgement. In a hypothetical sample, three outdated answers among ten questions indicate a version-control problem; a retrievable document with a wrong answer may instead mix exceptions into the general rule. These figures illustrate diagnosis, not actual product results. If staff still ask the same thing in chat, first inspect whether the document states conditions and responsibility clearly. If a public visitor sees internal content, fix the access boundary first. Findability and confidentiality are both acceptance criteria.
Questions teams ask
Does marking a knowledge base internal stop public answers?
A name or toggle is not a security boundary. Check which knowledge sources the public agent uses and what an unauthenticated visitor can actually retrieve. Keep internal sources in a signed-in, role-controlled workspace and retest as a visitor after any configuration change.
Do new staff need company accounts?
The project's console knowledge test requires sign-in and role access. An administrator should issue suitable accounts and remove access when a person moves or leaves. Do not assume employee SSO or a separate private chat entrance is already supplied; confirm those needs separately.
What should happen when a file changes?
Assign an owner, update the source, inspect processing status and test actual answers before treating a new version as effective. Remove or isolate superseded prices and conflicting procedures. Uploading a new PDF alone does not prove every response has changed.
Can identifiable customer conversations become training documents?
First check purpose, permissions and retention. Remove unnecessary names, numbers and identifiers; write a de-identified procedure when possible. If original records are needed, manage them through an authorised business-data workflow rather than a general training search index.
Sources and further reading
- Enable content on a site to be searchable — Microsoft Learn
- Least privilege — NIST Computer Security Resource Center