Security & compliance FAQ

This page answers the questions vendor-risk reviews ask most, in the order most questionnaires ask them. Every section has a stable link, so a questionnaire can point at the exact answer. It describes how the platform works as of October 2026. For data flow and sub-processor detail see Data flow, Sub-processors and the Data handling FAQ. The documents available on request are listed on Trust & Security.

Cybersecurity

Identity and access management

• Single sign-on. Workspace admins can connect any SAML 2.0 identity provider (Microsoft Entra ID, Okta, Google Workspace, Ping, ADFS and others) and require it for their email domains. People who sign in through your provider join the workspace automatically with the default role you choose. See Single sign-on.
• Multi-factor authentication. When single sign-on is used, your identity provider's MFA and conditional-access policies apply to every sign-in. Email-and-password sign-in does not offer MFA itself, so organisations that require MFA should require single sign-on.
• Role-based access. Each workspace has four roles: owner, admin, member and viewer. Admins manage members, sign-in policy, models and integrations, and can grant or withhold specific rights per role; permission changes take effect on the next request. See Members and roles.
• Privileged access. Kumkuat operator access is limited to named staff and used only for support and incident response. Production infrastructure is administered through Google Cloud IAM.
• Sessions. A browser sign-in lasts up to seven days, after which the user signs in again. A configurable idle timeout is not offered today.
• API keys. Each key works for one workspace only, acts with that workspace's rights, and can be revoked by a workspace admin at any time.

Encryption

• In transit. Every connection uses TLS. The web application and API are HTTPS-only with HTTP Strict Transport Security, and database connections must be encrypted.
• At rest. The database, stored files and secrets are encrypted at rest by Google Cloud with AES-256 and Google-managed keys. OAuth tokens for document-library connectors are additionally encrypted by the application.
• Customer-managed keys. Customer-managed encryption keys are not offered today. Kumkuat is designed for public information and communications content, not for regulated data such as health, payment-card or government-ID data.

Network security

Kumkuat is a multi-tenant SaaS application on Google Cloud Run in us-central1. The only public application endpoints are the HTTPS web application and the HTTPS API. The application reaches the database over a private VPC connection. The database allows no public networks; administrative access is only through Google's IAM-authenticated Cloud SQL connector, over TLS. The web application sends a Content Security Policy and related security headers. Dedicated private connectivity for a single customer (VPN, Private Service Connect, IP allow-listing) is not offered today.

Logging and monitoring

Application and request logs are written to Google Cloud Logging. Every model-provider call is recorded per workspace with the provider, model and feature that made it (see Model provider controls). Availability, the background job queue and database connections have automated alerts that reach the engineering team. Customer-exportable audit logs and streaming to a customer SIEM are not offered today.

Vulnerability management

• An automated test suite of more than 6,000 tests must pass before any production release.

• A pre-commit hook refuses commits that contain credentials.

• Dependencies are pinned to exact versions and updated through normal releases.

• Google patches the managed runtime and database (Cloud Run and Cloud SQL).

• Dependencies are checked continuously against published vulnerability databases (GitHub Dependabot), which raises an alert and opens a security-update pull request for any affected package.

No third-party penetration test has been carried out to date, and static analysis of application code is not running today.

Incident response

Production alerts go to Kumkuat's engineering lead, who triages, contains and remediates. An incident that affects a customer's data is escalated to that customer's named account lead and to the customer's designated contacts. Customers are notified without undue delay, with the scope, impact and remediation, within the timeframe set in their agreement.

Reporting a vulnerability

Email security@kumkuat.ai. The same address is published in security.txt. Please include steps to reproduce, and do not access data that is not yours. See Report a vulnerability.

Hardware and installed software

None. Kumkuat runs in a web browser. Nothing is installed in your environment, and no devices, appliances or agents are added to it. The optional integrations (Slack, Claude Desktop, SharePoint, Google Drive) connect over standard OAuth or API keys that your administrators control.

Data and information management

Data classification

Data	Examples	Sensitivity
Public information	Public social posts and profiles of public figures, news articles, press releases, earnings-call transcripts	Public. Profiles of named people are still personal data under GDPR
Customer content	Drafts, messaging and documents your users paste or upload, and the outputs generated from them	Confidential to your organisation
Account data	User name and email address	Personal data

Kumkuat is not designed to process payment-card, health or government-ID data.

Data residency

All stored data is in the United States. The application runs in Google Cloud us-central1 (Iowa), the database is Google Cloud SQL in us-central1, and files are in Google Cloud Storage, US multi-region. Model-provider inference endpoints are not region-pinned. A workspace can run on its own provider keys and contracts instead; see Bring your own key.

Data retention and deletion

• Workspace data is kept for the life of the subscription, unless a workspace admin sets automatic expiry of chats, audience reactions and narrative test reports after a chosen number of days (7 to 3650) in Workspace settings → Data retention; see Data retention.
• A quick reaction test is not stored.
• A document a user deletes leaves the workspace immediately, and its stored file is destroyed automatically 30 days later.
• On request, a whole workspace is deleted, including its database records and stored files.
• Database backups expire after seven days, so deleted data leaves backups within that window.
• Model providers keep API content only under their standard API retention terms; no zero-data-retention addendum is in place.

Data ownership

Your organisation owns the content it submits and the outputs generated in its workspace. Kumkuat processes them only to provide the service and never uses them to train models. Your workspace owners and admins decide who has access. Kumkuat operates the platform and its catalogue of public-figure audiences. Contractual terms are set in your agreement.

Privacy regulations

