The Limits of Trust
An engineer sat through a job interview with a company that did not exist.
There was a conversation with someone from human resources. Another with a person claiming to be the CEO. The people looked real. They had profiles, photographs, ordinary details that gave the whole thing the feeling of a genuine opportunity.
At the end came a coding assignment. Nothing particularly unusual if you make your living writing software.
The assignment carried malicious code.
The engineer worked at Binance.
I keep thinking about the moment before the download. Not because I know what that person was thinking. I don't. I keep thinking about how easily the same situation could have happened to someone else. An interesting opportunity. A convincing conversation. A task that seems to belong to the process.
Most of us have trusted far more on far less evidence.
On 29 October 2026, Binance suffered a theft involving approximately $6.34 billion in digital assets. Its initial incident report describes a series of compromises, including the fake interview, that eventually allowed attackers to reach the systems controlling its wallets.
The number is almost too large to mean anything. Six billion dollars is a headline. A job interview is something you can picture.
The uncomfortable part is that the interview wasn't the beginning.
Months earlier, in June, another engineer had downloaded a tampered software installer. Binance says its security team detected that incident, replaced the device and changed the relevant credentials. In other words, people noticed something was wrong and acted on it.
Yet the attackers had already learned something about the engineer's role and the people working alongside that engineer.
You can change a password. You can replace a laptop. You cannot make someone forget what they have learned about your organisation.
By September, the fake recruitment process had compromised another engineer. In October, the attackers used that computer and an internal AI tool to gain control of two more engineers' devices. Nine days later, they used stolen permissions and credentials to launch the attack.
The investigation is still ongoing. It would be foolish to pretend that an initial report tells us everything, or that one employee's decision explains an operation that unfolded over months.
Still, I can imagine the conversation that follows a breach like this.
Why did the engineer download the assignment?
Why wasn't the link checked?
Didn't they have training?
Those are fair questions, up to a point. They are also much easier to ask than the one that troubles me.
Why was it possible for somebody who had deceived one employee to keep moving?
I've spent much of my working life making things that have to survive contact with the real world. A cabinet can look perfect on a drawing, right down to the last millimetre. Then you install it and discover that the door hits something nobody accounted for.
The problem was there before anyone touched the handle. Telling the person opening the door to be more careful won't fix it.
I see a similar danger in the way organisations think about security. The policies are there. The controls have names. Responsibilities have been assigned. There may even be a certificate on the wall. All of it matters, but none of it can tell you, on its own, what will happen when a trusted person is tricked by someone patient enough to study them.
We have a habit of calling people the weakest link.
I've never liked that expression. It makes the person sound defective and the rest of the system sound innocent.
A capable engineer can be deceived. So can a director, a finance manager, a lawyer, or someone who has spent years working in cybersecurity. That is not an excuse for carelessness. It's a recognition of what a determined attacker is trying to exploit. They don't need you to become stupid. They need something false to appear ordinary for long enough.
The part about AI deserves attention too, although perhaps not the attention it will get. Binance says an internal AI tool formed part of the route into other devices. That doesn't establish that AI caused the attack or acted independently. It raises a more practical concern.
When we give a tool the ability to reach across our business, whose authority is it using? How much can it see? How much can it do before another person, or another control, has to agree?
We are understandably excited by anything that removes friction from work. Nobody enjoys asking for permission five times to do something they are authorised to do once. Yet some of that friction exists for a reason. Remove it without understanding the reason and you may make life easier for somebody you never intended to let in.
This is where my mind goes whenever I look at an organisation's risks. Not only to what is documented, but to what happens after the first assumption turns out to be wrong.
Suppose the employee is deceived despite the training. Suppose the device is compromised despite the software protecting it. Suppose the attacker has credentials that look perfectly legitimate.
What stops them then?
It's a less comfortable question than asking whether everyone has read the policy. It also tells us much more about how secure a business really is.
I don't want people to become suspicious of every opportunity, every colleague, every unfamiliar face on a screen. Work and life would be unbearable if we treated trust itself as a mistake.
We need trust. We couldn't get through an ordinary day without it.
What I question is the moment we allow trust in a person to become trust in every action performed in their name.
Somewhere in a business today, somebody is opening a file sent by a person who seems genuine. Perhaps it is genuine. Almost certainly, most of the time, it will be.
I wonder how many organisations know what would happen on the one occasion it isn't.
Comments