Security Measures

1. Encryption

In transit

• All communication between clients and the Service is encrypted using TLS 1.2 or higher.
• API endpoints enforce HTTPS; plaintext HTTP connections are rejected.
• Inter-service communication within our infrastructure uses mutual TLS (mTLS).

At rest

• All stored data — source code, indexes, embeddings, metadata, and backups — is encrypted at rest using AES-256.
• Encryption keys are managed through the cloud provider's key management service (KMS) with automatic rotation.

2. Access controls

• Access to production systems is restricted to authorized personnel using multi-factor authentication (MFA).
• Production access follows the principle of least privilege; access is granted only as needed and reviewed regularly.
• Customer data access by Keyes AI personnel requires explicit justification and is logged.
• API access is authenticated via scoped API keys with configurable, per-key permissions.

3. Tenant isolation

• Customer data is logically isolated at the engine level. Each tenant's repositories, indexes, and embeddings are inaccessible to other tenants.
• Isolation is enforced at the data layer, not solely at the application layer.
• Enterprise self-hosted deployments provide full physical isolation on customer-owned infrastructure.

4. Audit logging

• All API operations — reads, writes, commits, searches, and administrative actions — are logged with timestamps and identity.
• Logs include the identity of the actor (human or AI agent), the operation performed, and the resources accessed.
• Audit logs are retained for 90 days and available to account administrators through the dashboard.
• Enterprise customers may export audit logs to their own SIEM or log management system.

5. Infrastructure security

• The Service runs on Google Cloud Platform (GCP) infrastructure in secured, access-controlled data centers.
• Network perimeters are protected by firewalls, intrusion detection, and DDoS mitigation (Cloudflare).
• Production servers run hardened operating systems with automated patching.
• Infrastructure is provisioned as code and changes are reviewed before deployment.

6. Application security

• The GitDB engine is built in Rust, which eliminates entire classes of memory-safety vulnerabilities by design.
• Input validation and parameterized queries are enforced throughout the stack.
• Dependencies are scanned for known vulnerabilities and updated regularly.
• Code changes undergo peer review before deployment to production.

7. Data backup and recovery

• Customer data is backed up continuously to geographically separate storage.
• Backups are encrypted at rest using the same AES-256 standard as primary storage.
• Recovery procedures are tested regularly to ensure data can be restored within defined recovery objectives.

8. Incident response

• We maintain a documented incident response plan covering identification, containment, eradication, recovery, and post-incident review.
• In the event of a data breach affecting customer data, we will notify affected customers within 72 hours of becoming aware of the breach, as described in our Privacy Policy.
• Post-incident reviews are conducted for all significant incidents, and findings are used to improve our security posture.

9. Employee security

• All employees with access to customer data undergo background checks.
• Employees receive security awareness training on an ongoing basis.
• Access to production systems is revoked immediately upon employee departure.

10. Vulnerability management

• We conduct regular vulnerability assessments and penetration testing.
• Security researchers may report vulnerabilities to [email protected]. We commit to acknowledging reports within 48 hours.
• Critical vulnerabilities are prioritized and remediated promptly.