Kalky makes sure an AI cannot change anything important unless the right person approves it first.
Working today as a tested proof of concept, and ready for a first pilot.
AI assistants are being given access to real systems: customer records, payments, cloud accounts. They work around the clock, and they are fast.
Today’s security asks one question: is this account allowed? Nothing asks the question that matters: did a person actually mean this?
Without Kalky
With Kalky
Think of a cheque. Your AI assistant can fill it in, but only a person can sign it. Each signature works once, for that cheque only.
An AI assistant asks to do something important, just as it does today. Kalky holds the request. Nothing happens yet.
The right person sees exactly what will happen, in plain words, and approves it on their phone with a fingerprint or face.
The action runs exactly as approved, one time. Any change to it, or any second attempt, is refused.
Try it. This runs only in your browser; nothing is sent anywhere.
Request from an AI assistantWaiting
Assistant Ops assistant Wants to Cancel pending orders Which Older than 30 days System Orders
Press and hold the ring, or hold Space. About one second.
Held. Nothing has happened. Waiting for a person to approve.
Start with the gate: a person approves every important action. That alone delivers the promise, and it is all a first pilot needs. The layers further down add more protection when you are ready.
Before an AI changes anything important, the right person sees what will happen and approves it on their phone.
For exampleA support assistant wants to refund £4,000. The duty manager's phone shows “Refund £4,000 to customer 1182”. They approve with Face ID, and the refund goes through.
An approval matches one exact action. It cannot be stretched, edited or reused.
For exampleAfter approval, the assistant tries to change the refund to £40,000, then tries to send it twice. Both are refused. The approval covered one £4,000 refund, and it is now used up.
Your AI assistants never hold passwords or keys to your important systems.
For exampleTo carry out the approved refund, Kalky creates a key that works for two minutes, for that one job, then throws it away. There is nothing in the assistant for an attacker to steal.
You decide what needs a quick approval and what needs a verified identity on two devices.
For exampleReading a customer's address needs one tap. Deleting customer records needs a person whose identity was checked, confirming on two of their own devices.
Even approved actions cannot add up beyond a person's daily limit.
For exampleA manager has a £500 daily limit. They approve a £300 refund. A second request for £250 is refused, even though each would look fine on its own.
People are asked only when it matters, and only once per decision.
For exampleFifty copies of an assistant ask for the same thing. The manager sees one request, not fifty. Routine, low-risk tasks run without asking at all.
Kalky adds a check. It removes none of the security you already run.
For exampleStaff sign in the way they do today. Joiners and leavers come from your HR system, so a leaver can no longer approve anything. Kalky sits behind your existing firewalls.
Systems an AI cannot even see.
Your important systems disappear from the network for anything that has not been approved by a person. There is no door to knock on.
For exampleAn AI assistant scans the network looking for the customer database. It finds nothing: no address, no door, no answer.
Decoys that catch a misbehaving AI.
Kalky leaves convincing fakes where a misbehaving AI would look: fake databases, fake files, fake passwords. No real person is ever sent there, so anything that touches them is caught.
For exampleAn assistant finds a “database password” in a document and tries it. It is a trap. Within seconds the assistant is locked out everywhere, its waiting requests are frozen, and the security team has the full record. Nothing real was ever at risk.
A security guard that never sleeps.
Watch looks at every action for the things that should never happen, and alerts your security team the moment one does.
For exampleAn account approves forty requests in one minute, faster than anyone could read them. Watch flags it to the security team in Microsoft Teams.
A record no one can quietly rewrite.
Each organisation keeps its own tamper-evident record of who may approve and when evidence was sealed. It never holds names, emails or personal data.
For exampleSix months later an auditor asks who approved a change. The answer is checked against your own record book, which nobody could have altered after the fact.
Live systems hidden inside shared cloud accounts.
Where developers and live systems share one cloud account, AI accounts are given no view of the live side at all.
For exampleIn a Microsoft Azure account shared by test and live systems, an AI account cannot even list the live ones. It only ever sees the test side.
AI assistants will soon act inside every bank and every large organisation. Today’s security was built to check accounts, not intent. Kalky’s aim is to be the simple, standard proof that a person approved an action, working alongside the security you already trust rather than replacing it.
Our order is deliberate. We start where an unapproved action costs most and where the change is smallest: one gateway in front of one system. Then we extend the same pattern, a gateway at the door with a person approving each action, to new kinds of systems and new threats.
HowThe Kalky gateway in front of one system that matters, such as payments or customer data, using the bank's own sign-in. Daily value limits, two-person approval for the highest risks, and a sealed record for auditors.
WhyBanks are where an unapproved AI action costs most, and where regulators expect proof of control. A single-system pilot shows that proof without touching core banking.
HowThe same gateway in front of databases, file storage, internal services and cloud accounts, alongside tools companies already use, such as CyberArk and Microsoft Entra.
WhyEvery organisation adopting AI assistants has the same gap: today's tools check that an account is allowed, not that a person meant this action. Open standards mean no rip-and-replace.
HowApproval keys in hardware security modules, certified hardware security keys for approvers, real identity checks by a chosen provider in each region, and the record book spread across separate sites.
WhyThe proof of concept shows the guarantee works. These are the parts a bank's own security team will require before it runs on live systems.
HowThe gateway sits at the mainframe's front door: its service interface or message queue. No software is installed on the mainframe, and every other path is closed.
WhyMuch of banking still runs on mainframes. Protecting new systems while the oldest stay open would leave the back door unlocked.
HowA Kalky gateway in front of the custody provider or signing service. Each approved transaction gets a short-lived authorisation for one amount, one destination, one asset. Kalky never holds a key that can move funds.
WhyA digital asset transfer cannot be reversed. A person approving each exact transfer is the strongest control there is, and it follows the same pattern Kalky already uses.
HowKalky approvals last sixty seconds, so a future quantum computer cannot forge one after the fact. The real exposure is long-lived keys and network traffic recorded today, so the next step is quantum-resistant encryption for Kalky's own connections, already scoped.
WhyNo real-world key has been broken by a quantum computer yet, but regulators now ask for plans: FINMA expects Swiss banks to have one by mid-2027, the G7 published a roadmap for finance in January 2026, and NIST plans to phase out today's algorithms by 2030.
Design-stage items are planned and designed but not yet built or tested. We will not claim them until they are.
The rest of this page is for platform and security engineers: how the protocol works, how it fits your stack, and the test evidence behind every claim above.
Kalky sits in front of the systems you care about. Agents keep working as they do now; anything that changes production waits for a person, and runs once.
The agent sends its request as it always would. The enforcement point canonicalises it (RFC 8785) and hashes the exact operation and parameters.
A governed request is answered 202 KAP_PENDING_HUMAN. Nothing runs, and the agent holds no credential that could run it another way.
An approver sees what will happen, in plain words, and signs that hash with a passkey. KH2 adds a verified identity and a second enrolled device.
Kalky issues a one-time capability bound to that request and to the enforcement point's key: Ed25519, sixty seconds, consumed once. The parked request runs once.
Kalky is a set of enforcement points and brokers between agents and your systems, built on open standards you already use: WebAuthn passkeys, SCIM from your HR feed, MCP for agent tools, and plain HTTP. It adds proof of a human; it does not replace the controls you trust.
Three proofs make a human: a unique person (one HR record and an identity check at IAL2 or IAL3), a present person (a user-verified WebAuthn passkey), and an intended action (the passkey signs the canonical hash of this request).
| Level | Evidence | Used for |
|---|---|---|
KH0 | Credentials, tokens or sessions only | Not human. Governed actions are denied. |
KH1 | A user-verified passkey bound to the employee's Kalky credential | Low-risk reads; moderate writes where policy allows |
KH2 | A passkey bound to an identity verified at IAL2 or IAL3, confirmed on a second enrolled device | Production changes, deletes, exports, privilege changes, secrets, job approval. Two people for the highest risk. |
{
"iss": "https://kalky.acme.example/tenant/acme",
"aud": "urn:acme:orders-api",
"sub": "ksub_opaque_pairwise_value",
"jti": "01J8K7H3D7W0S5Q9N7K2A6V8C1",
"iat": 1790413200, "exp": 1790413260,
"human": { "level": "KH2", "presence": "webauthn_uv" },
"op": "orders.cancel",
"params_hash": "sha256-5c1b…e930",
"cnf": { "jkt": "thumbprint-of-enforcement-point-key" }
}| Status | Code | Meaning |
|---|---|---|
202 | KAP_PENDING_HUMAN | Parked, waiting for a verified person |
403 | KAP_NON_HUMAN | No human evidence, and the route forbids parking |
403 | KAP_POLICY_DENY | Denied by policy; no approval can override a forbid |
403 | KAP_VALUE_CAP | Would exceed the approver's cumulative daily value cap |
409 | KAP_REPLAYED | Capability or challenge already consumed |
409 | KAP_BINDING_MISMATCH | The live request differs from what was approved |
410 | KAP_EXPIRED | Challenge, session, job or capability expired |
503 | KAP_VERIFIER_UNAVAILABLE | Verification unavailable; nothing executed |
The employee credential is a W3C Verifiable Credential 2.0 with a pairwise subject and a status list whose hash is anchored on your chain. A lost key means proving identity again, never a helpdesk reset. The full specification is not public yet; ask for a walk-through.
Every capability in the proof of concept closed on a pass or fail test. Under load, enforcement made 600,000 decisions at 1,000 a second beside the replay store over TLS: median 2.3 ms, 99th percentile 4.3 ms. Of 6,000 capabilities presented a second time, none was accepted.
| What was proven | Tests | Result |
|---|---|---|
| Parked execution with a real agent | T01 | Pass |
| Brokers mint short-lived credentials; no standing access | T02, T07, T08 | Pass |
| Enrolment, verified identity and KH2 approval with a passkey | T03, T18 | Pass |
| Canonical binding, capability signing, single consumption | T04, T05, T06 | Pass |
| Watch rules, alerts and human-signed jobs | T09, T10, T11, T13 | Pass |
| Verifier or replay store down, or clock drift: fails closed, then runs exactly once | T12 | Pass |
| Load: 600,000 decisions at 1,000 a second, p99 under 10 ms, nothing consumed twice | T14 | Pass |
| Private chain sync, revocation and fail-closed staleness | T15, T16, T17 | Pass |
| Cloak: no host, port or name found; no answer to direct dials | T19, T20, T21 | Pass |
| Kalky Web: decoys only, W11 within 5 s, agent kept engaged | T22 to T26 | Pass |
| Prod Shield and harness integration (tenant simulator) | T27 to T31 | Pass |
| Daily value cap per approver (KAP_VALUE_CAP) | T32 | Pass |
| Decoy touch contains every agent seen at that address | T33 | Pass |
We are looking for a small number of design partners: banks, data platforms and any team whose production an agent could reach. A pilot puts the Kalky gateway in front of one system you choose, working with your identity provider. There is nothing else to stand up: no new network and no chain. The other layers come later, if you want them.
We can walk security leaders through the guarantee and the evidence, platform engineers through the protocol and the test results, and investors and partners through both.