How Kirky is built to be safe to embed

The script tag carries a public workspace ID. It is publishable and proves nothing on its own.

Your backend, behind your own login, signs who the user is: an ES256 token with the user ID, roles, language and audience, valid for five minutes at most. We verify the signature against the key you registered, the audience, the expiry and the page’s origin against your allowlist.

Only then do we issue our own session token: short-lived, bound to that origin and signed with a key held in a hardware-backed key service. Every Kirky API accepts only that session token. The workspace is derived from the key that verified your token, never from a claim inside it.

Roles come from your token and are detected automatically. A role we have not seen before starts with no permissions until your admin grants them in the portal.

Each session gets a manifest of the tools, documents and endpoints its role may use. A request for anything outside that manifest is rejected by the server, whatever the model asks for.

Workspaces share infrastructure on Starter, Business and Scale, and are separated at every layer: every stored item is keyed by workspace, the functions that serve a request can only reach keys and storage prefixes of that workspace, and each workspace has its own search index.

A cross-workspace isolation test suite runs before every deploy, and a failure blocks it. Enterprise can run in a dedicated deployment.

For live data, the model asks for a tool call and the widget executes it in the user’s browser against your read endpoints, with that user’s existing session. Your API credentials never reach us.

Each tool call carries a single-use signed ID. The widget re-validates the path before calling it and rejects encoded separators, parent paths and absolute URLs. The result comes back capped in size, reduced to the fields your admin selected, and treated as untrusted input.

Direct database access is optional. The connector is an open-source container you run in your network. It connects out to us over an encrypted WebSocket; we never open a port into your network.

It refuses to start unless its database role can only read, runs every query inside a read-only transaction with a statement timeout and a cost budget, and signs its results.

We don’t hold your API keys. The keys we do hold, such as the public keys that verify your tokens and each connector’s secret, are stored encrypted and scoped to your workspace. Signing keys never leave the key service.

All traffic uses TLS. Data at rest is encrypted with keys whose use is bound to your workspace; a paid plan can move to a dedicated key, and Enterprise can bring its own.

Every question first passes a topic check, and content filters run on the input and on free-text fields that come back from tools. Document answers run in strict mode, with every quote verified word for word against its source in code.

To prevent data from leaving through an answer, the output is sanitized: no links, no images and no active markup, and Kirky has no web access. The model provider is configured not to retain requests, and your data doesn’t train models.

Requests are throttled per workspace and per user, with a daily cap per user. Suspicious activity is flagged as a security event for your admin; we block the request, and a person decides whether to suspend anyone.

Sign-ins, questions, tool calls, actions, configuration changes and support sessions are recorded in an audit log your admin can review and export. Records are written once and not edited.

Our staff can only act inside your workspace through a support session that is time-limited, requires multi-factor sign-in and appears in your audit log.

Automated alerts watch for security events. If an incident affects your data, we notify your workspace owner without undue delay, with what happened, what data was involved and what we are doing, and keep you updated until it is closed. The Data Processing Agreement sets out these obligations.