kvendra
·MENU

·LEGAL — SECURITY

Security.

How we protect the hosted Kvendra Cloud service and the credentials handled by the Kvendra CLI. This page describes what is in place today, including its limits.

Last updated: 2026-09-30 · Version 1.0

Kvendra is operated by Chronum LLC. This overview is informational: it describes our current security practices and does not change the Terms of Service or the Privacy Policy. Practices may evolve; we will update this page when they change materially.

§ 01 — Scope

This page covers the hosted Kvendra Cloud service (the web application at app.kvendra.cloud, the API at api.kvendra.cloud and the kvendra-cloud MCP server), the websites kvendra.com and kvendra.ai, and the open-source Kvendra CLI, which runs on your machine. Software you run on your own infrastructure (for example, a self-hosted Kvendra Platform engine) is secured by you.

§ 02 — Infrastructure and hosting

  • Kvendra Cloud runs on Amazon Web Services in the us-east-1 (N. Virginia) region, using managed services: API Gateway, AWS Lambda, Amazon Aurora PostgreSQL behind RDS Proxy, Amazon DynamoDB, Amazon S3, Amazon CloudFront, Amazon Cognito, AWS KMS and AWS Secrets Manager. The static website kvendra.com is served through CloudFront from a storage bucket in us-west-1.
  • The knowledge-base database runs in private subnets of a dedicated virtual network and is not publicly accessible. Network rules only allow database connections from the service's own functions, through the connection proxy.
  • We do not operate our own data centres or servers. Physical and environmental security of the underlying infrastructure is provided by AWS.

§ 03 — Encryption

In transit.

  • Our public endpoints are served over HTTPS only; plain HTTP requests are redirected to HTTPS. The API and the web application require TLS 1.2 or later.
  • kvendra.com, kvendra.ai and app.kvendra.cloud send HTTP Strict Transport Security (HSTS) with a two-year lifetime covering subdomains. kvendra.com and kvendra.ai have been submitted to the browser HSTS preload list.
  • Connections from the service to the knowledge-base database go through a proxy that requires TLS.

At rest.

  • The knowledge-base database (Aurora PostgreSQL), workspace files and knowledge-base exports are encrypted with a customer-managed AWS KMS key that we control, with automatic annual key rotation.
  • All DynamoDB tables and S3 buckets are encrypted at rest. Tables that hold account, credential and billing state use the customer-managed KMS key; the rest use AWS-managed encryption.
  • Service credentials (database, payment provider and similar) are stored in AWS Secrets Manager, encrypted with KMS, and are not kept in source code.
  • API keys are stored only as Argon2id hashes, never in plain text.
  • Vault backups uploaded by the Kvendra CLI are encrypted on your machine (AES-256-GCM) before they are sent. We store the ciphertext and cannot decrypt it.

§ 04 — Tenant isolation

  • Each Pro account and each Team workspace has its own separate PostgreSQL schema for its knowledge base. Every request runs in a database transaction scoped to that single schema.
  • The tenant is determined on the server from your verified identity token and, on Team plans, from your workspace membership record. It is never taken from parameters supplied in the request. Members whose access has been revoked or is still pending are refused.
  • Workspace files are stored under a per-tenant location. Download and upload links are issued only after the server has checked that you have access to that workspace and file.

§ 05 — Authentication and access control

Sign-in.

  • Accounts are managed with Amazon Cognito. You sign in with a verified email address and a password of at least 12 characters (with upper-case, lower-case and numeric characters), or with your GitHub account.
  • If you sign in with GitHub, we recommend enabling multi-factor authentication on your GitHub account.
  • AI tools such as Claude Code connect to the MCP server with OAuth 2.0 authorization code flow and PKCE (S256 required). Access tokens expire within 24 hours; refresh tokens expire after 30 days and can be revoked.
  • API keys can be rotated and revoked at any time.

Team roles.

  • Team workspaces have four roles: owner, admin, member and viewer. Workspace administration permissions are checked on the server, not only in the interface.
  • Only the owner can delete the workspace or manage its billing. The owner and admins manage membership and roles, read and export the workspace audit log, and approve changes to canonical knowledge-base entries.
  • Every change to a knowledge-base entry is recorded in its history (who, when and what changed), which workspace members can read.

Our access to Customer Data. We access Customer Data only as described in the Terms of Service: to provide the Service, to provide support you request, to protect the security of the Service, or where the law requires it.

§ 06 — Secrets and the Kvendra CLI

The Kvendra CLI is designed so that your AI agent can use your credentials (for GitHub, AWS, package registries and similar) without receiving them.

  • Local encrypted vault. Secrets are stored on your machine, encrypted with AES-256-GCM under a key derived from your master password with Argon2id (64 MiB, 3 passes). Vault files are readable only by your operating-system user. Your master password never leaves your machine, and Kvendra cannot recover it.
  • Broker. When the agent asks for an operation (for example a git push), the CLI's broker runs it and injects the credential directly into that command's process. The credential is not returned to the agent, and recognised credential formats are removed from command output before it reaches the agent.
  • Signed allowlists. Each credential can only be used for the operations, repositories, buckets or URLs you allow. Local allowlists are integrity-protected with a key derived from your master password; if an allowlist is missing, altered or unsigned, the broker refuses the operation.
  • Tamper-evident audit log. Every broker operation is recorded locally in a hash-chained log, so edits to past entries are detectable.
  • Escape hatch. Releasing a raw token to the agent is disabled by default. When you enable it, each use requires a stated reason, is limited per session and is flagged in the audit log.

