No scoped app, no update set, no widget, no stored script, no service account. One OAuth client record — the same mechanism ServiceNow's own mobile apps sign in through — and the console runs on your side of the wire. Here is the whole thing, drawn.
There is no code of ours running on your instance, so there is no version of ours to keep current, and nothing of ours can break in a platform upgrade.
Refresh a sub-prod instance from production and the only thing to check is whether that one record survived. If it didn't, recreating it is the fifteen minutes below.
Set the record inactive. Every session dies with it, immediately, and the decision stays entirely on your side — you never have to ask us to stop.
An authorization-code client in the instance's own OAuth registry. We hand it over pre-written — record type, exact redirect URI, PKCE, recommended token lifespans, and the clone-preserver step — as a change request your CAB can read and approve without reconstructing any of it.
It also answers the question that always comes up: why isn't this a service account? Because we are a user-delegated client, like the platform's own mobile apps, not an integration. There is no standing credential to grant.
Instance host, the client ID and secret from that record, and the model endpoint your organisation already approved. Configuration, not code — and it is set once for the deployment. The console is a single service; you run it, so instance data never crosses into anyone else's network.
The secret lives in your environment, next to every other secret you hold. It never enters our repository, and there is no place in the product where you type it into a form we operate.
No accounts to create, no directory to sync, no provisioning project. If someone can sign in to your ServiceNow, they can sign in here — and what they see is decided by the roles they already carry, read back from the instance at sign-in.
Which is also the offboarding story. Disable the person in ServiceNow and they are disabled here, in the same instant, because there was never a second account to remember.
If your organisation can't get a change request through in a reasonable window, the self-hosted shape below is the answer we give — the redirect URI stays inside your own network, which is usually the objection underneath the delay.
How an evaluation starts. One person runs the console locally, signs in, and asks their instance a real question. Nothing is shared, nothing is hosted, and the only instance-side change is still that one record.
The console is one service with a database; you deploy it where you deploy things. The redirect URI never leaves your perimeter, which is the shape that answers most of what a bank's review is actually asking.
The multi-tenant service runs at https://kaddiya.com, and it is deliberately not the shape we lead with for production: the organisations most interested in this product are the ones least willing to let a vendor hold a session token to their production instance. Self-hosted exists for that reason, and the same image runs both shapes. How the hosted trial works.
We started there. The first design was widgets on the portal and a scoped app brokering model calls out through the platform, and we abandoned it for reasons that haven't changed: server script can't stream an answer, every step of the agent's work becomes a round trip through the instance, and the AI runtime becomes whichever one your licensing tier happens to include.
Running outside, the agent gets a full toolchain and you keep the model contract you already negotiated — while ServiceNow keeps every job it is genuinely the authority on: who you are, what you're allowed to see, and what happened.
Installing nothing isn't a shortcut around the hard part. It is the part we designed for.