Most of this page is about what the product cannot do, because that is the part you're actually assessing. The last two sections are the risks we would raise ourselves if we were reviewing it — published here rather than waiting for your questionnaire to find them.
Anything you can do on your instance, it can draft. Nothing it can do without you. The agent can propose a write; it cannot perform one. Every write is one record, on a card that showed the exact payload, committed by a human click on that human's credentials, through a named endpoint. The whole list fits on one page, and a test fails the build if that page and the code ever disagree.
OAuth as the signed-in user. It sees exactly what that user sees — no service account, no elevated role, no authorization logic of ours for you to audit, because we did not write any. A denial is your instance denying.
Every query is shown on screen as it runs and retained with the conversation. Every commit is logged against the person who approved it, in your instance's own audit tables — the copy that outlives us.
The console speaks one protocol and calls the endpoint you point it at: your provider on your own key, or your own gateway, so instance data leaves through your DLP and logging. On a self-hosted deployment and on every paid plan we hold no model credential at all. The one exception is the hosted free plan: its trial allowance runs on a labelled key we hold and meter, until you connect your own.
The honest way to read an architecture is to assume each piece falls and ask what it was holding. Three pieces, and the answers differ enough to be worth writing down.
Holds all of the data and all of the authority — exactly as it did before we existed.
Holds conversations and, while people are signed in, their session tokens. This is the worst case, and it is the one we'd press on hardest in your position.
Holds the prompts and answers for turns you ran, under whatever agreement you already have with that provider.
A vendor page that lists only strengths is a page that has not been reviewed honestly. These are the open items we track internally, written the way we'd want to read them.
This is the line banks stall on, and they are right to. It is why the shape we recommend for production is the one you run yourself, inside your own network, where the token never leaves your perimeter — and why the multi-tenant hosted service at kaddiya.com is offered for developer and sub-production instances rather than as the thing we lead with for production.
It is bounded — active sessions only, each carrying one user's own permissions, no durable tokens because nothing runs unattended — but "bounded" is not "eliminated", and we would rather write that sentence here than have you extract it from us later.
The person who wants Kaddiya is almost never the person who can create a registry record in production. We productise that step — the change request arrives written for a CAB — but we cannot shorten your change calendar, and we don't claim to. The timeline is on the setup page, with the waiting drawn in.
Customer-run deployments behind restrictive networks are harder for us to support than a service we operate. We accept that trade because the alternative is asking you to accept risk 01 instead. The packaged distribution — signed images, an SBOM, preflight checks — is in build.
Any product that asks an administrator to sign in through a redirect is training a behaviour an attacker can imitate. Our answer is pattern discipline — you authenticate only on your own instance's domain, never on a page we render — which reduces the concern without eliminating it. Worth naming in your own awareness training.
| The question | The answer | |
|---|---|---|
| Installation | QuestionWhat gets installed on our instance? | AnswerOne OAuth client record. No scoped app, no update set, no widget, no stored script, no service account. |
| Identity | QuestionWhat identity does it act as? | AnswerThe signed-in user's, on their own OAuth token, for every single call. There is no other identity available to it. |
| Service accounts | QuestionThird parties must use a service account. Why don't you? | AnswerBecause we are a user-delegated client, like your platform's own mobile apps — not an integration. A service account would add standing privilege that nothing in the product needs. |
| Write scope | QuestionWhat can it change without us noticing? | AnswerNothing. Every write is a human click on a shown payload, one record at a time, and every one logs the approver. The list of what it can write fits on one page, and you can block any of it at your own edge with a REST API access policy. |
| Data egress | QuestionWhere does our instance data go? | AnswerTo the model endpoint you configured, and nowhere else. Point it at your own gateway and it leaves through your DLP and logging. We hold no model credential. |
| Kill switch | QuestionHow do we stop it, immediately, without you? | AnswerSet the OAuth record inactive. Every token dies with it, from your side, without asking us or waiting for us. |
| Unattended use | QuestionDoes it run when nobody is watching? | AnswerNo. No background jobs, no scheduled runs, no durable tokens. Session ends, access ends. |
| Certification | QuestionAre you SOC 2 certified? | AnswerNot yet, and we won't imply otherwise. in progress — ask us for current status rather than trusting a badge on a website. |