A public chatbot and an employee assistant may use similar technology, but they should not share unrestricted access to the same information.
A public website chatbot should not receive unrestricted access to an organization’s internal SharePoint Knowledge Hub.
The safer design is to give the public assistant its own approved knowledge sources containing only information intended for customers, donors, applicants or other website visitors. The internal assistant should remain behind organizational authentication and retrieve information according to each employee’s Microsoft 365 permissions.
Public and internal assistants should be treated as separate security products, even when both are built with Microsoft Copilot Studio.
Why Is a Public Chatbot Different From an Internal Assistant?
A public chatbot is available to people whose identities and business roles may be unknown.
A visitor might be a prospective customer, job applicant, donor, vendor, former employee or automated system. Unless authentication is deliberately required, the organization cannot assume that the visitor has permission to see internal content.
An employee assistant operates in a different environment. Employees can sign in through Microsoft Entra ID, and their existing Microsoft 365 identities and permissions can help determine which SharePoint information they may access.
Microsoft’s current Copilot Studio authentication guidance states that an agent configured with no authentication can be used by anyone who has or discovers its link. The organization cannot use that configuration to control which individual visitors may chat with the agent.
That makes an anonymous website assistant unsuitable for unrestricted internal SharePoint retrieval.
Can Copilot Studio Be Published on a Public Website?
Yes. Copilot Studio agents can be published through several channels, including live websites, mobile applications, Teams and Microsoft 365 Copilot.
Microsoft’s instructions for publishing an agent to a live website explain that a publicly available website agent can be configured without authentication.
That does not mean the agent should have access to confidential company knowledge.
Publishing determines where people can reach the assistant. Knowledge-source and authentication decisions determine what the assistant can retrieve and who may receive the answer.
Those decisions must be made separately.
What Information Should a Public Website Assistant Use?
A public assistant should use only material the organization has deliberately approved for public distribution.
Appropriate sources may include:
- Published website pages
- Approved service descriptions
- Public frequently asked questions
- Public application or intake instructions
- Approved product information
- Public program eligibility guidance
- Published policies
- Public reports and white papers
- Approved contact and escalation information
Microsoft allows a Copilot Studio agent to use a public website as a knowledge source. The organization can limit the source to approved public domains and paths rather than exposing an internal document environment.
A public chatbot should not search a company’s complete internal SharePoint tenant merely because some of the information stored there is public. Public content should be deliberately separated, reviewed and made available through a controlled public knowledge set.
Why Isn’t a List of “Public Documents” Enough?
A document may appear harmless while containing details that were never intended for broad distribution.
For example, a public service description might have been drafted from an internal document containing employee names, internal pricing assumptions, approval notes or links to restricted resources. An old PDF may contain outdated commitments. A procedure may describe internal security measures that should not be public.
Before information becomes eligible for a website assistant, the organization should confirm:
- The content is approved for public use
- Sensitive comments and metadata have been removed
- The information is current
- The public wording matches actual policy
- Links lead only to public destinations
- A named owner is responsible for future review
- Superseded versions are excluded
The public assistant should also be tested with adversarial and unexpected questions. Visitors may ask it to reveal internal instructions, employee information, system details or documents outside its intended scope.
Can the Public and Internal Assistants Use the Same Agent?
Technically, Copilot Studio can publish an agent to multiple channels. Operationally, one shared agent may create unnecessary risk when public and internal audiences require different sources, instructions and security controls.
A separate-agent design is often clearer.
The public agent can use:
- Publicly approved sources
- Public-facing language
- Limited topics and actions
- Website-specific escalation paths
- Anonymous or customer-appropriate authentication
The internal agent can use:
- Approved SharePoint knowledge
- Employee authentication
- Role-based access
- Department-specific instructions
- Internal correction and escalation processes
Separate agents also make testing easier. The organization can confirm that public answers never depend on restricted information without having to reason through a large collection of channel-specific exceptions.
The AskMaisy Microsoft 365 implementation guide recommends treating an internal employee assistant and a website assistant as distinct implementations with intentionally different knowledge boundaries.
What About an Authenticated Customer or Member Portal?
An authenticated external portal is different from an anonymous public chatbot.
A customer, member, vendor or partner may be required to sign in before viewing account-specific information. In that situation, the organization needs a deliberate external identity and authorization design.
Authentication answers, “Who is this person?”
Authorization answers, “Which information and actions may this person use?”
A signed-in customer should not inherit employee access. The external assistant must be limited to sources and operations approved for that customer role. Authentication alone does not make an internal SharePoint source appropriate for external use.
The organization must also decide how accounts are created, how access is removed, how customer boundaries are enforced and what happens when the agent cannot verify the appropriate record.
What Should the Public Assistant Do When It Cannot Answer?
A public assistant should not improvise an answer from general knowledge when the organization’s approved sources do not support one.
It should state that it cannot confirm the requested information and provide a useful next step. Depending on the organization, that might mean:
- Linking to an approved contact form
- Providing public office hours
- Directing the visitor to the appropriate department
- Offering to collect a limited support request
- Explaining which documents or details the visitor should prepare
The assistant should not reveal that restricted information exists or identify confidential document titles while refusing the request.
For example, it should not say, “The answer is in the confidential executive pricing plan, but you do not have access.” It should simply explain that it cannot provide an approved public answer and identify the proper contact process.
How Should the Two Assistants Be Governed?
Public and internal assistants need separate testing plans, source inventories and owners.
For the public assistant, testing should verify that answers are accurate, suitable for external audiences and free of internal references. The team should attempt questions about confidential operations, employee information, unpublished prices and restricted documents.
For the internal assistant, testing should focus on employee identity, role-based permissions, restricted departmental knowledge and citation access.
Both assistants need continuing content review. Public service details change. Internal procedures change. Old pages, PDFs and policies must be removed from active retrieval when they are no longer authoritative.
The How Maisy Works model emphasizes approved sources, ownership, permissions and continuing governance rather than treating the chatbot as a standalone product.
Can a Public Chatbot Safely Use an Internal SharePoint Knowledge Base?
Not without strict separation, authentication and authorization controls—and unrestricted access is inappropriate.
For most public website uses, the safer approach is a separate assistant grounded only in curated public information. The internal assistant should remain authenticated and permission-aware, using approved organizational knowledge available to each employee.
The public and internal experiences may look similar to the people asking questions. Their security boundaries should be deliberately different.