Kumkuat processes publicly available statements by public figures and the content your users submit. It does not collect data about consumers. The privacy policy sets out what is collected, the lawful basis, retention, your rights and how a person in public life can ask to be removed; the terms of service govern use of the platform. Requests to access or delete data go to support@kumkuat.ai, and sub-processors are listed on the Sub-processors page.

Technology and platform

Hosting model

Software as a service, multi-tenant, with every customer workspace logically isolated and every database row keyed to a workspace. Infrastructure is Google Cloud: Cloud Run (application, API and background workers), Cloud SQL for PostgreSQL, Cloud Storage, Secret Manager and Identity Platform.

Technology stack

Layer	Technology
Application and API	Python, Flask, Gunicorn
Database	PostgreSQL 17 (Google Cloud SQL)
Front end	Server-rendered HTML with JavaScript
Model access	LiteLLM to Google Gemini, OpenAI and Anthropic
Packaging	Docker containers built by Google Cloud Build
Source control	GitHub

APIs and integrations

The platform's core features are available through a documented REST API with an OpenAPI specification; see the REST API and the API reference. An MCP server connects Claude and other agents (see Claude Desktop and Claude Code). API keys are scoped to one workspace. The SharePoint, OneDrive and Google Drive connectors are off by default, use read-only scopes and can be revoked at any time.

Scalability

The application, API and background workers are stateless containers that Cloud Run scales automatically with load. Long-running work, such as crawling, reaction tests and report generation, runs through a background job queue so interactive requests stay fast. Database storage grows automatically.

Resilience and operations

Availability

Cloud Run serves the application across the zones of the us-central1 region, and the API always keeps at least one instance running. The database is a single Cloud SQL instance protected by automated backups and point-in-time recovery. A standard uptime SLA is not published; any availability commitment is set in your agreement.

Disaster recovery

The database can be restored to any point in the previous three days, so the recovery point is measured in minutes. A full restore of the production database was carried out in September 2026, as part of moving it to Google Cloud SQL, and completed in under 30 minutes. The platform runs in a single region; cross-region failover is not offered today.

Backup and restore

What	How often	Kept for
Database (Cloud SQL automated backup)	Daily	7 backups
Database transaction log (point-in-time recovery)	Continuous	3 days
Stored files (Cloud Storage soft delete)	On every delete	7 days

Restores use Cloud SQL backup restore or a point-in-time clone. Application code is in GitHub and every released container image is kept in Artifact Registry, so any release can be rebuilt or redeployed.

Support and escalation

Every customer has a named account lead, with escalation to Kumkuat's engineering lead. Support is provided during US business hours. Response targets are set in your agreement.

Releases and patching

Kumkuat releases continuously. Every customer runs the current version and no customer action is needed. Each production release passes the automated test suite and a manual approval. Security fixes and dependency updates ship as part of normal releases. Notable changes are listed in the release notes.

Risk and vendor management

Sub-processors and external services

The sub-processors, their purpose, what each receives and a dated change log are on the Sub-processors page. Kumkuat also uses open-source components, chiefly Flask, SQLAlchemy and LiteLLM, and an open-source web-search library for discovering public sources. A full dependency list is available on request.

Software supply chain

Dependencies are pinned to exact versions in a lockfile and checked continuously for published vulnerabilities (GitHub Dependabot), and a pre-commit hook refuses commits that contain credentials. Container images are built from source by Google Cloud Build and stored in Artifact Registry. Provider keys and connector secrets live in Google Secret Manager, never in code or images. A software bill of materials and signed build attestations are not published today.

Compliance attestations

Kumkuat does not currently hold a third-party attestation of its own (SOC 2, ISO 27001 or a third-party penetration test). Kumkuat's infrastructure runs on Google Cloud, whose SOC 2 and ISO 27001 reports are available from Google. The policy documents available on request are listed on Trust & Security. The Control map shows, criterion by criterion, how the platform's controls line up against the SOC 2 Trust Services Criteria and ISO/IEC 27001:2022 Annex A.

Exit and data export

Your data can be exported through the REST API as JSON, and reports can be exported as PDF, PowerPoint and other formats (see Reports and exports). When a subscription ends, the workspace and its files are deleted on request, and backups expire within seven days.

Sustainability and lifecycle

Roadmap

Over the next 12 to 18 months Kumkuat will keep improving the product experience. No planned change affects how data is handled or secured. Recent and upcoming work appears in the release notes.

Deprecation and end of life

Kumkuat is a hosted service, so there is no on-premises version to retire. Features being retired are announced in the release notes before they are removed, and API changes are made additively where possible.

AI

Model training

Kumkuat trains no models of its own, and model providers are used on API tiers that do not train on content. See Is anything trained on my content?.

Model updates

Kumkuat uses models from Google, OpenAI and Anthropic through their APIs. The models in use are set in configuration and changed deliberately, never automatically by a provider. A workspace admin can choose the model per feature or turn a provider off; see Models and providers. A model change does not change how data is handled.

Safety and human oversight

• Read-only. No Kumkuat feature posts, publishes or sends anything outside the platform on your behalf.
• People in the loop. Every output is reviewed by the person who asked for it before it is used. See Human oversight.
• Evidence shown. Persona reactions show the public evidence they are based on, and persona definitions can be viewed and edited.
• Simulations, not people. Personas are simulations built from public statements; their reactions are predictions, not the views of the people they model.

Manipulation and adversarial input

Model output is text shown to a user; it cannot trigger actions outside the platform. Retrieved web content is used as context for the model, and every workspace is isolated from every other. Anything a model produces is reviewed by a person before use.