Data handling
Kepler processes the minimum data required to execute an authorized task. Customer source code remains customer-owned and is not sold or used for advertising.
Receive
Task inputs, repository context, and credentials are accepted only for the requested operation.
Isolate
Workloads execute in isolated environments intended to prevent cross-customer access.
Return
Results, logs, and code changes are returned through the authorized project workflow.
Retain or delete
Transient workspace data is removed after task completion; required account and audit records follow documented retention periods.
Encryption and access controls
Protection is applied across transport, storage, execution, and administrative access.
Data in transit
External connections use HTTPS with modern TLS. Non-encrypted application traffic is redirected or rejected at the edge.
Data at rest
Stored sensitive data is encrypted at rest using provider-managed or application-level encryption appropriate to the data class.
Secrets
Repository credentials and service tokens are kept separate from task output, scoped to authorized operations, and excluded from application logs.
Administrative access
Administrative surfaces are restricted to authorized operators through private network controls, authenticated tunnels, and least-privilege access.
Compliance roadmap
SOC 2 is planned. Kepler is not currently SOC 2 certified, and this roadmap is directional rather than a certification claim or guaranteed audit date.
Security control baseline
In progressDocument policies, system boundaries, data flows, owners, risk register, incident response, and evidence collection.
SOC 2 readiness assessment
PlannedComplete a gap assessment against the applicable Trust Services Criteria and remediate identified control gaps.
SOC 2 Type I examination
PlannedEngage an independent auditor after controls are designed, implemented, and supported by sufficient evidence.
SOC 2 Type II observation period
FutureEvaluate operating effectiveness over an observation period following successful readiness and Type I work.
Sub-processors
This provisional register identifies the service categories that may process customer data. Final provider names, processing locations, and supporting documentation will be published before production customer data is handled.
| Service category | Provider | Purpose | Potential data scope |
|---|---|---|---|
| Cloud and edge infrastructure | To be confirmed | Hosting, traffic delivery, and network protection | Account metadata, request metadata, encrypted application traffic |
| Compute and task execution | To be confirmed | Isolated execution of authorized development tasks | Source code, task instructions, generated output |
| Managed data storage | To be confirmed | Application records, configuration, and audit data | Account data, project metadata, encrypted credentials |
| Transactional communications | To be confirmed | Service notifications and account communications | Email address, name, delivery metadata |
| AI model processing | To be confirmed by workload | Code analysis and generation requested by the customer | Task instructions and the minimum relevant code context |
Material changes to the final register will be communicated through the product or the customer contact channel before the new provider begins processing covered data.
Responsible disclosure
Security researchers and customers are encouraged to report suspected vulnerabilities privately so they can be investigated and remediated before public disclosure.
Report a vulnerability
Security contact pending publication. Use the configured Kepler support contact in the interim.
Target acknowledgement: within two business days.
Include in the report
- Affected endpoint, component, or workflow
- Reproduction steps and proof of concept
- Observed and potential impact
- Any remediation suggestions or disclosure deadline
Please avoid privacy violations, service disruption, data destruction, social engineering, and accessing data beyond what is necessary to demonstrate the issue.