One assistant answers questions for anyone on the internet. The other works with private company information. Treating them as the same system can create serious security and accuracy problems.
A business may want two apparently similar AI tools.
Customers visiting its website need quick answers about services, locations, hours, warranties or appointment policies. Employees need answers about internal procedures, pricing exceptions, HR policies, customer problems and management approvals.
Both tools may use a chat window. Both may be built with Microsoft Copilot Studio. Both may answer questions in ordinary language.
That does not mean they should use the same knowledge sources.
A public website chatbot and an internal employee assistant serve different audiences, operate under different identity rules and require different information boundaries. Connecting both to one large collection of company documents can expose confidential information, confuse public and internal guidance and make the system difficult to govern.
A Public Visitor Has No Employee Identity
An internal assistant usually knows who is asking the question.
An employee signs in through Microsoft 365, Teams or another authenticated channel. The system can use that identity, along with Microsoft Entra ID groups and SharePoint permissions, to determine which sources the employee may access.
A finance employee may be able to retrieve accounting procedures that a field technician cannot. A manager may see escalation guidance that is unavailable to a contractor. HR information can remain restricted to the appropriate group.
A public website visitor is different. Unless the website requires authentication, the chatbot does not know whether the person is a customer, competitor, former employee, vendor or automated attacker.
Microsoft’s Copilot Studio authentication guidance explains that when an agent is configured with no authentication, anyone who has or discovers the link can chat with it. The organization cannot use employee identity to decide which internal information that visitor should receive.
That makes the knowledge source—not merely the chatbot’s instructions—the primary security boundary.
Public Knowledge Should Be Deliberately Public
A public chatbot should normally answer from a separate collection of approved public information.
That collection might include:
- Published service descriptions
- Business hours and locations
- Public FAQs
- Warranty explanations
- Appointment instructions
- Public application requirements
- Published policies
- Case studies
- Contact information
The key word is approved. Information should not become public simply because it is stored in a folder the chatbot can reach.
Microsoft allows organizations to add a public website as a Copilot Studio knowledge source. This can be appropriate when the site already contains the information the organization wants customers to receive.
A curated public document library may also be used, but it should contain only information that has been reviewed for anonymous access. Internal comments, draft prices, employee contact details, unpublished service plans and customer-specific records do not belong in that collection.
Internal Assistants Need Authentication and Permissions
An internal employee assistant serves a different purpose.
It may answer questions such as:
“Who can approve this refund?”
“What procedure applies when equipment fails?”
“Which form should I use for this incident?”
“How should this customer complaint be escalated?”
These answers may depend on department, location, role or management level. The assistant therefore needs authenticated users and carefully organized permissions.
Microsoft’s SharePoint knowledge-source documentation states that Copilot Studio normally uses Microsoft authentication when accessing SharePoint knowledge through Teams, Power Apps or Microsoft 365 Copilot.
Authentication alone, however, does not repair poor access controls. A document that is accidentally shared with the entire company may still be available to every authenticated employee. Internal implementations must review SharePoint permissions, security groups, inherited access and overshared sites before launch.
AskMaisy’s Microsoft Knowledge Hub implementation guide describes this architecture as a governed information system in which SharePoint stores approved knowledge, Entra ID establishes identity and Microsoft 365 groups control access. The agent is the retrieval layer—not the security strategy.
One Shared Repository Creates Avoidable Risk
Some organizations attempt to place public FAQs, employee procedures, HR material and management guidance into one repository and rely on prompts to tell the chatbot what not to reveal.
That is a weak control.
Instructions such as “do not share confidential information” may influence an agent’s behavior, but they are not a substitute for isolating sensitive sources and enforcing permissions. OWASP identifies sensitive-information disclosure and prompt injection among the major risks affecting large-language-model applications.
A malicious visitor may repeatedly rephrase a question, request hidden context or attempt to manipulate the agent’s instructions. Even without an attack, the assistant may combine internal and public material in an unexpected way.
The safer design is to prevent the public agent from reaching private information in the first place.
Authenticated Customer Portals Are a Third Scenario
Not every external assistant must be fully public.
A customer portal may require users to sign in before asking about their own account, project or support history. This creates a third architecture: an external but authenticated agent.
Such a system may use customer identity, controlled APIs or carefully secured data connections. It still should not receive unrestricted access to the employee knowledge hub. Customer access must be designed around the exact records and actions each authenticated user is allowed to reach.
This is more complex than publishing a general FAQ chatbot and should be treated as a separate security project.
Test the Boundaries, Not Just the Good Answers
Organizations often test whether a chatbot answers expected questions correctly. They should also test what happens when users ask for information they should not receive.
Public-agent testing should include requests for employee names, internal prices, unpublished procedures, system instructions and confidential documents. Internal-agent testing should use representative employee accounts with different roles and permissions.
The AskMaisy approach to governed knowledge retrieval includes approved SharePoint libraries, document status, permission-aware access and testing with representative users.
A public chatbot and an internal assistant may look alike on the screen, but their trust boundaries are fundamentally different. The safest architecture does not ask one agent to remember which company secrets to withhold. It gives each agent only the knowledge its audience is allowed to use.
