Privacy & Security
Data handling, LLM providers, tenant isolation, session management, and access control for groundcover Agent Mode
Agent Mode requires cloud LLM access. Some deployment types require additional setup. See Requirements & Compatibility.
LLM Provider
The groundcover Agent uses cloud provider LLM services for inference. The specific provider depends on your deployment type:
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
Not currently supported
On-premises (AWS)
AWS Bedrock - Anthropic Claude models (provisioned by groundcover)
On-premises (GCP)
Google Cloud Vertex AI - Anthropic Claude models (provisioned by groundcover)
Both providers share the same 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-region - requests are processed within your configured cloud region
For provider-specific security documentation:
AWS Bedrock: AWS Bedrock Security
Google Cloud Vertex AI: Vertex AI Data Governance
What Data Reaches the LLM
When you ask the Agent a question:
Your prompt, current session context, and UI context (page, filters, time range) are sent to the Agent service running within your groundcover deployment
The Agent service queries your telemetry data (logs, traces, metrics) through internal APIs
Relevant query results are passed to the LLM to generate analysis
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.
AI Features settings - Admins can enable or disable AI features per backend from Settings > Preferences > AI Features. 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