Cribl.Cloud Government differs from commercial Cribl.Cloud in three ways: some capabilities are unavailable or constrained, some behavior affects how you deploy and operate the platform, and FedRAMP authorization drives additional requirements. For onboarding steps, see Onboarding: Quick Start for Federal Users.

Different or Unavailable Capabilities ​

Azure Key Vault Secret Stores ​

If your Azure Key Vault lives in the Azure commercial environment, you can generally use it as a secret store from Cribl.Cloud Government, for example through an API token. Because external API integrations are limited, behavior varies by the specific Key Vault features you use. Test your configuration before you rely on it.

Authentication and Access Behavior ​

Some SSO diagnostics show less detail than in commercial (for example, Test Connection messaging). See SSO (Single Sign-On): Setup and Requirements.

Security, Compliance, and FedRAMP-Driven Constraints ​

Splunk FIPS Considerations ​

When integrating Cribl.Cloud Government with Splunk, FIPS compatibility can matter for on-premises Splunk. Cribl.Cloud Government Worker Groups use FIPS 140-3; Splunk Enterprise releases before 10.0 support only FIPS 140-2.

Customers on older Splunk versions may need a hybrid Worker Group on an OS that still supports FIPS 140-2. Splunk Enterprise 10.0 and later support FIPS 140-3. This gap matters most for on-premises Splunk; cloud-to-cloud setups rarely have the same mismatch. Plan Splunk upgrades where needed.

Federated Search and Gov Cloud Object Stores ​

Federated Search is available in Cribl.Cloud Government, but it cannot query Datasets that live in AWS GovCloud (for example, us-gov-west-1 or us-gov-east-1) or Azure Government regions. The Cribl.Cloud Government boundary is currently authorized on FedRAMP-approved AWS US East/West regions, so federated queries cannot reach across into Gov Cloud object stores. Plan federated Datasets to live in supported regions, or use a hybrid Worker Group to process data in place.

Administrative and Procurement Differences ​

• Procurement: You cannot purchase Cribl.Cloud Government through AWS Marketplace. Contact your Cribl Federal account team for packaging and ordering.
• Support channels: Cribl.Cloud Government uses standard support channels, and all support processes meet FedRAMP compliance requirements.
• Status communications: The public status page covers commercial and government tenants.

AI in Cribl.Cloud Government ​

Cribl Insights is not a Cribl AI product. Insights in Cribl.Cloud Government is at parity with commercial Cribl.Cloud; the restrictions in this section apply to Cribl AI and AI-assisted features only.

Cribl AI is available in Cribl.Cloud Government, but only through a Custom AI Provider that you configure. Cribl.Cloud Government never routes large language model (LLM) requests to Cribl-managed models, and it cannot reach the Cribl AI backend that serves them in commercial Cribl.Cloud.

Custom AI Providers Are Required ​

Cribl.Cloud Government is permanently limited to the bring-your-own-model (BYOM) approach:

• You must configure a Custom AI Provider before any feature that calls an LLM can run. Until you do, those feature entry points stay visible but report that AI is unavailable.
• Features that do not call an LLM do not need a provider. These are the embedded Cribl MCP Server, where MCP clients bring their own models, and Cribl Guard background detection, which runs on a local detection model.
• The Cribl Default option, which uses Cribl-managed models, is not supported. AI Settings does not display a control to switch to it, and the API rejects a request to change the provider mode.
• There is no path to Cribl-managed models later. This restriction follows from the FedRAMP authorization boundary, so neither an administrator nor Cribl Support can change it.
• Deleting your Custom AI Provider makes Cribl AI features non-operational until you configure another one. Cribl AI does not fall back to Cribl-managed models, as it does in commercial Cribl.Cloud. See Delete a Custom AI Provider.

Feature Differences ​

After you configure a Custom AI Provider, most Cribl AI features behave as they do in commercial Cribl.Cloud. The following differ:

These features work the same as in commercial Cribl.Cloud once you configure a Custom AI Provider:

• Copilot chatbot, for questions about your deployment
• Copilot Editor
• KQL assistant and visualization assistant
• Search investigations, apart from web search
• Cribl Guard rule-building assistance and Analyze detections
• MCP integrations

Cribl Guard background detection does not appear in either list, because it needs no Custom AI Provider at all. See Cribl Guard in Cribl.Cloud Government.

Data Flow and Auditing ​

Cribl.Cloud Government sends no AI requests, prompts, or telemetry to the Cribl AI backend. Inference happens at the provider endpoint that you configure and control. Cribl blocks requests to the Cribl AI backend at the platform level, so a misconfiguration cannot route data outside the boundary.

Cribl writes an audit log entry for each change to AI configuration, including provider creation and deletion, feature toggles, detection model selection, and MCP server changes. Review these entries as part of your normal audit process.

FedRAMP authorization applies to a defined system boundary and control baseline. Cribl AI capabilities that ship commercially are not automatically available in Cribl.Cloud Government: each one must first complete the applicable security assessment and change process. Expect new and expanded AI capabilities, including additional Custom AI Provider types such as Google Gemini, to reach Cribl.Cloud Government later than commercial Cribl.Cloud.

Cribl Guard in Cribl.Cloud Government ​

Cribl Guard is offered in Cribl.Cloud Government for eligible licenses. Enterprise licensing rules align with commercial: Guard requires an Enterprise license, and Cribl.Cloud Government does not offer the lower tiers where Guard is unsupported.

Guard capabilities that you configure manually, such as detection, rules, and workflows, behave the same as in commercial Cribl.Cloud.

Background detection is available in Cribl.Cloud Government. It runs locally on the Worker Node using regex rules and an in-house named-entity-recognition (NER) model rather than an LLM. It sends no event data to your AI provider or to any external inference service.

Background detection needs no Custom AI Provider. Turn it on per Pipeline and it runs, whether or not a provider is configured.

Cribl.Cloud Government provides one approved detection model. Because only one model is available, the Detection model control at the top of the Guard page displays that model as a static label rather than a drop-down.

Guard capabilities that do call an LLM use the same Custom AI Provider. These include rule-building assistance and the Analyze detections workflow, which classifies findings and suggests mitigations after detection runs. See AI in Cribl.Cloud Government.