Security Overview

Reviewers rarely read a security document front to back on the first pass. The table below maps each control domain to how Kavanah addresses it and where in this document the detail lives, so a questionnaire can be answered by jumping straight to the relevant section.

Kavanah runs as a serverless application on Vercel, backed by a managed Neon Postgres database. Both providers operate SOC 2-audited data centers with physical security, redundant power, and encryption at rest enforced at the infrastructure layer. We do not operate our own physical servers.

Compute runs on isolated, per-request function instances; there is no long-lived shared application host that could retain one customer's data in memory across another customer's request. A full inventory of the vendors that process customer data is published on our Sub-processors page.

Production data is processed in the United States. The component inventory, data flows, and trust boundaries of this infrastructure are documented on the Architecture Overview and, at specification level, in the Technical Data Sheet; how it is recovered after a disruptive event is documented in the Disaster Recovery & Business Continuity Plan.

User authentication

Passwords are hashed with bcrypt and never stored or logged in plaintext. Sessions are issued as signed JWTs with server-side validation on every request. Kavanah supports:

• Single sign-on (SSO) via SAML 2.0 and OIDC for enterprise identity providers.
• Multi-factor authentication (MFA) with TOTP authenticator apps.
• SCIM directory sync, so that joiner, mover, and leaver events in your identity provider propagate to workspace membership rather than depending on a manual step.
• OAuth sign-in with Google, GitHub, and other supported providers.

Authorization

Access within a workspace is governed by role-based permissions (owner, admin, member, and client-portal roles). Administrative and AI-agent capabilities are further constrained by granular permission scopes, so an account — human or automated — can only reach the surfaces it is explicitly granted.

Below the role level, access can be narrowed further: per-project and per-task access control lets a workspace restrict a sensitive engagement to a named subset of members, rather than making membership of the workspace equivalent to visibility of everything in it. The same checks apply to automated access — an AI agent acting on a member's behalf inherits that member's scope and cannot reach a project the member cannot.

Kavanah is a multi-tenant application in which every customer's data lives under a workspace boundary. Every workspace-scoped database query is required to filter by workspace_id. This is not left to reviewer discipline: a continuous-integration linter scans the codebase on every change and fails the build if a query against a workspace-scoped table is missing its tenant filter. Any exception must be explicitly allow-listed with a written justification. This control has already caught and closed real cross-tenant issues before release.

• Immutable audit logs. Security-relevant read, write, and administrative actions are recorded to an append-only audit log whose immutability is enforced by database triggers, with configurable retention (7+ years) to satisfy long-tail compliance requirements.
• Health monitoring. Platform health and every scheduled background job are monitored through a dedicated health endpoint and cron-health registry that alerts on missed or failing jobs.
• Legal hold & eDiscovery. Deletion of specific users, projects, or workspaces can be frozen under litigation hold, with search and export across messages, tasks, and audit logs.

Customer data is stored in a managed Postgres database with automated, continuous backups and point-in-time recovery. Restore procedures are documented in an operational runbook and exercised on a recurring restore drill — because a backup that has never been restored is not a backup. Our target recovery objectives (RPO and RTO), the backup design, the disaster scenarios we plan against, and the continuity of the business itself are documented in full in the Disaster Recovery & Business Continuity Plan. Support response targets during an incident are stated by severity in the SLA.

• Version-controlled change management with peer review before merge.
• Automated CI on every change: type checking, unit tests, linting, SQL and tenant-scoping checks, and idempotent migration verification.
• Dependency and platform patching on a managed, continuously updated runtime.
• Least-privilege access to production systems, scoped to the engineers who require it.

Patching

Kavanah runs on a managed, continuously updated runtime. Operating-system and platform-level patching is performed by the infrastructure provider on its own cadence, which means there is no fleet of Kavanah-operated servers waiting on a maintenance window and no patch backlog attributable to us. Application dependencies are updated on an ongoing basis, and a dependency update is not a special case: it passes through the same continuous-integration gate as any other change — type checking, unit tests, linting, the SQL and tenant-scoping linters, and migrations applied twice — before it can reach production.

Remediation

Findings — whether from a dependency advisory, a penetration test, an internal review, or an external report — are prioritized by severity. Critical and high-severity issues take precedence over planned feature work and are tracked to closure; lower-severity issues are scheduled into normal engineering work. Where a fix cannot be shipped immediately, a compensating control or temporary mitigation is applied in the interim rather than accepting the exposure silently.

Independent testing

Kavanah commissions an annual third-party penetration test covering the external network surface and the application. The executive summary, including remediation status, is available to security teams under NDA through the Trust & Compliance page.

Coordinated disclosure

Externally reported vulnerabilities enter the same severity-based remediation process. How to report one, and the good-faith protections that apply to researchers, are set out under Vulnerability reporting below.

Detection

Kavanah does not rely on a single signal to learn that something is wrong. Detection sources are:

