Security & Trust

Last updated: 2026-07-25

Klar analyses commercially sensitive data — revenue, customers, ads, payments and operations. We treat that responsibility as part of the product. This page explains how your data is handled, secured and controlled.

Your data stays yours

Klar is pushdown-first. For live databases and warehouses, your queries run inside your source and only the aggregated results return to Klar — we don't copy your whole database. For SaaS and file sources, only the data needed to build your dashboards is ingested, stored encrypted, and used solely to answer your questions.

How we handle your data

• Encryption everywhere. TLS 1.2+ in transit; AES-256 at rest (AWS RDS and object-storage encryption). Connection credentials are stored in AWS Secrets Manager with KMS-wrapped envelope encryption — never in application databases.
• Never used to train AI. Your data is queried only to answer your questions. It is never used to train AI models — ours or a provider's. Our AI provider (Anthropic) does not train on API data and retains requests for at most 30 days for safety review.
• Least access, read-only by default. Live-database connections use least-privilege, read-only credentials wherever possible. Our own application runs on a restricted database role, not an administrative one.
• Tenant isolation. Every workspace's data is isolated at the database level using PostgreSQL Row-Level Security, enforced by a least-privilege runtime role — one customer can never read another's data.
• Audit trail. Data-source access, dashboard changes and administrative actions are logged.
• Deletion & retention. You can disconnect a source or delete data at any time; connected-source data and OAuth tokens are removed on disconnect or account deletion. Automated database backups are retained for 7 days for disaster recovery.

Connecting your database

Klar connects outbound to your database from a fixed address. Nothing is required inbound — you never open a port to us, and Klar cannot be reached from your network.

Add that single address to your database firewall, security group, or — for Snowflake — your network policy, once. There is nothing to update afterwards. (Google BigQuery has no IP allowlist; it authenticates by service account instead, so this does not apply.)

Please treat an IP allowlist as a filter, not as authentication. It narrows who can attempt a connection; it does not establish who they are. Two things we ask for alongside it:

• A dedicated, read-only user for Klar — not a shared or administrative account. Klar never issues writes to your database.
• Access scoped to the schemas or tables you want analysed, rather than the whole instance. If Klar cannot see a table, it cannot query it, and neither can anyone who obtains the credential.

If your database has no public endpoint at all — typical for a database inside a private VPC — an IP allowlist will not help, and we should discuss the right connection method for your environment. Write to security@aeye-on.com.

Architecture

For warehouses and databases: queries travel to the source, aggregates return to Klar. Klar holds the metric definitions, dashboards and (for SaaS/file sources) the ingested rows needed to render your views — all encrypted, all scoped to your workspace.

Compliance & roadmap

We publish our Sub-processors, a Data Processing Agreement, our Privacy Policy and Terms of Service. We do not claim certifications we do not yet hold.

Reporting a vulnerability

If you believe you've found a security issue, please email security@aeye-on.com. We investigate all reports and will keep you updated. Please give us a reasonable opportunity to remediate before public disclosure.

Security questions: security@aeye-on.com