Security

Konkui helps Thai enterprises turn operations into AI-assisted workflows. This page describes, honestly and in concrete terms, how we protect customer data and infrastructure today. Where a control is still being formalized, we say so and label it as planned.

• Encryption: AES-256-GCM at rest for channel and datasource credentials; TLS in transit via a managed edge.
• Tenant isolation: Application-level, session-derived org/account scoping with per-account advisory locks.
• Access control: NextAuth sessions, role-based procedures, and short-lived turn-scoped HMAC gateway tokens (account-scoped gateway tokens persist until the shared secret is rotated).
• Certifications: Not yet certified. Our assurance basis is an internal red-team threat model, the controls above, and a certification roadmap as we scale.

1. Data security

Encryption at rest

Channel and datasource credentials — LINE, Telegram, Shopee, Lazada, and Shopify tokens and secrets — are encrypted at rest with AES-256-GCM (a 12-byte random nonce and a 16-byte authenticated tag) before they are written to the database. A rotatable keyring protects Konkui Agent channel credentials, and a dedicated key protects B2B product-datasource credentials.

Please note the honest scope: this is application-layer, field-level encryption of secret fields only. Chat messages, agent traces, and memory are stored as plaintext database columns and are protected by tenant isolation and access control, not by at-rest column encryption. Database-level encryption (for example TDE) is a planned item, not a control we operate today.

Encryption in transit

Traffic between Konkui and its upstreams is transported over HTTPS/TLS. Transport security is provided by the managed hosting edge (Vercel / Cloudflare), and every third-party base URL Konkui calls uses an https:// default. Konkui does not operate custom cryptographic code — our engineering standards forbid it, and managed TLS is a genuine engineering control rather than a custom claim.

Access control

• Sign-in uses NextAuth with Google OAuth, LINE Login, and bcrypt-hashed credentials.
• Privileged actions go through role-based procedures: logged-in, org-user, org-admin, and superadmin (an allowlist).
• Internal and cron endpoints authenticate with a constant-time secret comparison.
• Sandbox-to-gateway calls use short-lived, turn-scoped HMAC tokens (a 45-minute ceiling). Account-scoped gateway tokens remain valid until the shared secret is rotated — only turn-scoped tokens expire automatically.

Tenant isolation

Customer data is isolated at the application layer. Every privileged query resolves the account from the authenticated session, and for organization-scoped queries selects the organization from a request header and then verifies the session user's membership on each request, rejecting any organization the user does not belong to. Every mutation carries an account/org guard so a non-owner's update or delete affects zero rows. A per-account Postgres advisory lock prevents concurrent webhook turns from spawning duplicate sandboxes. This is application-level, row-scoped isolation with advisory locks; it is not database row-level security, and an insider with read-only database access remains an accepted threat for non-secret data.

2. Privacy and compliance (PDPA)

Lawful basis

For end-customer personal data processed in chat, Konkui's intended lawful basis is consent. The full consent framework — including explicit-consent handling for any special-category data and a withdrawable consent mechanism — is being formalized and will be documented in the Data Processing Addendum. Planned

Data-subject rights

Under Thailand's Personal Data Protection Act (PDPA), data subjects have the right to: be informed; access; correct; delete (erasure); restrict processing; object; withdraw consent; and data portability. You may exercise any of these rights by [email protected]. A dedicated, monitored request channel with a stated response timeframe is planned. Planned

Data retention

• Inbound LINE images are retained only for the vision-processing window (served via a one-hour presigned URL) and deleted by a scheduled cleanup job; the current default retention is 24 hours and is configurable per deployment.
• Workspace versions are capped to the newest 10.
• Observability logs and conversation history are retained by default for the lifetime of the account — the beta default is to retain, and a bounded retention schedule is configurable but not the current default.

A single, documented, per-category retention schedule with hard ceilings and automatic purge is planned. Planned

3. Data Processing Addendum (DPA)

A version-dated Data Processing Addendum is in preparation and will be provided to enterprise customers once legal has produced it; we do not host or link a DPA document before then. To request the DPA, contact [email protected] and we will share a target timeline on receipt. The DPA's version and effective date are recorded once legal produces it. Planned

4. Subprocessors

The following subprocessors process customer data to operate Konkui. Locations reflect current deployment defaults. This list was last reviewed on July 18, 2026.