• The platform health endpoint — continuously checked, and the basis on which availability is measured for the SLA.
• The cron-health registry — every scheduled background job is registered with its expected interval, so a job that stops running is detected as an absence, not only as an error.
• Provider alerting— platform and database provider notifications for infrastructure-level faults and degradations.
• The audit log— the immutable record of security-relevant actions, used both to surface anomalous administrative activity and, after the fact, to establish precisely what was accessed, by which principal, in which workspace.
• Inbound reports— from customers via support and from security researchers at security@kavanah.ai.

Severity

Incidents are triaged against the same severity ladder used in the SLA and in the continuity plan, so one classification drives support response, engineering escalation, and communication rather than three different ones:

Response phases

• Containment.Limit the blast radius first — revoke or rotate affected credentials, disable an affected integration or feature, or roll back a deployment — before diagnosis is complete.
• Eradication. Remove the cause rather than the symptom: ship the fix, rotate the keys, close the path. Removal is verified, not assumed.
• Recovery. Restore normal service and confirm it. Where data recovery is involved, the restore and smoke-test path in the Disaster Recovery & Business Continuity Plan applies — a restore is not accepted until the application has been exercised against the restored database.
• Post-incident review. A written review of what happened, why, and what changes as a result. A material incident updates the operational runbook and the published plans, not only the incident ticket.

Customer notification

Affected customers are notified by email at the workspace owner and any security or operations contacts on record. Security incidents affecting customer personal data are notified in line with the Data Processing Addendum and applicable law — without undue delay after Kavanah becomes aware, and carrying the information a customer acting as controller needs to meet its own regulatory deadlines. See the DPA for the exact obligations.

• Hiring. Personnel are screened with background checks appropriate to the role and to what that role can reach, conducted where permitted by applicable law.
• Security awareness. Everyone with access to production systems or customer data is expected to understand the controls in this document and the handling rules that apply to customer data. Those expectations are set at onboarding and reinforced whenever the controls change.
• Least-privilege production access. Access to production systems and data is not a default of employment. It is granted only to the engineers whose role requires it, and only to the systems that role requires.
• Access review and revocation. Access is reviewed on a recurring basis and revoked on role change or departure, so a permission granted for one role does not survive into the next one.
• Confidentiality. Employment and contractor agreements carry written confidentiality obligations covering customer data, and those obligations survive the end of the engagement.

For accuracy: Kavanah is a small team, and this document does not claim a separate security function or around-the-clock security operations staffing. Accountability for the controls described here sits with engineering leadership, and the technical controls are deliberately designed to be enforced by automation — the tenant-scoping linter, the CI gate, the database-enforced audit immutability — rather than by headcount.

Kavanah deliberately keeps its vendor list short: every additional processor is additional surface, an additional place customer data can sit, and an additional party a customer has to accept.

• Selection.A vendor that will process customer data is evaluated against its own security posture before adoption — its audited controls, encryption in transit and at rest, data location, subprocessing, and the contractual terms it is willing to offer.
• Published and maintained. The full inventory of vendors that process customer data is published on the Sub-processors page and kept current, and customers are notified of material changes so they can exercise the objection rights their DPA provides.
• Integration access is the customer's to grant and revoke. Kavanah's integrations with third-party systems are connected by the customer through the provider's own consent flow, request the narrowest scopes the feature needs, store their credentials encrypted at the application layer under a per-workspace subkey, and can be disconnected by the customer at any time — which revokes Kavanah's access to that system.
• AI providers. What reaches an AI provider, what it may be used for, and our no-training posture are documented separately on the AI Transparency page.

Workspace data is owned by the customer. Kavanah acts as a data processor and does not sell personal information. We support GDPR and CCPA data-subject requests — export or erasure of an individual's data — which workspace owners can initiate from Settings → Data Governance. A Data Processing Addendum (with Standard Contractual Clauses for international transfers) is available for customers who require one. See our Privacy Policy for full detail.

Kavanah embeds AI features. How customer data is (and is not) used by the underlying AI providers — including our no-training posture — is documented separately on the AI Transparency page.

A reviewer's time is wasted by a vendor that blurs “in progress” into “certified.” The table below states exactly where each framework stands. Where something is not yet achieved, this page says so.

Kavanah does not hold FedRAMP authorization, a PCI-DSS attestation, or ISO/IEC 27017 or 27018 certification. If your process requires one of these, raise it early rather than late — we would rather tell you up front than discover it at contract stage.

Artifacts that are shared under NDA — the SOC 2 report once available, the penetration-test summary, and completed SIG or CAIQ questionnaires — can be requested through the Trust & Compliance page.

We welcome reports from security researchers. If you believe you have found a vulnerability, email security@kavanah.ai with the details and steps to reproduce. We investigate all good-faith reports and will not pursue action against researchers who act responsibly and avoid privacy violations or service disruption.