Skip to content
kirky
How it works

Your app, your permissions. Kirky inside.

Kirky never logs into your systems. Your backend says who the user is, the user’s own browser reads your data, and every answer is checked against its source before anyone sees it.

See the three install stepsTrust page
The moving parts

Three places, and what crosses between them

Your backend

Your login, your keys, your endpoints

  • Token signer (ES256)
  • Read and write endpoints
The user’s browser

Your app, with the widget in a Shadow DOM

  • Your app’s screens
  • kirky widget
Kirky

Sessions, documents, the model · United States

  • Session check
  • Your documents, indexed
  • The model, with your rules
  1. 1Who is this user?The widget asks your backend, behind your own login, for a token.
  2. 2Signed token · 5 minYour server signs the user’s id and roles with a key that never leaves it.
  3. 3Token + questionKirky verifies the signature and the origin, then opens a short session.
  4. 4Read this endpointFor a data question, Kirky names the call; it never makes it.
  5. 5GET /orders, as the userThe browser calls your API with the user’s own session.
  6. 6Answer + sourcesEach quote checked against its passage, or “I don’t know”.
  1. 1
    Who is this user?The user’s browserYour backendThe widget asks your backend, behind your own login, for a token.
  2. 2
    Signed token · 5 minYour backendThe user’s browserYour server signs the user’s id and roles with a key that never leaves it.
  3. 3
    Token + questionThe user’s browserKirkyKirky verifies the signature and the origin, then opens a short session.
  4. 4
    Read this endpointKirkyThe user’s browserFor a data question, Kirky names the call; it never makes it.
  5. 5
    GET /orders, as the userThe user’s browserYour backendThe browser calls your API with the user’s own session.
  6. 6
    Answer + sourcesKirkyThe user’s browserEach quote checked against its passage, or “I don’t know”.

Numbers follow one question from start to finish.

One question, step by step

What happens between the question and the answer

  1. 01

    The widget loads

    One script tag. It mounts in a Shadow DOM, so your styles and Kirky’s never touch, and it knows which screen the user is on.

  2. 02

    Your backend vouches for the user

    It signs a token with the user’s id, roles and language. It lives five minutes at most, and Kirky trusts nothing else about who the user is.

  3. 03

    Kirky checks the role

    Roles come from the token. A role Kirky hasn’t seen before starts with no permissions until an admin grants them.

  4. 04

    It finds the sources

    Documents the role may read, the guide for the current screen, or one of your read endpoints — at most three reads per question.

  5. 05

    Data is read in the browser

    The user’s browser calls your API with the user’s session. Your API keys never reach Kirky, and only the fields you allowed come back.

  6. 06

    The answer is checked

    Every quote is compared word for word with its passage. What can’t be backed is removed; if nothing is left, the answer is “I don’t know”.

Try it

Watch the role check stop a question

Ask about the return window, then ask for a commission. Same user, same chat; the second never reaches the model.

Ana Torres · salesSample app · Orders
Hi Ana. Ask me about your orders, the return policy or how to do something here.
The rules it runs by

What Kirky will and won’t do

  • It says when it doesn’t knowIn Knowledge and Queries, every claim needs a source. No source, no claim.
  • Roles start emptyA new role sees nothing until you grant it. Kirky never widens what your app allows.
  • It never deletesActions create or update, after a preview and a confirmation. Delete isn’t on the list.
  • It stays on topicQuestions outside what you’ve turned on get a polite no, and no links or images go out in answers.
  • It knows its limitsAt most three reads per question, 500 rows to reason over, 60 seconds per answer — then it tells the user how to narrow the question.
  • It warns, never blocksCentinela gives a heads-up before an unusual value is saved. The user always decides.
What’s kept, what isn’t

Caching, and what never leaves your side

Cached, for speed
  • Answers from Help and Knowledge, for up to 7 days.
  • Keyed by role and language, so a user never sees an answer written for another role.
  • Dropped the moment a document that answer could read changes.
Never cached
  • Answers from your live data.
  • Actions and their previews.
  • Anything personal to one user.
Never leaves your side
  • Your API keys and database credentials.
  • The private key that signs user tokens.
  • Fields of a response you didn’t allow Kirky to use.
Technical questions

What developers ask first

Docs
Do you need access to our code, database or API keys?

No. You add a script, and your backend signs a short-lived token. Data questions run in the user’s browser against your endpoints; direct database access is optional, on Scale, through a read-only connector you host.

Where does the private key live?

With you. The portal generates the key pair in your admin’s browser; the private key is downloaded once and never reaches our servers. We keep only the public key, and you can rotate with two keys active.

Will the widget clash with our CSS?

No. It mounts in a Shadow DOM, so your styles don’t leak into it and its styles don’t leak into your app.

Can we test without affecting production?

Yes. Every organization has a free Test environment with its own keys and data, and the SDK has a mock mode with canned answers for your CI.

See it inside a real app.

The demo is a sample app with Kirky already installed. Ask it anything you’d ask in yours.

Try the demoBook a demo