Limits. A local, software-only vault cannot protect you from malware already running as your user while the vault is unlocked: such a process can read what you can read. Lock the vault when you are away and use short session lifetimes. The CLI source, its threat model and a plain-language description of what it does and does not protect are published in the kvendra-cli repository.

§ 07 — Application and web security

  • Our websites and the web application send security headers, including a Content Security Policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff and a strict referrer policy.
  • The Content Security Policy on kvendra.com and kvendra.ai does not allow inline scripts. Analytics on kvendra.com load only after you opt in (see the Privacy Policy).
  • Payments are handled by Stripe Checkout and the Stripe billing portal. We do not receive or store card numbers. Billing events from Stripe are accepted only with a valid Stripe signature.
  • Uploaded files are checked against size and file-type limits before they are accepted.

§ 08 — Secure development and supply chain

  • All code is kept in version control. Continuous integration runs linting, type checks and automated tests for the Kvendra Cloud service, the CLI and the Platform engine.
  • Dependencies are pinned with lockfiles. For the Kvendra CLI, CI also checks dependencies against the RustSec advisory database and a licence allowlist, and builds only from the locked dependency set.
  • Release images of the Kvendra Platform engine are signed and published with a software bill of materials (SBOM).
  • Security fixes ship with regression tests that reproduce the issue. In 2026, an external reviewer audited the Kvendra CLI; the findings were fixed in CLI 0.6.4 and described in a public security advisory.
  • Kvendra Cloud infrastructure is defined as code (AWS SAM templates) kept in version control.
  • We run internal security reviews of Kvendra Cloud and the CLI on an ongoing basis. The improvements they identify are scheduled and shipped in upcoming releases, listed in the changelog.

§ 09 — Logging and monitoring

  • Service logs and request traces are collected in Amazon CloudWatch and AWS X-Ray. AWS CloudTrail records administrative activity on our AWS account.
  • Automated alarms notify us of error spikes, latency breaches, encryption-key failures, database capacity limits and invalid payment-webhook signatures.
  • Operational logs, including request metadata and IP addresses, are used for security and troubleshooting, as described in the Privacy Policy.

§ 10 — Backups and continuity

  • The knowledge-base database is backed up automatically by AWS, with point-in-time restore over the previous 7 days.
  • DynamoDB tables that hold account, credential and billing state have point-in-time recovery enabled.
  • You can export your knowledge base at any time, including through the MCP export tool. Keep your own copies where you need them.
  • Retention after a subscription ends, deletion and backup rotation are described in the Terms of Service.

We do not currently offer a contractual uptime, recovery-time or recovery-point commitment.

§ 11 — Incident response and notification

When we detect or are told about a possible security incident, we investigate, contain it and fix the cause. If we confirm a security incident that affects your Customer Data or personal data, we will notify the affected account holders (for a Workspace, the workspace owner) by email without undue delay and no later than 72 hours after we confirm it, with the information we have about what happened and what we are doing, and we will meet the notification duties that apply to us under applicable law.

If you believe your account, API key or token has been compromised, revoke it and write to security@kvendra.ai straight away.

§ 12 — Vulnerability disclosure

If you find a vulnerability in any Kvendra product or service, please report it privately to security@kvendra.ai, with a description, steps to reproduce, the affected version or URL and any proof of concept that is safe to share.

  • We acknowledge reports within 72 hours and give you a remediation timeline within 7 days.
  • We follow coordinated disclosure: we agree a public disclosure date with you, typically 30 to 90 days after the fix, and credit you in the advisory unless you prefer to stay anonymous.
  • Safe harbour. We will not take legal action against research carried out in good faith under this policy that avoids privacy violations, data destruction and service degradation, and does not access or modify other people's data.
  • Out of scope: denial-of-service or load testing, social engineering, physical attacks, and issues in third-party dependencies (please report those upstream).
  • We do not run a paid bug-bounty programme.

The same policy is published as SECURITY.md in our public repositories.

§ 13 — Subprocessors

We use the following service providers to run Kvendra Cloud:

  • Amazon Web Services, Inc. (United States) — hosting, database, file storage, email delivery (Amazon SES) and search embeddings (Amazon Bedrock) for the content of your knowledge base.
  • Stripe, Inc. — payment processing and billing.
  • GitHub, Inc. — sign-in, only if you choose to sign in with GitHub.

The web application loads profile images from Gravatar using a hash of your email address. The AI model you connect to Kvendra (for example, Claude) is provided under your own agreement with the AI Provider and is not our subprocessor. Website analytics providers are listed in the Privacy Policy and do not receive Customer Data.

§ 14 — Compliance and certifications

Kvendra does not currently hold a SOC 2 report, ISO 27001 certification or any other third-party security certification, and we have not commissioned a penetration test of Kvendra Cloud. AWS maintains its own certifications for the underlying infrastructure; they do not certify Kvendra.

If your organisation needs to complete a security review, write to security@kvendra.ai and we will answer your questions based on the practices described here.

§ 15 — Shared responsibility

Security is shared between Kvendra and you. You are responsible for:

  • Your account credentials, API keys and tokens: use a strong, unique password, protect your GitHub account if you use it to sign in, and revoke keys you no longer need.
  • Who you invite to a Workspace and which role you give them, and removing members who no longer need access.
  • What you put in the knowledge base. Do not store passwords, API keys or other secrets in knowledge-base entries or files; keep them in the CLI vault.
  • The AI tools and models you connect, and the actions you authorise them to take (see the Terms of Service).
  • For the Kvendra CLI: your master password, your vault backups, keeping allowlists as narrow as possible, and the security of the machine where the CLI runs.
  • Anything you run on your own infrastructure, including a self-hosted engine.

§ 16 — Contact

Last updated: 2026-09-30. Version: 1.0.