Microsoft 365 Copilot alternative for US government and GCC High: what the boundary requires
A self-hosted assistant can meet a US government or GCC High requirement only if the organization owns the hosting, identity, logging and model endpoints inside its own authorization scope. Onyx with vLLM is the main open-source combination to evaluate for that role, because Onyx handles the connectors, permission sync and chat interface while vLLM serves the model from infrastructure you control. This page does not establish whether Microsoft 365 Copilot holds an authorization for GCC High or DoD tenants, so confirm that status with Microsoft and in writing before you compare any option against it.
The boundary question starts with scope rather than product features. NIST SP 800-53 Rev. 5 is the control catalog that federal systems use, and SP 800-53B selects the low, moderate and high baselines. Your system security plan needs to show who operates each component: the vector index and Postgres database, the Onyx web and worker services, the Redis cache, the model servers, the object storage, and the reverse proxy in front of them. Under FedRAMP's scope rules from OMB M-24-15, a cloud service that stores or processes federal information on behalf of an agency falls in scope, so a self-managed deployment inside your own accounts changes which assessment applies. Ask your authorizing official and assessor to classify the deployment before procurement, not after.
For contractors handling CUI, 32 CFR 170.17(c)(5) matters most. A cloud service that stores or processes CUI for a CMMC Level 2 assessment must be FedRAMP Authorized at the Moderate baseline or meet equivalent requirements, so an add-on license whose authorization you cannot document may fail the scope test. Also check the vLLM security documentation before exposing endpoints: inter-node communication is insecure by default, and the --api-key option does not protect /metrics or /health, so place a reverse proxy in front that allowlists only the user-facing routes. Each of these choices becomes evidence in your assessment, and DeployOpen prepares that evidence without issuing any audit report or certification.
Which federal and defense requirements shape an AI assistant decision
Federal and defense buyers rarely choose an assistant on features alone. Each requirement below decides who must authorize the system, where the data may sit and which controls an assessor will test. Check which of them your contract or data type actually triggers before you compare products.
NIST SP 800-53 Rev. 5 baselines
NIST SP 800-53 Rev. 5 is the federal control catalog, and SP 800-53B groups it into low, moderate and high baselines that select 149, 287 and 370 controls and enhancements respectively. An assistant that indexes agency content will usually be sized to the impact level of that content, so the baseline you are assigned drives how much evidence you must produce for access control, audit and encryption. Ask your authorizing official which baseline applies before you scope a self-hosted stack.
FISMA and the Inspector General role
FISMA requires agencies to secure their information systems, and Inspectors General independently assess that security and report to OMB. For an assistant, this means the system must be in your agency's inventory with documented controls, and assessors will ask how prompts, retrieved documents and logs are protected. Self-hosting shifts that evidence burden to you, so plan for an independent review of the full stack, including vLLM and the index.
FedRAMP scope under M-24-15
FedRAMP applies to cloud products and services that create, collect, process, store or maintain federal information on behalf of an agency. A system that runs only for one agency on its own cloud infrastructure and is not offered as a shared service is outside that scope. Confirm with your agency whether a self-hosted assistant in your own account is out of scope, or whether a hosted vendor component inside it brings FedRAMP obligations.
CUI on non-federal systems
32 CFR 2002.14(h)(2) requires agencies to use NIST SP 800-171 when setting requirements for controlled unclassified information on non-federal information systems, unless the CUI category's own authority prescribes other safeguards. Contractors running an assistant over CUI must therefore map its components, including the index, model host and connectors, to the SP 800-171 requirements in their contract. Ask the contracting officer which CUI categories are involved.
CMMC Level 2 cloud storage rule
Under 32 CFR 170.17(c)(5), a defense contractor seeking CMMC Level 2 may store or process CUI in a cloud service only if that service is FedRAMP Authorized at the Moderate baseline or higher, or meets equivalent requirements. This matters if your assistant keeps indexes or embeddings of CUI in a hosted service, because that service then falls into the rule. A self-hosted stack in your own environment is assessed within your own scope, so confirm with your C3PAO how it is classified.
CJIS Security Policy v6.1 controls
If criminal justice information is involved, CJIS Security Policy version 6.1 took effect on 26 June 2026 and requires FIPS 140-3 certified modules or FIPS 197 AES with at least 256-bit keys for CJI in transit and at rest outside physically secure locations. It also requires vulnerability scanning at least monthly. Confirm your state's CJIS Systems Agency adoption and check that your vLLM, index and reverse proxy encryption choices meet these terms before any CJI enters the system.
Where Microsoft 365 Copilot stops and your own boundary starts
Before comparing any self-hosted assistant with Copilot in a government tenant, be clear about what Copilot does and does not do by default. Microsoft sells Microsoft 365 Copilot as an add-on license to eligible plans such as Microsoft 365 E3, E5 and Business Premium, and includes it in Microsoft 365 E7. Work-based Copilot Chat grounds its answers in content the user's Microsoft Entra account can already access, and it requires a Microsoft Copilot license. Web-based chat, by contrast, only shows internet results. That split matters for an agency or contractor: the grounding that makes Copilot useful for internal documents depends on licensing, identity and the tenant's permissions, so each user group needs to be checked against the license and the Entra configuration it actually has.
The facts behind this page do not confirm whether Microsoft 365 Copilot is available in GCC, GCC High or DoD tenants, which features are enabled there, or what authorization status applies to them. Treat those three questions as open until you have answers in writing. Ask Microsoft for the current feature availability and compliance documentation for your specific cloud and tenant type, and ask your contracting officer or authorizing official whether that documentation is acceptable for the system boundary you plan to use. Do not carry a comparison forward from commercial cloud documentation into a government tenant without that confirmation.
Once you have those answers, draw the boundary explicitly. Record which systems hold the indexed content, the prompts, the responses and the logs, who administers each one, and which of them sit inside your authorization boundary. A self-hosted assistant such as Onyx, which can index SharePoint, Teams and other sources while honoring the permissions those sources already set, only keeps the boundary under your control if its index, its model endpoint and its logs are also hosted within it. If the model is an external API, that API becomes part of the boundary and needs its own answer from your authorizing official.
Which open-source assistants fit a boundary you operate
This table compares four self-hosted assistants and one model serving engine by how each one can sit inside an authorization boundary you control. Read each row against your own boundary requirements, because none of these products is FedRAMP authorized by default and the boundary is the deployment you build and document.
| Option | How it meets the boundary | Trade-offs |
|---|---|---|
| Onyx | Connectors for SharePoint, OneDrive, Outlook and Teams sync source permissions so answers only draw on content the user can already see. Documents an air-gappable deployment with Docker, Kubernetes, Helm or Terraform, and works with vLLM or Ollama for in-boundary models. | SSO through OIDC or SAML, SCIM provisioning and RBAC are listed as enterprise features, so confirm which ones the Community Edition includes. Connector and permission sync setup needs validation in your own tenant. |
| Open WebUI | Can run entirely offline and works with Ollama and OpenAI-compatible APIs, so the interface and model traffic can stay inside your network. | The Open WebUI License restricts changing branding for deployments above 50 users in a rolling 30-day period unless the copyright holder permits it or an enterprise license is bought. Document connectors are not its core focus, so confirm grounding in SharePoint and Teams needs. |
| LibreChat | MIT licensed and self-hosted with Docker. Offers multi-user authentication through OAuth2, LDAP and email, and supports Ollama and other providers, so models can be hosted inside your boundary. | The supplied facts do not list document connectors for SharePoint or Teams, so confirm whether grounding in Microsoft 365 content is possible or needs custom work. MCP support adds integration options that also need review. |
| AnythingLLM | MIT licensed, runs as a Docker deployment on your own servers, supports multiple users and ingests documents into built-in vector databases with local or cloud LLMs. | Built for document chat rather than enterprise search across Microsoft 365 sources, so confirm permission-aware retrieval and audit logging meet your requirements before choosing it for controlled content. |
| vLLM (model serving, not an assistant) | Apache-2.0 inference engine that exposes OpenAI-compatible endpoints, so models can run on GPUs in your authorized environment. Security docs require a reverse proxy allowlist and an isolated network for multi-node traffic. | vLLM has no paid edition, so cost comes from accelerator capacity, infrastructure and operators. The --api-key option does not protect every endpoint, so restrict exposed routes and monitor /metrics access. |
How vLLM hosts the model without widening the attack surface
vLLM runs as a server started with vllm serve, and it exposes OpenAI-compatible endpoints including /v1/chat/completions, /v1/completions, /v1/responses and /v1/embeddings. Applications written against the OpenAI API can point at it with a base URL change, which matters when Onyx or another assistant front end needs a model behind it. Hardware support is broad: NVIDIA CUDA, AMD ROCm and Intel XPU GPUs, x86 and ARM CPUs, Apple silicon and IBM Z CPUs are all listed in the installation docs.
- Endpoint set: Chat, completions, responses and embeddings are the endpoints most assistant deployments call. Audio transcription is also exposed, so confirm whether it is needed at all.
- GPU platform: Confirm the accelerator family with your hardware vendor and check the installation documentation for that platform before procurement.
- Third-party hardware: Other accelerators run through plugins outside the main repository, which adds a support path your team must own.
- Model placement: Decide which model runs on which hardware and document it, since the serving config defines what the assistant can answer with.
- Pinned versions: Record the vLLM and model versions in your configuration so auditors can trace what served a given answer.
Confirm with your security team which endpoints users may call, because this list drives the proxy rules in the securing tab.
A large model often does not fit on one GPU, so vLLM splits it. Tensor parallelism divides the model across GPUs inside one node, and pipeline parallelism spreads layers across nodes. For mixture-of-experts models, data parallel deployment is supported. Multi-node runs use Ray or vLLM's own multiprocessing backend to coordinate workers, and each choice changes what traffic crosses the network.
- Single node first: Tensor parallelism within one node keeps inter-GPU traffic local and is the simpler starting point for most teams.
- Cross-node pipelines: Pipeline parallelism across nodes adds network traffic between hosts, so network design becomes part of the model's performance and security.
- Coordination backend: Ray or the built-in multiprocessing backend each bring their own operating model, dependencies and upgrade path.
- Mixture-of-experts: Data parallel deployment applies to these models specifically, so confirm the model architecture before choosing a layout.
- Capacity planning: GPU count, memory and network bandwidth drive cost, and they are the main items to price in a quote.
Ask your platform team to confirm the target model, expected concurrency and whether multi-node operation is required, since these decide whether a single node is enough.
The --api-key option protects endpoints under /v1, /v2, /inference and /cohere. It does not protect /invocations, /pause, /resume, /abort_requests, /metrics or /health, and the vLLM security docs warn against relying on it alone. The recommended pattern is a reverse proxy that allowlists only the endpoints meant for users and blocks everything else at the network edge. Multi-node traffic has a separate issue: communication between nodes is insecure by default, with no authorization or encryption, so those nodes must sit on an isolated network.
- Reverse proxy allowlist: Expose only the chat, completions, responses and embeddings paths to the assistant, and deny control and metrics paths from user networks.
- Control endpoints: Keep
/pause,/resumeand/abort_requestsreachable only from administrative hosts, if at all. - Metrics and health: Restrict
/metricsand/healthto the monitoring network so usage data is not exposed to general users. - Node isolation: Place multi-node workers on a dedicated network segment with no route from user subnets.
- Key handling: Treat the API key as a secret, rotate it through your normal process and do not depend on it as the only control.
Ask your security team to test the proxy allowlist against the vLLM endpoint list and to confirm how node-to-node traffic is segmented inside your authorization boundary.
vLLM publishes Prometheus-format metrics at /metrics, covering request counts, token throughput, latency histograms and KV cache use, with configurable histogram buckets. These feed dashboards and alerts. The project documents Kubernetes options including native manifests, Helm, the vLLM production-stack, AIBrix, KServe, KubeRay, LeaderWorkerSet, llm-d and NVIDIA Dynamo. Minor releases arrive about every two weeks, with v0.31.0 dated October 5, 2026, so an unplanned upgrade cadence will fall behind quickly.
- Metrics pipeline: Scrape
/metricsfrom inside the monitoring network only, and send latency and KV cache data to your existing observability stack. - Kubernetes packaging: Choose between native manifests, Helm and the production-stack based on the platform team's skills and existing tooling.
- Release cadence: Set a patch process that tests each minor release in a staging environment before promotion, since releases come roughly every two weeks.
- Change records: Keep version, configuration and model hash records for each deployment to support change management.
- Vendor support: vLLM is community-maintained with no paid edition, so support comes from your own team or a service provider you contract.
Confirm with your platform and compliance teams how patches, vulnerability scans and change approvals will be scheduled, and which release the authorization package will name.
What assessors and contracting officers ask to see
An assessor or contracting officer will not accept a claim that an assistant is secure, only evidence that its boundary, controls and operating records can be inspected. The cards below list the artifacts that tie an open-source assistant, its index and its model server to the authorization decision your agency or contract requires.
System security plan
The system security plan must name every component: the Onyx services, Postgres, the index store, Redis, the vLLM model servers, the reverse proxy, and the identity provider. For each one, record what data it holds, which network it sits on, who administers it, and how it connects to the Microsoft 365 tenant. Ask your assessor which control baseline the plan must follow before drafting it, since the scope of a deployment in a GCC High or DoD tenant changes the answer.
Control mapping to NIST SP 800-53
Map each implemented control to the NIST SP 800-53 Rev. 5 catalog and to the baseline your system category selects under SP 800-53B. Document which controls the platform inherits from the cloud or data center, which the assistant implements, and which the operating team owns. Gaps such as session timeouts, audit record content or boundary protection must appear as open items with owners, not be left out of the mapping.
Access control and SSO evidence
Provide screenshots, configuration exports and test results showing that Onyx permissions mirror the source application ACLs for SharePoint, OneDrive and Teams, and that SSO through OIDC or SAML is bound to your identity provider. Show SCIM deprovisioning for a departed user and a test where a user without access to a document receives no citation from it. Confirm these behaviors against your own tenant, since connector coverage differs by source.
Query history and access logs
Retain query history and usage records from the assistant, plus the vLLM access log behind your reverse proxy and the Prometheus metrics exposed at /metrics. Together these show who asked what, which documents were retrieved, and which endpoints each caller reached. Confirm with your assessor where these logs are shipped, how long they are kept, and how they are protected from modification.
Vulnerability scan results
Keep dated scan reports for the operating system, container images, Onyx, vLLM and the proxy. Where CJIS applies, the CJIS Security Policy requires vulnerability scanning at least monthly, so the scan schedule and the remediation records for each finding must be in the package. Scan results should cover the same components listed in the system security plan.
Boundary diagram and network allowlist
The boundary diagram shows every data flow into and out of the assistant, including connector traffic to Microsoft endpoints, model traffic to vLLM, and user traffic through the proxy. The network allowlist lists only the endpoints meant for users, because vLLM's --api-key does not protect /metrics or /health. vLLM's own documentation says inter-node traffic in multi-node runs is unauthenticated, so the diagram must show an isolated network for those nodes.
What a self-hosted GCC High alternative costs to run
The largest variable in a self-hosted GCC High alternative is the accelerator capacity behind vLLM. vLLM is Apache-2.0 licensed and has no paid edition, so its license cost is zero, but the GPUs or other accelerators that serve the model are not. Those costs depend on the model sizes you choose, how many concurrent users you plan for, and whether you buy hardware for a boundary you control or rent capacity inside an authorized environment. Confirm with your compliance lead which hosting options your authorization boundary permits before you size anything. Onyx Community Edition is MIT licensed, so the application layer has no license fee either, but any Enterprise Edition features such as role-based access control must be quoted separately from the written scope.
Some costs are one-time and others recur. One-time work includes architecture, the connector build for SharePoint, OneDrive, Teams and Outlook, permission mapping, and the control mapping and evidence set you prepare for an assessment. Recurring costs include compute, storage and the surrounding infrastructure inside the boundary, plus the staff who patch, monitor and upgrade the stack. vLLM ships new minor releases about every two weeks, for example v0.31.0 on October 5, 2026, so budget for a regular upgrade and regression-testing cycle rather than a one-off install. Vulnerability scanning and the assessment support you need each year also recur. Ask your vendor or internal team whether connector changes triggered by Microsoft API updates are included in the retainer or billed as new work.
When you request a quote, ask for the scope in writing: the environments (development, test and production), the number of connectors and the sites or libraries each one covers, the model sizes and count of model endpoints, expected concurrent users, log and conversation retention periods, and who holds the administrator and key-management roles. Ask for the staffing assumptions behind each line and whether the quote covers testing and documentation of the vLLM security configuration, including a reverse proxy that exposes only user-facing endpoints. Microsoft 365 Copilot's per-user add-on pricing is not covered on this page, so obtain the current figures and the licensing terms that apply to your government tenant directly from Microsoft before comparing totals.
Questions agencies and contractors ask before hiring help
Can Microsoft 365 Copilot be used in GCC High or DoD tenants?
The supplied facts do not establish whether Copilot is available in GCC High or DoD environments, so confirm this directly with Microsoft and your tenant's licensing representative before you plan around it. Microsoft's licensing guidance describes Copilot as an add-on to eligible plans, and work-based Copilot Chat grounds answers in content your Microsoft Entra account can access, but availability by cloud environment is a separate question. Ask for the service description and the government cloud feature list in writing, including which Copilot experiences and data paths are covered.
Is a self-hosted assistant FedRAMP authorized?
No open-source assistant is FedRAMP authorized by being installed, because FedRAMP authorizes cloud products and services offered to agencies, not software in the abstract. Whether a deployment falls within FedRAMP scope depends on who operates it, whether it is offered as a shared service, and which cloud provider hosts it. A system run only for one agency on its own infrastructure may sit outside FedRAMP scope, while a contractor hosting CUI for an agency may need to meet FedRAMP Moderate or equivalent requirements. Have your authorizing official and assessor make that scope decision with the architecture in front of them.
How long does a deployment take in a government environment?
The supplied facts do not give a duration, and the timeline depends on drivers you can list before any quote. Scope is the first: how many sources you connect, whether Microsoft 365 connectors need tenant-level approval, and whether you need Enterprise Edition features such as role-based access control. Model choice matters as well, since hosting models on your own GPUs requires hardware procurement and capacity planning. Assessment timing often dominates, because security approvals, the system security plan and evidence gathering run on the agency's schedule. Ask any provider for a written scope and milestone plan before accepting a date.
What does our team have to provide before work starts?
Plan to provide tenant access, named identity owners, GPU or accelerator capacity, and written security approvals before implementation begins. For the Microsoft side, you need an admin who can register the connector application and grant the Graph and SharePoint or Teams permissions the connectors require. Identity owners must confirm how Entra ID sign-in, group membership and SCIM provisioning will map to Onyx roles. Infrastructure owners must confirm the cloud account or enclave, network segmentation, logging destinations and backup targets. Security staff must approve the architecture, the vLLM endpoint exposure and the vulnerability scanning cadence before anything touches production data.
Can our own staff run this without outside help?
Yes, teams that already operate Kubernetes or Docker, manage Entra ID or another identity provider, and have GPU operations experience can run this themselves, but the skills gap is usually in the vLLM security model. vLLM's --api-key option does not protect every endpoint, including /metrics and /health, so the documentation recommends a reverse proxy that allowlists only the endpoints meant for users. Multi-node deployments also need isolated networking, because inter-node traffic is insecure by default. Confirm that your staff can build and maintain that proxy, the network isolation and the patch cadence for both Onyx and vLLM before taking this in-house.
What changes if our data includes CUI or criminal justice information?
CUI and CJI bring specific control requirements that apply to the whole system, not only the assistant. For CUI on non-federal systems, NIST SP 800-171 is the baseline federal agencies use, and defense contractors must meet CMMC Level 2 requirements, including FedRAMP Moderate or equivalent for any cloud service that stores or processes CUI. For CJI, the FBI CJIS Security Policy version 6.1 requires FIPS 140-3 validated modules or AES with 256-bit keys for CJI in transit and at rest outside physically secure locations, plus vulnerability scanning at least monthly. Ask your compliance lead which data classes flow through prompts, indexes and logs, and confirm each control mapping with your assessor.
What does DeployOpen cover for a government-facing deployment?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, including cloud accounts, data centers or air-gapped networks. It also runs security testing of applications, APIs, infrastructure and AI systems, and prepares systems, controls and evidence for compliance assessments. DeployOpen does not issue audit reports, attestations or certifications, and independent assessors and certification bodies make those determinations. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope.
How DeployOpen deploys an assistant inside your authorization boundary
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. For a Microsoft 365 Copilot alternative in US government or GCC High, that means the assistant, its model servers and its connectors run under the agency's or contractor's own authorization boundary, with DeployOpen preparing the systems and evidence that independent assessors review.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope names which SharePoint, OneDrive, Teams and Outlook sources Onyx will index and which user groups get access.
- Scope records where vLLM model servers, Onyx services and their databases will run inside your boundary and who operates them.
How we build
- We deploy Onyx with Postgres, its index, Redis and model servers in your own environment, using Docker, Kubernetes, Helm or Terraform.
- We configure SharePoint and Teams connectors and verify that permission sync limits answers to documents each user can already see.
- We place vLLM endpoints behind a reverse proxy that allowlists only user-facing routes, and we test that metrics and admin routes stay unexposed.
How we hand over
- You receive architecture, configuration and network diagrams mapped to the control families your assessor will review.
- Runbooks cover upgrades, backups, log retention, key management and how to handle offline updates in disconnected networks.
- We prepare control evidence for your compliance assessment, but independent auditors and certification bodies issue any authorization or attestation.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after handover.
- Testing covers the Onyx application, the vLLM serving layer, connector credentials and the cloud or on-premises infrastructure beneath them.
- Before any quote, ask for the written scope, the named assumptions about your boundary and the list of deliverables each phase produces.
