Last updated: 27 September 2026
This page describes our security controls in detail. If you are evaluating whether Keply can be connected to your systems, start with Trust instead, which sets out exactly what Keply reads, what it stores, who else processes it, and how to revoke or delete it. This page is the drill-down behind that summary.
We follow least privilege for access to our own systems, and access is removed when it is no longer needed. Administrative access to the systems that run Keply, our cloud database, our hosting and DNS, and our source control, requires multi-factor authentication. Within the product, each organization's data is reachable only by that organization's members, enforced at the database layer rather than only in application code. Roles determine what a member can see and do.
Keply is multi-tenant. Isolation is enforced by deny-by-default row-level security scoped to the organization, applied to every application table, and backstopped by organization scoping in the application layer. A query issued in one organization's session cannot return another organization's rows.
All data is encrypted in transit (TLS 1.2+) and at rest (AES-256). Integration access tokens are encrypted with an application-managed key using AES-256-GCM and are never stored in plaintext. API keys we issue are stored only as hashes, so they cannot be recovered from the database, only verified. Application secrets are held in managed secret stores and never committed to source control; our automated static analysis includes a secret-detection ruleset that runs on pull requests, pushes to the production branch and a weekly schedule.
Context sent to our AI provider is processed under commercial terms that prohibit training on your data. Scores are expected to cite the concrete signals behind them. The autonomy dial, what Keply stores, and what leaves it are described on Trust.
All application code, database migrations, CI workflows and configuration are version-controlled, and no change reaches production except through a commit. Changes are developed on a branch; deployable changes are validated on staging first. The production branch is protected: it cannot be pushed to directly or force-pushed. Changes land through pull requests with eight required check contexts. Applicable checks must pass; jobs unrelated to the change may be skipped. The available checks cover lint, type checking, unit tests, edge-function tests, database integration tests, a production build, full migration replay against a clean database, static analysis including secret detection, and dependency vulnerability scanning. The scope check fails closed when it cannot safely determine which jobs apply. These protections apply to administrators as well, so there is no routine path around them. Every deployment to production re-runs lint, type checking, a model-quality evaluation gate and a production build before it ships, and a post-deploy check verifies the live site. Database changes ship as versioned, ordered migrations.
Agent actions are recorded in an audit log, and operational events are recorded and surfaced by a watchdog that runs on a schedule. We maintain a written incident response plan that defines severity levels, the response runbook, and notification obligations, including the GDPR 72-hour breach-notification clock. Suspected incidents and vulnerability reports go to ori@keply.ai and are triaged on receipt.
Keply runs on Supabase (database, authentication, storage, edge functions) and Cloudflare (hosting, CDN, TLS, WAF). Both maintain their own SOC 2 and ISO 27001 attestations and are responsible for physical and infrastructure security. The database is backed up daily, with seven days of snapshots retained. Application code and configuration are reproducible from the commit history.
We process personal data in line with the EU/UK GDPR and the Israeli Privacy Protection Law. Our Privacy Policy sets out the lawful bases we rely on and the rights available to individuals, and our Data Processing Addendum governs our processing on your behalf. Requests relating to personal data, including access, correction and deletion, go to ori@keply.ai; the procedure and timelines we work to are set out in our internal data-subject-rights procedure. Analytics consent is honored server-side, so opting out stops collection rather than merely hiding it.
Our controls are documented in a written policy set and a control matrix mapping each control to the Trust Services Criteria it addresses. It covers information security, access control, encryption and key management, secure development and change management, vulnerability and patch management, logging and monitoring, incident response, backup and data retention, vendor and third-party risk, data classification, data protection and privacy, data-subject rights, business continuity, and acceptable use. Each control carries an honest maturity marker, so a control that is partial or planned is labelled as such rather than presented as complete.
We will share this documentation and complete a security questionnaire on request, without requiring an NDA. Email ori@keply.ai.
Keply does not hold a SOC 2 report. Our controls are self-assessed. Keply has not completed an independent third-party SOC 2 examination, and a SOC 2 report can be issued only by a licensed CPA firm following one. We will update this page if and when one is issued.
What we do have is an information-security program designed and operated to align with the Trust Services Criteria for Security, Availability and Confidentiality established by the AICPA for SOC 2. The design and operation of those controls are documented in our control matrix and assessed by us against those criteria. Nothing on this page should be construed as a statement that an independent SOC 2 audit has been performed.
If you believe you have found a security issue, please email ori@keply.ai with details. We appreciate responsible disclosure and will acknowledge your report.