For the complete documentation index, see llms.txt. This page is also available as Markdown.

Privacy & Security

Data handling, LLM providers, tenant isolation, session management, and access control for groundcover Agent Mode

Agent Mode requires access to a supported LLM endpoint. Some deployment types require additional setup. See Requirements & Compatibility.

LLM Provider

The groundcover Agent uses a supported LLM provider for inference. The provider depends on your deployment and selected configuration:

Deployment
LLM Provider

groundcover Cloud (default)

AWS Bedrock - Anthropic Claude models

BYOC AWS

AWS Bedrock - Anthropic Claude models

BYOC GCP

Google Cloud Vertex AI - Anthropic Claude models

BYOC Azure

Microsoft Foundry - Anthropic Claude models

On-premises (AWS)

AWS Bedrock - Anthropic Claude models (provisioned by groundcover)

On-premises (GCP)

Google Cloud Vertex AI - Anthropic Claude models (provisioned by groundcover)

On-premises (Azure)

Microsoft Foundry - Anthropic Claude models (provisioned by groundcover)

On-premises (other)

Anthropic API - Anthropic Claude models (your API key)

You can override the deployment provider for an individual backend from Settings > AI & Agents > Management:

Override
Request destination

Anthropic Key

Anthropic's API, authenticated with your Anthropic API key

Custom Anthropic Domain

The Anthropic-compatible endpoint you configure, such as a LiteLLM or Bifrost proxy

Data handling for Anthropic Key follows your Anthropic agreement and account settings. Data handling for Custom Anthropic Domain follows the policies of your proxy and its upstream model provider. See Configuring Settings for custom endpoint setup and Anthropic API key for direct Anthropic setup and key rotation.

When you use Native Cloud Provider, the cloud-provider services listed above share the following data handling guarantees:

  • No model training on your data - your prompts and telemetry data are not used to train or improve the underlying models

  • No data retention - inputs and outputs are not stored by the LLM provider beyond the request lifecycle

  • Data stays in your cloud account - requests are processed within your configured cloud account. For BYOC AWS and BYOC GCP, inference runs in the same region as your cluster. For BYOC Azure, Anthropic models on Foundry are only available in select regions and inference may run in a different region from your AKS cluster, but always within your Azure subscription (see Enable AI models for Agent Mode)

For provider-specific security documentation:

What Data Reaches the LLM

When you ask the Agent a question:

  1. Your prompt, current session context, and UI context (page, filters, time range) are sent to the Agent service running within your groundcover deployment

  2. The Agent service queries your telemetry data (logs, traces, metrics) through internal APIs

  3. Relevant query results are passed to the LLM to generate analysis

  4. The response streams back to your browser

Only the data needed to answer your specific question is sent to the LLM. The Agent does not send your entire dataset.

Tenant Isolation

All Agent operations are scoped to a single tenant. The Agent service enforces tenant boundaries at every layer:

  • All telemetry queries are executed against your tenant's data store - the Agent has no path to query data belonging to another tenant

  • Conversation history and session state are stored with a tenant identifier and cannot be accessed across tenant boundaries

  • LLM requests are constructed using only data from the requesting tenant's context

This means cross-tenant data access is not possible through the Agent, regardless of prompt content.

Session Management

Conversations are organized into sessions. Each session maintains its own isolated message history, which provides the Agent with context for follow-up questions and multi-step investigations.

  • Session TTL - sessions expire after 30 days of inactivity by default

  • Session cleanup - expired sessions and their associated message history are automatically deleted when the TTL is reached

  • Session scope - conversation history is scoped to the individual session; the Agent does not carry context between separate conversations unless you explicitly share or fork them

Starting a new conversation (Cmd/Ctrl+Shift+O) creates a new session with no prior context.

Conversation Storage & Data Retention

Conversation history is stored in a database within your groundcover deployment. This data is:

  • Scoped to the originating user and tenant - other users and tenants cannot access your conversation history

  • Retained for the duration of the session TTL (30 days of inactivity), after which it is deleted

  • Stored entirely within your own infrastructure in BYOC deployments

Access Control

Authentication - The Agent is only accessible to authenticated groundcover users. There is no anonymous or public access.

Permission scope - All queries the Agent executes run with your user-level permissions, not elevated or admin privileges. The Agent respects your existing groundcover RBAC configuration and can only access data your account is authorized to see.

Instructions and Skills - Personal Instructions and personal Skills are scoped to the user who created them. Org Instructions apply to everyone in the selected backend, and Organizational Skills are readable and usable across the organization. They do not grant additional data access: the Agent still follows the current user's RBAC permissions for every query and action.

AI & Agents settings: Admins can enable or disable AI features and choose an LLM provider per backend from Settings > AI & Agents > Management. See Configuring Settings for instructions.

Questions

Contact your groundcover account team if you have questions about data handling or want to discuss your organization's specific security requirements.

Last updated