Lab
Four small demos of how these systems are kept safe. They run in your browser on toy data, and each one says what is real and what is simplified.
1 · The approval flow
The agent can propose a change. Only a person can approve it, and the approval works once, for that exact change.
// click the steps in any order
// try committing before approving
This demo needs JavaScript. In short: the agent can only propose a change. A person approves it and gets a single-use token bound to a hash of that change. Committing without the token is blocked, a second commit is rejected, and editing the change after approval breaks the hash.
What's real
The token is bound to a real SHA-256 hash of the change, computed with your browser's Web Crypto API. Commit checks the hash again, so changing the limit after approval breaks the match. A token works once; a second commit is rejected.
What's simplified
There's no database or real card, and you play both the agent and the person approving. In the real system they are separate identities, the agent can't reach the approve step at all, and tokens are issued and checked on the server.
How it maps
In KONA's card management system the agent can only save drafts or act as the maker in the bank's maker-checker flow. Writes with no approval step of their own go to an approval ledger, and a person approves them from a card in the portal. Read the case study →
2 · The PIN-safe screen matcher
Ask an invented wallet how to do something, in English, Bangla or Banglish. Try a forgotten PIN, or ask for an OTP.
Try:
This demo needs JavaScript. It matches questions in English, Bangla or Banglish to screens of an invented wallet, refuses to send anyone who forgot their PIN to Change PIN, and answers requests for a PIN or OTP with safety advice only.
What's real
The rules mirror the real ones. Someone who forgot or lost their PIN never gets Change PIN, a request for a PIN or OTP gets safety advice and no screen, and a topic the guide doesn't cover beats any partial match. Only screen titles and synonyms count, never the steps. A multi-word synonym needs all its words. Matches are exact, likely or weak, and a weak match never becomes a button.
What's simplified
The wallet, its seven screens, its synonyms and its word lists are invented, and the scoring is simpler: here the safety rules run first, while the real screen finder scores every screen and then applies them. It also keeps an index per platform and app version, runs as a tool server, and the orchestration layer checks weak matches again.
How it maps
This is how KON-AI, the assistant in the Nagad app, sends people to the right screen without ever sending someone who lost their PIN to Change PIN. Read the case study →
3 · The lookup check
A model answered a bank operator. The check marks each number in the answer that no tool call returned.
Operator asks How many active cards does this customer have, and what is their daily limit?
Model answers
The customer has 3 active cards, a daily limit of 50,000 BDT and 12 declined payments this week.
This demo needs JavaScript. It highlights every number in the answer that no tool call returned. Here, "12 declined payments" has nothing behind it, so the check flags it.
What's real
The idea is the real one: a number about the bank's records has to come from a tool, and code checks that after the model answers instead of trusting the prompt. Before the check, about 1 in 3 count answers in a 60-question test sample were made up.
What's simplified
The question, the tool results and the answer are invented, and this demo compares each number with what the tools returned. The real check is coarser: when an answer states a number in a turn that called no tool, a quick yes-or-no model call decides whether it's a fact about the records, and if so the agent is asked once to look it up. It runs inside the orchestration service, next to limits on tool calls and repeat-call detection.
How it maps
It's one of the guardrails around the bank assistant, alongside input screening, PII redaction and an eval suite of 2,265 cases. Read the case study →
4 · Offline signing
Make a key, sign a payment and send it to a pretend gateway. Then change the amount on the way and send it again.
{"from":"wallet-a","to":"merchant-7","amount":120}// the gateway only ever receives the payment, the signature and the public key
This demo needs JavaScript. It makes a P-256 (secp256r1) key pair in your browser that can't be exported, signs a toy payment with it, and lets a pretend gateway check the signature with the public key alone. Changing the amount after signing makes the check fail.
What's real
The key pair is a real ECDSA key on the P-256 curve (also called secp256r1), made by your browser's Web Crypto API. The private key can't be exported, and the gateway checks the signature with the public key alone.
What's simplified
NCP users get a BIP39 HD wallet, and a signed transaction goes on through Hyperledger Fabric endorsement and commit. Here it's a single key pair and a gateway that only verifies.
How it maps
This is the idea behind NCP's signing portal: the gateway never sees a user's private key, so custody stays with the user. Read the case study →