# Security at Kyroco

**Kyroco, LLC** - Korium · Last updated **September 11, 2026**

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](dpa.html).

The one-line version

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.

## Tenant isolation

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.

## Encryption

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.

## Access control & authentication

- **Least privilege & unique identities** throughout; no shared credentials.
- **Short-lived database credentials** (15-minute IAM tokens); no long-lived cloud access keys.
- **Deployments are OIDC-authenticated** from CI only, with separate production and development accounts fenced by service-control policies.
- **Mandatory passkeys (WebAuthn)** for access to the memory store; passwords are hashed with Argon2id; tokens are signed, rotated, and replay-rejected; per-account device limits apply.
- A **Zero Trust network tunnel** fronts administrative access; there is no public administrative ingress.

## Data minimization

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.

## Monitoring, logging & audit

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.

## Change control

Our change process is forward-only and change-controlled, so recovery and rollback do not depend on destructive operations.

## Subprocessors

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](subprocessors.html) page.

## Compliance posture

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.

## Reporting a security issue

If you discover a vulnerability or suspect a security incident, please contact us promptly at [reports@kyroco.ai](mailto: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](dpa.html).

Related policies

[Data Processing Addendum](dpa.html)

Processing terms, SCCs, and the full security annex.

[Subprocessors](subprocessors.html)

Who we use, where, and the transfer safeguards.