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

Security & Data Privacy

Data access, retention, and platform infrastructure

Cleric uses read-only access to your infrastructure and observability tools, enforced by RBAC or the access scopes each system supports. Cleric does not make changes to customer infrastructure but may propose them. All remediation actions are performed by your team.

Some integrations also use write permissions so that Cleric can propose changes for your team to review, for example opening a pull request through GitHub or filing a Jira issue. Each section of Supported Integrations lists the permissions that integration needs and what Cleric uses them for. Cleric is instructed not to merge pull requests or push to your default branch. See the GitHub integration for the branch protection rule that enforces this.

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. 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, Prometheus, etc.)

  • Kubernetes Metadata: Read-only commands (get pod, describe pod, get events)

  • Alert Metadata: Content from alerting systems (PagerDuty, Grafana)

  • Source Code: Optional, can be scoped to single repository

  • Documentation: Optional, from Atlassian or GitHub

Avoid exposing unnecessary personal data to Cleric. If you find personal data in Cleric investigations, contact us via [email protected] 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, evidence extracts cited in findings, and responses delivered to your team. Raw data from your environment (e.g. logs, metrics, traces, code) is queried at runtime and not persisted.

  • 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.

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.

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

    • EU-hosted instances run the application, database, and model inference in Europe, with observability and analytics processed centrally in the US. See EU Hosting & Data Processing

  • 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 [email protected]

    • Customer notification within 24 hours for critical incidents affecting customer data

    • Post-incident review within 5 business days for medium to critical incidents

Contact

Last updated