Korium stores memory for AI agents, which means it can hold sensitive, free-text content. Security is not a feature bolted on afterward - it is the design. This page summarizes the technical and organizational measures we use to protect your data. It reflects our production architecture and is the security description referenced in our Data Processing Addendum.
Every customer’s memory is a database-sealed tenant that even our own application role cannot read across; data is encrypted in transit and at rest; and the models that read your content for extraction and embedding run inside our own environment - your content is not sent to third parties for those steps, and is never used to train foundation models.
Each organization’s brain is its own tenant, isolated at the database layer with PostgreSQL FORCE ROW LEVEL SECURITY, combined with an application-level tenant bind for defense in depth. The application’s database role cannot bypass the row-level filter, and a continuous-integration guard blocks any query that is missing its tenant scope. There is no memory visibility between customers, and no standing path for us to read a customer’s brain.
Data is encrypted in transit with enforced TLS across all connections, including to the database and cache. Data is encrypted at rest using customer-managed keys (AWS KMS) across the database, object storage, and cache tiers.
We keep sensitive content out of places it doesn’t belong. A strict input-isolation rule prohibits memory content, extracted entities, relations, and embeddings from appearing in any log line, at any level - enforced by a runtime alarm and by code review. Entity extraction (a GLiNER model) and vector embedding (a self-hosted Ollama model) both run inside our own AWS environment; your content is not sent to any third party for those steps. The only external AI service is the managed model used for higher-level memory cognition, which is contractually prohibited from training on your content.
We maintain centralized audit logging and cloud-native threat detection and data-activity monitoring, with alarms on authentication and replay-attack signals. Dependencies are continuously monitored for known vulnerabilities (Dependabot), and penetration testing is performed periodically.
The production database runs across multiple availability zones with automated backups and deletion protection. Our change process is forward-only and change-controlled, so recovery and rollback do not depend on destructive operations.
We use a small, vetted set of subprocessors, each under a data-protection agreement. The current list, with purpose, location, and transfer safeguards, is published on our Subprocessors page.
Our controls are designed to align with the security requirements of the GDPR (Article 32) and the control families of SOC 2 and the FTC Safeguards Rule. We have not yet completed a formal third-party certification; independent certification (e.g. SOC 2) is on our roadmap, and we will state its status here honestly rather than imply a certification we do not hold. Customers with specific assurance needs can contact us to discuss current documentation.
If you discover a vulnerability or suspect a security incident, please contact us promptly at reports@kyroco.ai. For customer data we process on your behalf, we will notify affected customers without undue delay, and in any event within 72 hours of becoming aware, consistent with our Data Processing Addendum.
