> For the complete documentation index, see [llms.txt](https://docs.cleric.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cleric.ai/security/security-data-privacy.md).

# Security & Data Privacy

Cleric uses **read-only access** to your environment, guaranteed by RBAC or access scopes supported by each system. Cleric does not make changes to customer infrastructure but may propose them. All remediation actions are performed by your team.

You control what Cleric can access across Observability (logs, metrics), Infrastructure (Kubernetes, cloud providers), Code, and Documentation.

Cleric is SOC 2 Type II certified. The report, as well as our policies, pentest reports, and security program details are available in our [Trust Center](https://trust.cleric.ai). Annual penetration tests are performed by external security firms; the most recent was completed Q3 2025.

## Data Access

### What Cleric Can Access

Minimum access required for investigation:

* **Logs & Metrics**: Infrastructure and application logs and time-series telemetry via observability APIs ([Datadog](/integrations/supported-integrations.md#datadog), [Prometheus](/integrations/supported-integrations.md#prometheus), etc.)
* **Kubernetes Metadata**: Read-only commands (`get pod`, `describe pod`, `get events`)
* **Alert Metadata**: Content from alerting systems ([PagerDuty](/integrations/supported-integrations.md#pagerduty), [Grafana](/integrations/supported-integrations.md#grafana))
* **Source Code**: Optional, can be scoped to single repository
* **Documentation**: Optional, from [Atlassian](/integrations/supported-integrations.md#atlassian-confluence--jira) or [GitHub](/integrations/supported-integrations.md#github)

Avoid exposing unnecessary personal data to Cleric. If you find personal data in Cleric investigations, contact us via <support@cleric.ai> or your dedicated Slack Connect channel to filter or disable specific data sources.

### Data Storage and Retention

Cleric stores investigation data: queries executed, reasoning traces, and responses delivered to your team. Your data (e.g. logs, metrics, traces, code) is queried at runtime and not persisted by Cleric.

* **System logs**: 30 days
* **Application logs**: 120 days (configurable per customer requirements)
* **On-demand deletion**: Request in writing, processed within 2 business days with confirmation

### Self-Learning and Tenant Isolation

Cleric distinguishes between product improvement and self-learning. Both improve Cleric's behavior, but they use different data flows and storage boundaries.

#### Product Improvement Data Flow

Cleric product improvements are built from execution telemetry. Tenant agent systems emit telemetry one way to a centralized profiler. Profiler output is analyzed to produce agent updates, and those updates are deployed back to each tenant. Tenant agent systems do not pull customer data, tenant memory, or investigation context from the profiler.

```mermaid
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#F7F7F5', 'primaryBorderColor': '#D7D7D4', 'primaryTextColor': '#313131', 'lineColor': '#6B6B6B', 'clusterBkg': '#EBF0FA', 'clusterBorder': '#C2D0EB', 'fontFamily': 'Inter, Inter Fallback, system-ui, arial'}, 'flowchart': {'curve': 'basis', 'rankSpacing': 65, 'subGraphTitleMargin': {'top': 10, 'bottom': 10}}, 'themeCSS': '.nodeLabel, .nodeLabel p, .edgeLabel .labelBkg, .edgeLabel .labelBkg p { font-family: Inter, Inter Fallback, system-ui, arial !important; } .edgeLabel .labelBkg, .edgeLabel .labelBkg p { background-color: #D8DFEF !important; } .edgeLabel .labelBkg, .edgeLabel .labelBkg span, .edgeLabel .labelBkg p { color: #6B6B6B !important; font-size: 13px !important; }'}}%%
flowchart LR
    subgraph Tenants["Tenant agent systems"]
        A("Tenant A")
        B("Tenant B")
        C("Tenant C")
    end

    P("Centralized profiler")
    R("Agent updates")

    A -. "One-way telemetry" .-> P
    B -. "One-way telemetry" .-> P
    C -. "One-way telemetry" .-> P
    P --> R
    R --> A
    R --> B
    R --> C

    classDef tenant fill:#FFFFFF,stroke:#D7D7D4,color:#313131
    class A,B,C tenant
    style Tenants color:#3967C8,rx:8px,ry:8px
```

#### Self-Learning Data Flow

Self-learning happens inside each tenant. Within the tenant boundary, the Agent System writes and reads operational Memory, including infrastructure context, prior investigation outcomes, team playbooks, and engineer corrections. That Memory is scoped to the dedicated customer instance and database. Customer A's Memory is not copied into Customer B's tenant, and tenant Memory is not promoted into a shared model.

```mermaid
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#F7F7F5', 'primaryBorderColor': '#D7D7D4', 'primaryTextColor': '#313131', 'lineColor': '#6B6B6B', 'clusterBkg': '#EBF0FA', 'clusterBorder': '#C2D0EB', 'fontFamily': 'Inter, Inter Fallback, system-ui, arial'}, 'flowchart': {'curve': 'basis', 'rankSpacing': 75, 'nodeSpacing': 53, 'subGraphTitleMargin': {'top': 10, 'bottom': 10}}, 'themeCSS': '.nodeLabel, .nodeLabel p, .edgeLabel .labelBkg, .edgeLabel .labelBkg p { font-family: Inter, Inter Fallback, system-ui, arial !important; } .edgeLabel .labelBkg, .edgeLabel .labelBkg p { background-color: #F8F8F8 !important; } .edgeLabel .labelBkg, .edgeLabel .labelBkg span, .edgeLabel .labelBkg p { color: #6B6B6B !important; font-size: 13px !important; } .edgeLabel { translate: 0 -14px; }'}}%%
flowchart LR
    subgraph TenantA["Tenant A"]
        AgentA("Agent System")
        MemA("Memory")
        AgentA --> MemA
        MemA --> AgentA
    end

    subgraph TenantB["Tenant B"]
        AgentB("Agent System")
        MemB("Memory")
        AgentB --> MemB
        MemB --> AgentB
    end

    subgraph TenantC["Tenant C"]
        AgentC("Agent System")
        MemC("Memory")
        AgentC --> MemC
        MemC --> AgentC
    end

    TenantA <-. "No access" .-> TenantB
    TenantB <-. "No access" .-> TenantC

    classDef tenant fill:#FFFFFF,stroke:#D7D7D4,color:#313131
    class AgentA,MemA,AgentB,MemB,AgentC,MemC tenant
    style TenantA color:#3967C8,rx:8px,ry:8px
    style TenantB color:#3967C8,rx:8px,ry:8px
    style TenantC color:#3967C8,rx:8px,ry:8px
```

Cleric may use the tenant's operational memory as context for future investigations in that same tenant but has no access to other tenant memory.

## Model & Inference Privacy

### No Model-Training Risk

* Your data is **never** used to train or fine-tune models
* Enterprise LLM APIs include contractual zero-data-training and zero-data-retention guarantees
* All AI agent actions are logged and auditable

### Where Models Run

* LLM providers: Anthropic, Google Gemini, and OpenAI
* Model calls route from your isolated Cleric instance to provider enterprise API endpoints

## Platform Security

Cleric is a **single-tenant SaaS solution** with complete isolation between customers.

### Architecture & Isolation

* **Dedicated Infrastructure**
  * Isolated compute with network boundaries per customer
  * Dedicated instance (frontend and backend)
  * Dedicated PostgreSQL database per customer (not publicly accessible)
  * Customer-specific domain (`<your-company>.app.cleric.ai`)
  * Data encrypted at rest using AES-256
* **Hosting**
  * GCP `us-east4` by default, alternative regions on request
* **Infrastructure as Code**
  * 100% Terraform-managed infrastructure
  * All changes subject to automated CI/CD checks and security scans
  * No direct production server access via SSH or similar protocols

### Network Security & Egress

* **Encryption in Transit**
  * TLS 1.2 or higher for all external connections
  * Internal service-to-service communication encrypted
  * Managed certificates
* **Static Egress IP**
  * Dedicated static egress IP per instance for allowlisting
* **Compromise Detection**
  * Monitors infrastructure for suspicious activity (privilege escalation, secret changes, IaC bypasses)
  * Centralized alerts reviewed by security on-call

### Internal Access Controls

* Only Engineering team members have production access
* Multi-factor authentication (MFA) required for all production systems
* User access reviews performed at least annually

### Availability & Recovery

* **Backups**: Automated daily backups with point-in-time recovery. Seven daily backups retained, encrypted, and stored in multi-region location.
* **High availability**: Multi-zone GKE clusters. Cloud SQL PostgreSQL with 99.95% availability SLA

### Security Monitoring & Incident Response

* **Automated Security Scanning**
  * Semgrep for static code analysis
  * Grype for dependency and container image vulnerability scanning
  * Checkov for infrastructure-as-code misconfiguration detection
  * gitleaks for secret detection
  * GitHub Dependabot for dependency vulnerabilities
  * Oneleet for cloud security monitoring
  * Vulnerability remediation SLA: High/Critical within 7 days
* **Incident Response**
  * Security incidents escalated to <security@cleric.ai>
  * Customer notification within 24 hours for critical incidents affecting customer data
  * Post-incident review within 5 business days for medium to critical incidents

## Contact

* **General inquiries**: <support@cleric.ai>
* **Security incidents**: <security@cleric.ai>
