Yes, an assistant can be designed to answer from SharePoint without exposing restricted documents to everyone. The practical decision is whether your chosen experience respects each signed-in person's access throughout the answer. Audit a small library, test identical questions as different staff roles, and inspect both the response and its sources before trusting it with sensitive knowledge.
For a South African business considering custom AI agents, the useful first output is a permission-aware knowledge pilot: a bounded collection, an agreed access map and recorded evidence of what each test user could see.
What the September announcement establishes
On 25 September 2026, Microsoft announced that Copilot in SharePoint had reached general availability, with worldwide rollout starting on 30 September. The same announcement described Copilot Search answers drawn from supported content users are authorised to access, while identifying that search rollout as Frontier Public. These are distinct statements about different experiences. Source: Microsoft's September SharePoint announcement
Before deployment, your administrator should check current tenant availability, account and plan eligibility, regional applicability and the exact experience being enabled. A dated announcement cannot establish those details for your business today.
Also separate permission protection from answer quality. A response might use only permitted documents yet misread them. Conversely, an accurate answer can still be unacceptable if it reveals information the reader should not receive. Your pilot must test both.
Audit intended access against actual access
Choose a small library supporting a concrete task, such as finding equipment-return instructions. Avoid starting with the whole company knowledge base: permission disagreements become harder to isolate when everything is included.
For each document, record its owner, intended audience, source location and actual access for your test users. Ask the owner to confirm the intended audience before treating existing access as correct. An old sharing arrangement is evidence to investigate, rather than permission to broaden the assistant's audience.
Inspect how access is obtained: site or library membership, inherited access, document-specific exceptions and sharing links. Check whether someone outside the intended group can open a file directly. If they can, correct the underlying access before testing AI answers; an assistant cannot repair an overly broad audience merely by receiving a restrictive instruction.
Use distinct signed-in accounts representing ordinary staff, a relevant manager and a restricted-document owner. Keep the administrator account for configuration checks. Its successful answers do not demonstrate what an ordinary employee can safely receive.
Check the whole answer path
For the pilot, propose this rule: information must be authorised before it reaches the model, and every displayed answer, citation and attachment must remain suitable for the requesting user. Do not retrieve everything first and rely on the assistant to hide sensitive passages afterwards.
With a custom integration, ask the implementer where identity is verified, where access is checked and what happens when that check fails. OpenAI's function-calling documentation describes the application executing a model-requested function and returning its output. Connecting a retrieval function therefore still leaves the application responsible for deciding what data it returns. Source: OpenAI function-calling documentation
If a proposed design copies SharePoint extracts into PostgreSQL, require a separate explanation of how copied records retain their access boundaries. PostgreSQL supports per-user row security policies, but its documentation identifies important bypasses, including superusers and roles with BYPASSRLS; table owners normally bypass them too. Database protection must be configured and tested for the actual querying role. It does not automatically reproduce SharePoint permissions. Source: PostgreSQL row security documentation
These are implementation questions for a proposed workflow, not claims that SharePoint provides this custom architecture. The custom AI agent glossary explains the broader concept, while AI agents versus automation helps decide whether conversational retrieval is necessary.
Reusable permission-aware pilot checklist
Use the following checklist as your pilot brief. Its acceptance rules are proposed operating rules, not a vendor certification or legal standard.
- Name the pilot library, business question, document owner and technical owner.
- Confirm current product experience, tenant availability, account/plan eligibility and regional applicability.
- Record each document's intended audience, actual access and any sharing exceptions.
- Select separate ordinary-staff, manager and restricted-owner test accounts.
- Verify direct document access for each account before testing the assistant.
- Prepare synthetic restricted facts so leakage tests do not require real confidential information.
- Ask every account the same ordinary, restricted, missing and duplicate-document questions.
- Inspect answers, source titles, links, snippets and follow-up responses for unauthorised disclosure.
- Confirm allowed answers cite accessible evidence and do not invent missing details.
- Remove a test user's access, then test new questions and existing conversation behaviour.
- Record question, account, expected result, actual result, citations, time and reviewer decision in a restricted test record.
- Stop expansion if restricted information appears or an access check cannot be verified.
- Assign each failure to the document owner or technical owner, correct it and repeat affected tests.
- Obtain the business owner's decision to expand, narrow or pause the pilot using the recorded evidence.
A completed checklist should explain why the scope is acceptable, including unresolved limitations. Tick marks without recorded results are insufficient.
Work through ordinary and difficult cases
All names, documents and access arrangements below are hypothetical. Use synthetic content for your own tests and have the document owner approve expected outcomes beforehand.
Ordinary question: Lerato, an ordinary staff member, asks where to return a company laptop. The approved equipment guide is available to all staff. Expected handling: give the return steps supported by that guide and cite the accessible file. The reviewer opens the citation using Lerato's account and checks that the answer added no unsupported instructions.
Restricted question: The same library contains a manager-only investigation note with a synthetic incident code. Lerato asks for a summary of all laptop incidents. Expected handling: answer only from permitted material, without revealing the restricted code, note title or its contents. A manager with intended access can receive a separately verified answer. If Lerato receives restricted details, pause the pilot and investigate retrieval, permissions and any stored conversation content.
Missing information: A staff member asks who arranges collections from a satellite office, but the permitted guide does not say. Expected handling: state that the available material does not answer that point and direct the person to the agreed equipment contact. The owner decides whether to update the guide. The assistant should not invent a contact or promise a collection.
Ambiguous question: “Can I keep the laptop?” could mean retaining it during leave or buying it after departure. Expected handling: ask which situation the person means before searching further. Any purchasing or employment decision remains with the appropriate human decision-maker.
Duplicate documents: Two accessible equipment guides give different return locations, and neither is clearly approved. Expected handling: flag conflicting instructions, cite both accessible sources and refer the location question to the owner. Do not silently choose the newer-looking filename. If one conflicting document is restricted, the response must not reveal it to the ordinary user; an authorised reviewer resolves the conflict separately.
Test changed access before expanding
Include a permission-change test rather than stopping after initial success. Remove a test account's access to synthetic restricted content, then ask a fresh question and revisit a conversation that previously used it. Record when access changed and when each test ran.
Ask the technical owner to explain expected behaviour for retrieved copies, cached answers and conversation history. Do not assume a new access restriction removes text already displayed. Decide whether the pilot needs restricted history, shorter retention or a narrower initial scope based on the verified design.
Keep test records restricted because they may reproduce the information being tested. Share a sanitised outcome with the business owner: what passed, what failed and what remains unresolved. For a wider AI automation programme, these findings should determine which knowledge workflows are ready to proceed.
FAQ: SharePoint permission testing
Is hiding the citation enough to protect a restricted document?
No. The answer may still disclose its facts through a summary, comparison or follow-up. Test the complete response. A blocked link does not make disclosed content acceptable.
Should we give everyone access so the assistant answers more questions?
Only change access when the document owner approves the underlying business need. Treat unanswered questions as coverage gaps to review. Do not broaden sensitive access simply to improve answer completeness.
What should we do when a restricted answer appears during testing?
Pause the affected pilot, restrict the test record and ask the technical owner to trace the disclosure. Correct the cause and repeat the failing question across relevant accounts before expansion.
If your business needs help planning this small-library test, get in touch about custom AI agents. The custom AI agent workflow guide provides context for discussing retrieval, human handling and the evidence needed before a wider rollout.