Skip to main content
knyte
SYSTEM · SECURITY

Security Overview

A public overview of Knyte architecture, access controls, incident response, and data handling.

Effective date: 2026-04-14 Last updated: 2026-04-14

This document describes how Knyte, operated by Kastling Inc., protects client data and runs the Knyte Services. It is a practical overview of system design, access boundaries, and operational safeguards.

1. Architecture Principles

  • Tenant isolation. Every client gets an isolated tenant. The brand brain built for one client is never merged into a shared corpus, never used to serve another client.
  • Model portability. The brand brain is a client-owned artifact. On termination, it is returned or deleted at client election.
  • Zero-retention routing on sensitive workloads. Inference routes sensitive workloads through providers that offer zero-retention or equivalent terms.
  • Defense in depth. Controls are layered across identity, network, application, and data layers.

2. Data Protection

  • Encryption in transit with TLS 1.2 or higher.
  • Encryption at rest with AES-256 or equivalent.
  • Key management through a hardened provider, with separation of duties.
  • Backups encrypted and access-controlled, with documented retention.

3. Access Control

  • Single sign-on and multi-factor authentication for all production and administrative access.
  • Role-based access control with least-privilege defaults.
  • Scheduled access reviews.
  • Audit logging of administrative actions, retained for a minimum of twelve months.

4. Network and Infrastructure

  • Production hosted on major cloud providers in the United States, with defined regions.
  • Network segmentation between production, staging, and corporate environments.
  • Web application firewall and DDoS protection at the edge.
  • Secrets management and rotation for service credentials.

5. Application Security

  • Secure software development lifecycle with code review.
  • Automated dependency scanning and vulnerability management.
  • Static and dynamic security testing in CI.
  • Scenario-based security reviews for critical product changes.

6. People

  • Background checks for personnel with access to client data, where permitted by law.
  • Confidentiality and acceptable use agreements required on day one.
  • Security awareness training on onboarding and annually.
  • Minimum-access provisioning, deprovisioned on role change or departure.

7. Incident Response

  • Documented incident response plan with defined severity levels, roles, and escalation.
  • Twenty-four hour on-call rotation for production incidents.
  • Client notification after confirmation of an incident affecting client data, based on severity and contract terms.

8. Business Continuity

  • Documented business continuity and disaster recovery plans.
  • Regular backups with tested restore procedures.
  • Defined recovery time and recovery point objectives per system tier.

9. Vendors and AI Providers

Knyte uses specialist vendors for hosting, inference, analytics, communications, and finance operations. AI and inference providers are selected and configured so that client data is not used to train shared or public models.

10. Contact

Security questions, vulnerability reports, and abuse: security@knyte.ai