• OpenRouter— Default LLM inference gateway/router. Processes message content on agent turns. US-based. Applies Konkui's provider.data_collection: "deny" floor (and an optional zdr: true uplift) on routed requests.
• Z.ai / Zhipu (GLM models) — Native LLM inference for glm-5-turbo and glm-5.2. Processes message content. China-based (api.z.ai) and not covered by the OpenRouter deny/ZDR control when called natively.
• Google (Gemini) — LLM inference for Gemini models. Processes message content. US-based.
• Anthropic (Claude) — LLM inference for Claude models. Processes message content. US-based; routed via OpenRouter by default.
• OpenAI and xAI (Grok) — Additional US-based LLM inference providers reached through the OpenRouter gateway. Process message content.
• DeepSeek and MiniMax — China-based LLM model providers also reached through the OpenRouter gateway and processing message content on their own infrastructure. Like the Z.ai path, this is a cross-border transfer to a China-based inference provider and is not covered by the OpenRouter deny/ZDR control for content processed on those providers' infrastructure.
• E2B — Code-execution sandbox (Firecracker microVMs) where customer agent turns run. Per-account, disposable. US-based. The microVM isolation boundary is trusted to E2B.
• Vercel — Application hosting and edge (Next.js). Terminates TLS. US (Vercel Sandbox region iad1 / US East).
• Managed PostgreSQL (Postgres Bridge) — Primary relational database for both the B2B product and Konkui Agent (separate konkui_agent schema). Stores accounts, channels, messages, traces, memory, and audit events. US-oriented provider.
• Qdrant — Vector store backing agent memory and recall. Stores embeddings derived from conversation content.
• Upstash (Redis + QStash) — Redis for caching/state and QStash for the async job queue (detached turn delivery, scheduled tasks, cron). US-based.
• S3-compatible object storage — Object storage for workspace bundles and inbound LINE images (pre-deletion). Region is configurable per deployment; the current production region is available on request.
• Browserbase— Headless browser automation for the agent's web-research/browse tool. Processes URLs and extracted page content. US-based.
• Exa— Web search and content extraction for the agent's research and extract tools. Processes search queries and extracted content. US-based.
• Google Workspace (Drive/Calendar) — Central company-owned Google account (default [email protected]) the agent uses to access customer-shared Drive files and calendar invites. Processes document content the customer explicitly shares.
• Google OAuth (identity provider) — Primary identity provider for NextAuth sign-in. Processes email and name for authentication.

An email subscription for subprocessor changes, with a 30-day objection window before a new subprocessor processes customer data, is planned. To be notified, contact [email protected]. Planned

5. Data residency and cross-border transfer

Is my data stored in Thailand? No. Personal data is stored and processed outside Thailand. Primary hosting, the database, sandbox execution, the vector store, the queue and cache, object storage, and LLM inference run in the United States, and — for Z.ai models — in China. There is no Thailand data residency.

Distinguish two cases: data at rest (US for Vercel/managed Postgres/Upstash/E2B/OpenRouter; China for Z.ai) versus data sent to LLM inference on every agent turn (chat content is transmitted to the US/China provider selected for that turn).

Because processing occurs abroad, cross-border transfer to LLM inference providers happens on every agent turn. Konkui's intended transfer basis is the customer's consent; formal Standard Contractual Clauses and a transfer impact assessment are planned and not yet in place. Konkui discloses the destination providers above and offers an OpenRouter zero-data-retention routing path as a partial mitigation for OpenRouter-routed traffic. Planned

6. Incident response and breach notification

When Konkui becomes aware of a personal-data breach through its audit logs or other means, it will notify affected enterprise customers as soon as practicable. A specific notification SLA — including breach-detection and escalation procedures and a target aligned to the controller's PDPC notification duty — will be established in the DPA rather than pre-published here. Konkui does not currently operate automated breach-detection tooling; the per-event audit ledger described below supports manual investigation after an incident is identified. For the breach-notification term, contact [email protected]. Planned

7. Certifications and attestations

Konkui is not yet SOC 2 or ISO 27001 certified. There is no "GDPR-certified" or "PDPA-certified" designation — no such certification exists, and we do not claim one. Our current assurance basis is an internal red-team threat model (a 5-agent pass backed by an attacker-perspective unit-test suite across five attack surfaces), AES-256-GCM encryption of credentials at rest, role-based access control, and application-level tenant isolation, with a certification roadmap as we scale.

The internal threat model covers authentication, multi-tenancy, injection, cryptography, resource exhaustion, and state-integrity races. Its scope is the Konkui Agent product; the main B2B product and vendored subsystems are out of scope for that assessment. To request the full threat model and architecture under NDA, contact [email protected].

8. Internal security practices

Konkui maintains an audit substrate for sensitive actions: a token-usage ledger with idempotency keys, per-event billing logs, and admin audit events (including observability-log truncation). Formal internal-access review with an approval trail, staff confidentiality obligations, and customer access reports on request are planned. Planned

9. Contact and responsible disclosure

For security questions, the DPA, data-subject-rights requests, subprocessor-change notifications, or to report a vulnerability, contact [email protected]. To request security documentation (the full threat model or architecture) under NDA, use the same address. A published responsible-disclosure policy with in-scope assets, safe-harbor, and a response SLA is planned. Planned

Last updated: July 18, 2026