On October 29, attackers moved approximately $6.36 billion out of Binance, one of the world’s largest cryptocurrency exchanges. According to investigators at TRM Labs, most of the money disappeared in about twenty minutes, moving across ten different blockchain networks.

Binance’s initial investigation pointed to a compromised laptop belonging to a DevOps engineer. The attacker may have used that computer to gain access to software responsible for processing withdrawals. Subsequent disclosures indicated additional points of compromise, and the full investigation is still underway.

But one detail caught my attention.

Binance says it has found no evidence that the private keys protecting its cryptocurrency wallets were stolen.

If that finding holds up, it raises an interesting question. How do you steal billions of dollars without stealing the keys?

Imagine a bank that has invested in an extraordinarily secure vault. The locking mechanism is excellent, the keys are well protected, and only authorized systems can request access.

But the bank also has automated machinery that moves money out of the vault when it receives an approved instruction. An attacker compromises one of the systems authorized to issue those instructions.

The vault recognizes the request, accepts the authorization, and opens.

The keys were never stolen. The lock worked. The money is still gone.

We don’t yet know whether that analogy accurately describes the internal failure at Binance. But blockchain investigators found that the malicious transactions carried valid cryptographic signatures. TRM Labs believes the attacker may have gained the ability to make Binance’s signing infrastructure authorize transactions of the attacker’s choosing.

For me, this points to a much larger problem than cryptocurrency.

For decades, security architecture has relied on three basic concepts: authentication, authorization, and audit. Collectively, we’ve called them AAA.

Authentication establishes who you are. Authorization determines what you are allowed to do. Audit provides the evidence of what happened.

Of these three, authentication has received much of the attention.

We’ve invested heavily in passwords, multifactor authentication, certificates, identity providers, hardware-backed credentials, and increasingly sophisticated ways to establish that a human or machine is who it claims to be.

These are important advances. But establishing identity is only the beginning of a security decision.

An authenticated identity should not automatically have permission to perform every action available through the system it has accessed. Yet many architectures still place enormous trust in the permissions attached to an identity, particularly when that identity belongs to a trusted application or service.

Knowing who is asking is not the same as knowing whether the request should be allowed.

There is another interesting aspect of the Binance incident.

The affected wallets operated across ten separate blockchain networks. These networks have different designs and transaction mechanisms. Yet the attacker was apparently able to initiate valid transactions across all of them.

That doesn’t mean the individual networks were compromised. It raises the possibility that a common system within Binance was trusted to act across them.

This is where transitive trust becomes important.

The classic explanation is simple. If A trusts B, and B trusts C, then A may effectively trust C, even if A never established that relationship directly.

In security architecture, trust relationships can form chains. A service trusts another service, which trusts another, and so on. Each relationship may be perfectly legitimate on its own. But together, they can create paths of authority that were never explicitly intended or evaluated.

This isn’t a new security problem. We’ve understood the dangers of transitive trust for decades. The challenge is discovering and evaluating all those relationships, particularly as systems become more interconnected and authority is delegated across services.

If investigators are correct that a common signing capability was involved at Binance, the incident raises an important architectural question. How much authority was concentrated in that common system, and what boundaries existed to prevent a compromise from reaching across so many otherwise independent environments?

We shouldn’t have to wait for a breach to discover those relationships.

Think about the keys we use every day.

My house key opens my house. My firesafe key opens my firesafe. Each has a relatively well-defined purpose, and I understand the consequences if either falls into the wrong hands.

Now imagine my house key also provides access to a system that can unlock the firesafe. I no longer need the firesafe key to reach its contents. I’ve found another path through a relationship between two otherwise separate systems.

The key itself hasn’t changed. The authority available through that key has.

This is what makes transitive trust so important. When evaluating access, we need to understand not only what an identity can do directly, but what it can accomplish through the systems that trust it.

Least privilege is usually evaluated locally, while the consequences of transitive trust are often global.

And I suspect this problem is about to become considerably more difficult.

As autonomous AI agents become pervasive, we’re giving software the ability to make decisions, discover tools, interact with other systems, and delegate work to additional agents.

Unlike my house key, an agent’s credentials don’t necessarily represent a fixed set of consequences. The agent can combine capabilities and invoke other systems in ways its designers may not have anticipated.

An agent that cannot directly access a sensitive system may know another agent that can. That second agent may have access to a third. Each relationship may be legitimate, but together they could create a path to something the original agent was never supposed to reach.

An attacker might not need to steal a privileged credential. They may only need to influence an agent that can enlist another agent with the authority they want.

I suspect these indirect paths will become increasingly attractive to attackers. As the number of agents and their relationships grows, discovering and exploiting transitive trust may become easier than compromising a highly privileged system directly.

This also exposes another limitation in how we think about authorization.

We tend to treat authorization as a state.

At any given moment, an identity either has permission to perform an operation or it doesn’t. We can inspect a role, review an access policy, or examine the permissions assigned to a service account.

But those permissions tell us surprisingly little about how authority is exercised over time.

A service authorized to transfer money may legitimately perform thousands of transactions. Does that mean it should be allowed to move billions of dollars in twenty minutes?

A deployment service may have permission to modify production infrastructure. Does that mean it should be allowed to replace every production system simultaneously?

Authorization needs to incorporate rate as well as state.

How often is an operation performed? How much cumulative authority is being exercised? How quickly is the scope of access expanding? How many trust boundaries are being crossed?

These should influence authorization decisions, not simply become interesting observations for a security system after the fact.

Audit needs to evolve alongside authorization. Recording that an authenticated identity performed an authorized action is useful, but we also need to reconstruct how that authorization was obtained, which trust relationships made it possible, and how the effective authority changed over time.

This is particularly important in an agentic environment where decisions may be made and executed at machine speed.

I don’t think the authorization technologies we commonly deploy today are sufficient for that environment.

Zero Trust and least privilege remain sound principles. But implementing them primarily through static roles, predefined permissions, and periodic access reviews won’t adequately address autonomous systems that discover and exercise authority dynamically.

We need architectures that can account for delegated authority, evaluate the consequences of actions, and place meaningful boundaries on how rapidly and extensively that authority can be exercised.

We also need to make transitive trust visible, so that we understand the effective reach of an identity before an attacker discovers it for us.

None of this establishes that transitive trust caused the Binance breach. We still need the full technical investigation to understand exactly what happened.

But the incident gives us a compelling reason to examine how much authority we concentrate behind credentials and trusted services, and how far that authority can extend.

We’ve spent decades getting better at protecting identities and the keys they hold. As autonomous agents become part of nearly every business process, protecting those keys will remain necessary, but it won’t be sufficient.

Authentication, authorization, and audit need to be first-class concerns in our architectures, with authorization and audit capable of keeping pace with the speed and reach of autonomous systems.

The problem may no longer be who holds the key, but how many doors that key can ultimately open.

And increasingly, how many of those doors we didn’t even know existed.

Since the Binance investigation is still ongoing, I wanted to post my reading references as of Nov 3, 2026 below