# The keys were safe. The money left anyway

> Source: <https://kindex.lv/blog/keys-safe-money-gone/>
> Published: 2026-11-02 13:05:12+00:00

# The keys were safe. The money left anyway

Judging by what is known about the Binance hack, the attacker didn’t need to steal any private keys. They got in through a DevOps engineer’s laptop and simply sent the system a withdrawal command. The system carried it out, exactly as it was designed to.

I have been given advice on protecting keys many times. The conversation usually went like this:

— You should encrypt the keys on the server.

— Fine. And where is the decryption key kept?

— We’ll hide it.

— Obfuscation doesn’t save you. It is a matter of time, and these days a neural network takes someone else’s code apart in minutes.

— Then AWS KMS.

— KMS will hand over the key when the compromised server asks for it.

— Then a separate isolated server that holds the keys and does the signing.

— Now the key can’t be stolen. But that server takes a message from the queue saying “send this much to there” and sends it. The key is safe; the money is not.

— We’ll add a checking service: before signing, it verifies that the withdrawal is legitimate.

— And where does it verify? In an internal database, and that can be tampered with too. If instead it checks against an independent, immutable source and decides for itself whether to sign, then we have just invented a smart contract. If the contract has all the information and has no vulnerability to begin with, you can’t talk it round or hack it through the server next door.

Anything that rests on a server will be broken one day: there will be a hole in SSH, nginx, PHP, anything. My services have never been broken into from outside. But once a developer who already had access to the server simply took the keys and withdrew the money. The problem is almost always people.

You can build a super-secure system. But people deploy to it. Someone will leave a backdoor that, on the right command, withdraws the funds and cleans up the logs as well.

So there are two options. Either trust mathematics, as in smart contracts. Or build the same thing on people, as in [our key generation protocol](https://kindex.lv/blog/two-person-key-ceremony/): several independent signers, a quorum, each one checking. But people’s eyes glaze over, and in the fifth year you press “confirm” without looking.

This, I think, is where models genuinely help for the first time. Not instead of people, but in front of them:

- the input is only a strictly formed JSON with the transaction data, no “let’s talk”;
- the output is only “yes” or “no”;
- at the same time the model has broad read access: the blockchain, databases, old backups, so it can look for discrepancies and traces of tampering;
- there isn’t one such model but, say, 13 different ones, and they must be unanimous. If even one has doubts, everything stops and people step in.

A model doesn’t get tired and doesn’t doze off in its fifth year on the job. And if false alarms are rare, people will take each one seriously.

**We have learned to protect keys. Now we have to protect the decision whether to sign.**