Security, Permissions, and Technical Architecture
Learn how a Knowledge Hub protects organizational information while making it easier for employees to find what they need.
This whitepaper explains user permissions, SharePoint security trimming, data isolation, AI grounding, domain-specific agents, website chat implementation, and how organizational data is protected from unauthorized access and model training.
Whitepaper:
Read the Security and Architecture Whitepaper
How organizational knowledge is protected, isolated, permission-aware, and delivered through Microsoft Copilot agents
Executive Summary
The Pixeldust Knowledge Hub is designed around a simple rule: an AI agent must not become a shortcut around the organization’s existing security model. The hub is built inside the customer’s Microsoft 365 environment, where identity, SharePoint permissions, Microsoft Entra ID, data governance, retention, auditing, and compliance controls remain under the organization’s control.
For authenticated internal use, the agent retrieves only content the signed-in employee is already authorized to access. A technician, manager, human resources employee, executive, and contractor can ask the same question and receive different results because their underlying permissions are different. The agent does not grant access; it respects access that has already been granted.
Pixeldust also configures agents to rely on approved organizational knowledge sources rather than uncontrolled web results or broad general knowledge. Web search is disabled for internal knowledge agents, and the agent is instructed to decline or clearly state when the approved sources do not contain an answer. This reduces unsupported answers and keeps the system focused on the organization’s policies, procedures, documents, and expertise.
Microsoft states that Microsoft 365 Copilot prompts and responses are processed within the Microsoft 365 service boundary and are not used to train the underlying foundation models. The customer’s data remains logically isolated within its tenant and continues to be protected by Microsoft 365 security, privacy, compliance, and access controls.
A public website agent requires a different security design. It should use a separate, intentionally public knowledge domain containing only approved customer-facing information. An internal hub should never be exposed anonymously. Where a website experience must provide private information, users must authenticate, and the implementation must enforce their identity and permissions before retrieving protected content.
Core principle: the agent is an interface to authorized knowledge—not a new repository that ignores permissions.
1. Security Model: Identity First, Permissions Always
1.1 The user signs in with their organizational identity
Internal employees access the agent through Microsoft Teams, Microsoft 365 Copilot, or another authenticated channel. Microsoft Entra ID verifies who the user is. The agent then operates in the context of that signed-in identity.
1.2 The agent does not create new access
When SharePoint or another supported Microsoft 365 source uses end-user authentication, the retrieval process is security-trimmed. The system searches only the content that the current user is permitted to open. Content outside that user’s permissions is not returned to the agent as grounding material and therefore should not be included in the response.
1.3 SharePoint remains the source of truth for access
Permissions can be managed at the SharePoint site, library, folder, file, Microsoft 365 group, or security-group level. Pixeldust favors clean group-based permissions and separate sites or libraries for materially different security domains. Excessive file-by-file exceptions are avoided because they become difficult to audit and maintain.
1.4 Permission changes flow through to agent access
If an employee changes roles, joins a department, leaves the organization, or is removed from a security group, their access to the underlying content changes accordingly. Because the agent depends on those same identity and permission controls, the agent’s available knowledge changes with them. Search indexes can require normal processing time to reflect changes, so sensitive removals should follow the organization’s established offboarding and access-revocation procedures.
2. Practical Permission Examples
| User | Authorized knowledge | Restricted knowledge | Expected agent behavior |
| Field technician | Service procedures, equipment manuals, safety checklists, approved troubleshooting guides | Payroll, executive planning, employee records | Answers operational questions but cannot retrieve payroll or HR material. |
| Service manager | Technician content plus scheduling procedures, warranty rules, quality reports, departmental performance | Confidential HR case files, owner-only finance records | Provides broader operational answers based on the manager’s group membership. |
| Human resources employee | Employee handbook, benefits, onboarding, approved HR procedures, assigned personnel files | Customer pricing, engineering documents, executive financial forecasts | Answers HR questions from authorized sources without exposing unrelated departments. |
| Executive | Executive site, financial reports, strategy documents, operating procedures | Any specifically segregated legal or board material not granted to the executive account | Can access broad business knowledge but remains constrained by explicit exclusions. |
| External contractor | Only the project site, files, and procedures shared with the contractor group | Internal operations, employee information, unrelated customer data | Answers only from the limited project workspace. |
| Former employee | No active account or group membership after offboarding | All organizational content | Cannot authenticate or retrieve internal knowledge. |
Important: “The agent knows it exists” is not the same as “the user can access it.” Security trimming prevents unauthorized content from being used to answer that user.
3. Restricting the Agent to Approved Internal Knowledge
3.1 Approved-source grounding
Each internal agent is connected only to named, approved knowledge sources such as specific SharePoint sites, document libraries, Dataverse tables, or controlled enterprise systems. Pixeldust documents the scope of each source and tests representative questions before release.
3.2 Web search is disabled
For internal knowledge agents, web search is turned off. The agent is not configured to supplement company answers with public internet content. This prevents a company policy question from being blended with unrelated guidance from the web.
3.3 General knowledge is constrained
In Copilot Studio experiences that provide an AI General Knowledge control, it is turned off. In newer experiences where knowledge is managed through configured sources rather than a separate general-knowledge toggle, Pixeldust limits the agent to explicit knowledge sources, disables web search, applies restrictive instructions, and validates behavior through testing. Because large language models still provide the language-generation layer, this is best described as approved-source grounding—not a claim that the underlying model has no pretraining.
3.4 Safe failure behavior
The agent is instructed to say that it cannot find an approved answer when the hub does not contain sufficient information. It should not invent policy, pricing, legal guidance, technical specifications, or internal procedures. Where appropriate, it can direct the user to an owner, department, form, or escalation path.
3.5 Citations and traceability
Where supported, answers include citations or links to the source document. Users can verify the answer, open the governing policy, and see whether the material is current. Source ownership, review dates, and content lifecycle rules are part of the Knowledge Hub governance process.
4. Data Privacy, Training, Isolation, and Safety
4.1 Organizational data is not used to train the foundation model
Microsoft states that prompts and responses in Microsoft 365 Copilot and Copilot Chat under enterprise data protection are not used to train the underlying foundation models. The organization’s documents are used at request time to ground an answer for an authorized user; they are not contributed to a public model-training dataset.
4.2 Tenant isolation
The Knowledge Hub is implemented in the customer’s Microsoft 365 tenant. The customer retains control over identities, groups, SharePoint sites, policies, licenses, audit configuration, retention, and access. Pixeldust does not combine one customer’s hub with another customer’s hub.
4.3 Data stays within the Microsoft enterprise service boundary
Prompts, responses, and grounding operations are processed using Microsoft enterprise services and protections applicable to the customer’s licensing and configuration. Microsoft 365 compliance capabilities can include auditing, eDiscovery, retention, sensitivity labels, data loss prevention, conditional access, multifactor authentication, and device controls. Exact capabilities depend on the customer’s Microsoft 365 plan and administrative configuration.
4.4 Least privilege
Users, service connections, makers, and administrators should receive only the access required for their role. End-user credentials are preferred for tools and connectors when data must be restricted to the requesting person. Maker-provided credentials are reserved for carefully reviewed low-risk or shared-service scenarios because they can cause the agent to operate with broader access than the user.
4.5 Sensitive-data segmentation
Highly sensitive material—such as personnel records, legal matters, medical information, payment data, trade secrets, board documents, or acquisition plans—should be placed in separate security domains. It should not be mixed into a broad company library merely because the agent can technically search it.
4.6 Logging, auditing, and oversight
Organizations should use available Microsoft 365 audit and compliance tools to review sign-ins, access, content changes, sharing, and agent activity. Agent owners should periodically review source scope, instructions, authentication, channels, tools, and published versions. Security is an operating process, not a one-time installation setting.
5. Technical Stack
| Layer | Primary technology | Purpose |
| Identity and access | Microsoft Entra ID, Microsoft 365 groups, security groups, Conditional Access | Authenticates users and determines group membership, sign-in rules, and access context. |
| Knowledge repository | SharePoint Online and approved Microsoft 365 content sources | Stores controlled documents, SOPs, FAQs, policies, decision trees, forms, and structured business knowledge. |
| Governance and compliance | Microsoft Purview capabilities, retention, sensitivity labels, DLP, auditing | Applies governance, classification, lifecycle, monitoring, and data-protection controls where licensed and configured. |
| Agent platform | Microsoft Copilot Studio and Microsoft 365 Copilot agents | Connects users to approved knowledge sources, instructions, topics, actions, and escalation paths. |
| Automation and integrations | Power Automate, approved connectors, APIs, Dataverse or Azure services when needed | Moves approved information, triggers workflows, and connects structured systems without manually duplicating all data. |
| Employee interface | Microsoft Teams and Microsoft 365 Copilot | Provides a familiar authenticated channel for internal users. |
| Website interface | Copilot Studio web channel, Web Chat, Microsoft 365 Agents SDK, or secured Direct Line implementation | Publishes a customer-facing or authenticated web experience using an intentionally scoped knowledge domain. |
5.1 How a question is answered
The user opens the agent in an approved channel and signs in when authentication is required.
Microsoft Entra ID establishes the user’s identity and applicable access context.
The agent interprets the question and selects the relevant approved knowledge source or topic.
The underlying service retrieves only content available under the configured source and authentication model.
The language model creates an answer grounded in the retrieved material and the agent’s instructions.
The answer is returned with citations or links when supported. If reliable approved content is not found, the agent declines, asks for clarification, or escalates.
6. Copilot Agents for Separate Knowledge Domains
A single all-knowing company bot is rarely the best security or usability design. Pixeldust can create multiple agents or tightly scoped knowledge areas, each aligned to a business domain, audience, owner, and permission model.
| Agent | Knowledge scope | Audience |
| Operations Agent | SOPs, checklists, equipment guidance, field procedures, quality standards | Technicians, operations staff, managers |
| HR and Onboarding Agent | Employee handbook, benefits, onboarding plans, approved policies, training materials | Employees and HR; sensitive case records remain segregated |
| Sales Agent | Service descriptions, qualification rules, proposal language, pricing guidance, case studies | Sales team and approved managers |
| Customer Service Agent | FAQs, service policies, escalation procedures, warranty guidance, approved scripts | Customer service and dispatch teams |
| Executive Agent | Strategy, scorecards, financial reports, leadership procedures, meeting knowledge | Executives and specifically approved leaders |
| Public Website Agent | Public FAQs, service information, locations, hours, approved educational content, lead capture | Anonymous website visitors; no internal content |
6.1 Why domain separation matters
It reduces the chance that irrelevant or sensitive content is retrieved.
It produces clearer answers because each agent has focused instructions and terminology.
It assigns a business owner who is responsible for source quality and approval.
It allows different authentication, sharing, channels, and escalation rules.
It makes testing and auditing manageable.
7. Implementing a Website Chat AI Agent
7.1 Public website agent
A public website agent can be embedded using Copilot Studio’s web channel, an iframe-based Web Chat experience, the Microsoft 365 Agents SDK, or a secured custom integration. For an anonymous public agent, authentication is normally disabled, which means the agent must be treated as publicly accessible.
Therefore, an anonymous website agent must never be connected directly to confidential internal SharePoint knowledge.
Instead, Pixeldust creates a separate public knowledge domain containing only information approved for customers and prospects. Examples include services, service areas, hours, financing explanations, general warranties, maintenance guidance, public policies, case studies, and contact information. The agent can answer questions, guide visitors, collect lead information, and route requests without exposing internal operations.
7.2 Authenticated customer or employee portal
A website can provide protected answers when users authenticate. The agent can use Microsoft Entra ID or another supported authentication design, and the application can connect through the Microsoft 365 Agents SDK or secured channel configuration. Authentication alone is not enough: the knowledge source and tools must also use the correct user-level authorization model.
7.3 Website deployment controls
Use a separate production agent or production environment rather than relying on the Copilot Studio demo site.
Enable secured Direct Line access or an authenticated SDK implementation when the experience is not intended to be openly accessible.
Restrict allowed domains and rotate secrets or tokens according to the organization’s security practices.
Do not place secrets directly in public page code.
Apply rate limiting, abuse monitoring, content moderation, privacy disclosures, and a clear escalation path.
Collect only the lead or support information actually required and define where that data is stored.
Test prompt injection attempts, requests for internal information, and questions outside the approved domain before launch.
8. Pixeldust Implementation Approach
1. Security and knowledge assessment: Identify user groups, sensitive domains, current SharePoint structure, external sharing, existing labels, licensing, and compliance requirements.
2. Information architecture: Create sites, libraries, metadata, ownership, review schedules, and group-based permissions aligned to business domains.
3. Knowledge preparation: Collect documents, interview experts, document unwritten procedures, remove duplicates, identify obsolete material, and assign authoritative sources.
4. Agent configuration: Create domain agents, connect approved sources, disable web search for internal agents, constrain instructions, configure authentication, and define safe fallback behavior.
5. Security testing: Test users from multiple roles, denied-access scenarios, sensitive questions, prompt injection, stale content, missing answers, citations, and escalation.
6. Pilot and release: Begin with a controlled group, review real questions and failures, correct content and scope, then expand access.
7. Governance and maintenance: Assign owners, review permissions, monitor content freshness, audit usage, revise instructions, and retest whenever sources, roles, or channels change.
9. Shared Responsibility
| Responsibility | Customer organization | Pixeldust |
| Identity and employment status | Maintain user accounts, MFA, offboarding, devices, and group membership. | Design around the customer’s identity model and document required groups. |
| Content ownership | Approve authoritative content, sensitivity, retention, and who should have access. | Organize, structure, migrate, and connect approved knowledge. |
| Microsoft licensing and tenant policy | Purchase and administer appropriate licenses and enterprise policies. | Assess requirements and configure within the agreed scope. |
| Ongoing permissions | Approve role changes and periodically review access. | Provide governance guidance and optional maintenance support. |
| Agent behavior | Designate business owners and approve responses and escalation rules. | Configure, test, document, and refine agent instructions and sources. |
| Incident response | Own organizational incident-response and legal/compliance decisions. | Support investigation of the implemented hub and agent configuration within the engagement scope. |
10. Important Limitations and Honest Expectations
No AI system should be described as infallible. Grounded agents can still misunderstand a question, summarize incorrectly, or use outdated source material.
Permissions protect only what is configured correctly. Poorly designed SharePoint access, broad sharing links, excessive owner rights, or shared credentials can undermine the security model.
An agent cannot distinguish authoritative from obsolete content unless the knowledge base is governed and maintained.
Public agents are public. Any source connected to an anonymous agent should be assumed discoverable through conversation.
Features and controls vary by Microsoft product experience, licensing, region, and release. Final architecture is confirmed during assessment and documented in the statement of work.
Security-sensitive implementations should be reviewed by the customer’s Microsoft 365 administrator, security lead, legal counsel, or compliance team as appropriate.
11. Summary
The Pixeldust Knowledge Hub makes organizational knowledge more useful without abandoning established enterprise controls. Internal agents authenticate users, respect source permissions, retrieve approved content, and operate inside the customer’s Microsoft environment. Public website agents are separated from confidential knowledge unless a deliberate authenticated architecture is implemented. Web search is disabled for internal agents, approved sources are explicitly scoped, and the system is tested to refuse unsupported questions rather than quietly inventing business answers.
The result is not simply a chatbot. It is a governed knowledge architecture that allows multiple Copilot agents to serve different business domains while preserving identity, access, privacy, source ownership, and organizational control.
Microsoft Reference Notes
Microsoft 365 Copilot Chat privacy and protections
Knowledge overview for Copilot Studio agents
Manage knowledge sources and web search
Generative answers and user-level access
Integrate agents with web or native apps
Configure web and Direct Line channel security
Configure user authentication for tools
Document note: This document describes the intended Pixeldust architecture and Microsoft capabilities available as of July 2026. Exact controls depend on tenant configuration, licensing, selected Copilot Studio experience, and the final statement of work. It is not a substitute for legal, regulatory, or formal cybersecurity advice.