Security at Kite, stated as mechanisms.

01

Infrastructure security

Production runs in a single protected environment in the United States, on managed infrastructure.

• All traffic to and between services is encrypted in transit with TLS.
• Private network traffic between services stays inside the production environment. The public marketing site has no private network access and shares no credentials with the product.
• Production resources are protected: a non-administrator cannot read a secret’s value, suspend a service or delete a resource.
• Secrets are held in the hosting environment, never in source or configuration files, and the server’s secrets are scoped apart from the consoles’.

02

Data protection

Customer data is encrypted at rest, scoped to the customer’s organization, and exportable on request.

• Documents — bills, leases, statements, agreements — are stored in object storage encrypted at rest.
• Every third-party credential is sealed with AES-256-GCM before storage, in an envelope that names the key that sealed it. Keys rotate as an operation: a new key is added, the store is re-sealed, the old key is retired when nothing cites it.
• Bank connections are made through a regulated bank-data aggregator. Kite holds a revocable access token, never a bank username or password.
• Every record carries its organization, and every query executes inside that scope. A group reads across its own entities only.
• Data is exported to the customer in ordinary formats on request, and deleted on request after export.

03

Identity and access management

Authentication is delegated to the customer’s identity provider. Authorization is role-based, least-privilege by default.

• Single sign-on through the customer’s identity provider, including SAML and Google Workspace. Kite does not store, see or reset passwords.
• Multi-factor authentication is enforced by the identity provider’s policy, which Kite inherits.
• Sessions are sealed, encrypted cookies; no session token is readable by script in the browser.
• Six roles — owner, administrator, store manager, accountant, auditor, viewer. A new user is a viewer until an administrator assigns otherwise. Each organization may grant permissions beyond a role’s defaults or withhold them.
• Kite’s accounting staff access a customer’s books only inside the product, under a role, on the same audit trail as the customer’s own users.

04

Application security

The codebase is continuously scanned, the accounting core is covered by automated tests, and every page ships hardened headers.

• Automated dependency vulnerability scanning runs against the repository on every change.
• The accounting core — postings, periods, close, recognition — carries an automated test suite that encodes each repaired defect as a check that must hold.
• Every page sends strict transport security, frame denial, content-type and referrer policies, and a restrictive permissions policy.

05

Product security and controls

The ledger is designed so that every figure can be traced, every change attributed, and nothing posted without a person.

• Append-only audit trail: every change to a financial record, by whom or what — a user, the AI, or a scheduled workflow — and when. No endpoint edits or deletes an audit row.
• Maker-checker on everything the model drafts: the model proposes, deterministic engines compute, and nothing it drafts reaches the ledger until a named person approves it. Every entry records who prepared it and who approved it.
• Every figure cites the document or line it came from, and every posting is traceable to the rule that produced it, so the books can be replayed and verified.
• All model calls pass through a single gateway, so a provider can be changed, or a document withheld, in one place. Providers, and the regions they process in, are named on request.

06

Business continuity

Customer data is backed up without customer action.

• The managed database is backed up daily by the hosting provider.
• Document storage is replicated by the storage provider.

07

Incident response

If an incident affects a customer’s data, the customer hears it from Kite directly.

• Affected customers are notified promptly, with what happened, what data it touched, and what was done about it.
• Vulnerability reports are read by a person and answered; see Responsible disclosure below.

08

Shared responsibility

Some controls sit with the customer by design, because they are the customer’s to set.

• The customer: multi-factor authentication and password policy at their identity provider; assigning roles and revoking access when people leave; the accuracy of documents and data supplied.
• Kite: everything above — the infrastructure, the encryption, the scoping, the audit trail, the approval control, and the staff who work inside them.

09

Compliance and privacy

Kite states its posture as mechanisms and its certifications as they stand.

• SOC 2: Kite does not have a SOC 2 report yet. The controls above are available for review, and Kite will walk a customer’s security team through any of them.
• Privacy: the website’s data practices, and a working analytics opt-out that honours Global Privacy Control, are on the privacy page. Customer data in the product is governed by the customer agreement and its data-protection terms.
• Security questionnaires are answered against the product, not from a template.

10

Responsible disclosure

Security researchers who identify a vulnerability in Kite are asked to report it to security@kitebo.com with steps to reproduce, and to allow a reasonable period for remediation before disclosure. Reports are read by a person, acknowledged, and answered with what was done.