How we think about trust.

Kairoi is a small senior firm building agentic systems that operate inside our clients’ businesses. That role comes with real responsibility for the data we handle, the credentials we hold, and the decisions our software makes on someone’s behalf. This page describes how we approach that responsibility: what is true now, what we’re honest about not yet having, and where you can read more.

Our security posture rests on two things: vendor diligence (we run on infrastructure built by enterprise providers whose security investment dwarfs anything a small firm could replicate alone) and architectural choices (we make specific decisions about how data moves through a system, who can access it, and where credentials live). We don’t use third-party certifications as a substitute for either.

---

Architectural commitments

These are real today: they describe how the platform is built, not how we wish we built it.

• Multi-tenant isolation. Every customer operates inside a workspace with team-level scopes and per-user accessor records. Database queries enforce tenancy at the data layer; cross-tenant access is impossible by construction, not by convention.
• Role-based access control. Permissions are scoped to workspace + team and enforced through declarative checks at the entry of each protected operation. Admins manage roles; the system reflects them in every request path.
• Server-side credentials only. No API keys, model-provider tokens, or secrets ever appear in client-bundled code. All sensitive operations happen on the server side.
• Encrypted secret storage. Credentials, OAuth tokens, and connector secrets are encrypted at rest using one of three drivers, selected per-deployment: a Postgres-backed store using AES-256-GCM, Microsoft Azure Key Vault, or Google Cloud Secret Manager. An application never sees plaintext secrets in memory longer than a single operation needs.
• TLS in transit; encryption at rest is provider-managed. All requests run over TLS. Data-at-rest encryption for the application database depends on the underlying database provider (Azure-managed when deployed on Azure infrastructure).
• Self-hosted JWT issuer. Sessions are issued and validated using an RSA key pair generated at deployment time. We do not depend on a third-party identity service for session integrity.
• OAuth2 single sign-on. Users authenticate through GitHub, Google, Microsoft Azure AD, or Auth0. Magic-link passwordless flow is available where SSO is impractical.
• Centralized model routing. Model selection is governed at the firm level. Administrators choose which model providers and which intelligence tiers are available within their workspace. Individual users do not pick raw models ad hoc; the platform routes through a controlled registry.
• Token usage and cost tracking. Every model call is logged with provider, model, token counts, and cost. This is what we can today describe as audit-grade. Full request/response audit trails for compliance use cases are on the roadmap, not in production. See “What we don’t yet have” below.

---

Our commitments to your data

These commitments are written into our privacy policy and apply to everyone who interacts with the website or the platform.

• We never sell, rent, or trade your data. Not to advertisers, not to data brokers, not to anyone.
• We never use your data to train external AI models. We work in AI; we don’t treat customer data as training material.
• Security incident notification. If a security incident affects personal information we hold, we’ll investigate promptly and notify affected people as required by law, with what we know.
• Prompt privacy-request response. We handle access, correction, and deletion requests promptly. If we can’t fulfill one, we’ll tell you why.
• Data deletion on request. Email info@kairoi.io and we’ll remove what we hold, except where we’re legally required to retain it.

---

Vendors and what they touch

The third parties below are the main services that handle data flowing through Kairoi. We’ve linked to each vendor’s own trust documentation so you can review their certifications directly.

Where things run. Our marketing site and Compass AI deployments run on managed cloud infrastructure and route across the model providers listed above. See the vendor table for specifics.

---

What we don’t (yet) have

Some trust pages list certifications they have. This section lists the ones we don’t. That information is more useful to a security reviewer than another lap around what we do.

• We do not currently have a published Data Processing Agreement template. For engagements where one is required, we negotiate directly.
• We do not maintain a public sub-processor list beyond the vendor inventory above. Engagement-specific sub-processor disclosure happens inside the engagement agreement.
• We have not yet commissioned a formal third-party penetration test against the platform. We have run internal threat-modeling and code-review passes; a formal external pen test is on the roadmap as adoption grows.
• Our request/response audit trail is scoped to model-call metadata (provider, model, tokens, cost). Full-fidelity audit logging across every protected operation is in development.
• Our rate limiting infrastructure is in place but not enabled by default. We turn it on per-deployment based on traffic patterns.

Our security posture today is the diligence we apply to vendor selection plus the architectural choices in how we run the platform, backed by the people running it. If you’d like to discuss a security review for a specific engagement, or you have a security question that isn’t answered here, email info@kairoi.io with subject line “Security question.”

---

Contact

For any trust, security, or privacy concern:

Email: info@kairoi.io
Subject line: start with “Security request” or “Privacy request”. That helps us route it to the right person.

Our privacy policy covers in detail what the website collects, how long we keep it, and the choices you have about it.