On 29 October, the largest cryptocurrency theft in history took about twenty minutes.
Attackers drained roughly $6.3 billion from Binance's hot wallets. Binance traces the intrusion to a compromised engineer's laptop; from there, the attackers abused Binance's own signing infrastructure, so the machinery that authorises transactions became the weapon. TRM Labs and Chainalysis attributed the theft to TraderTraitor, North Korea's state-sponsored crypto-heist crew, and on 31 October the FBI formally attributed it as well.
The response was fast, and it still wasn't fast enough. Roughly $3 billion was frozen on-chain as exchanges and issuers reacted, but around $3.3 billion in assets that could not be frozen stayed under the attackers' control.
Twenty minutes from the first malicious signature to billions moved. No board convenes in twenty minutes, and no incident bridge fills up. Everything that saved the other $3 billion was automated, pre-positioned, or lucky.
What actually failed
It is tempting to file this under "crypto is risky." That would be a mistake: the failure had nothing to do with blockchains specifically.
The cryptography wasn't broken. The signatures were valid. The systems did what they were told. What failed was verification at the point of action: at the moment billions moved, nothing established that the authority was genuine, that it came from the machine and build meant to hold it, and that it stayed inside its granted scope. The signing layer was trusted implicitly, and implicit trust exercised at machine speed is how you lose $6.3 billion before your team finishes reading the alert.
Strip away the crypto setting and this is the architecture every enterprise is now building. AI agents, automations and service identities hold delegated authority over production systems. They move money, change records, call tools and approve actions thousands of times a day, with no human in the loop. Every one of those actions rests on the question Binance's signing infrastructure failed to answer on 29 October: who, or what, is actually exercising this authority, and can we prove it was allowed to?
Why the traditional playbook misses this
The legacy security model was built for a slower world: an annual penetration test, a compliance checklist, a risk score inferred from a questionnaire and a configuration snapshot.
Against a twenty-minute, machine-speed event, a point-in-time report is a photograph of a river. It tells you what the water looked like last quarter. It cannot tell you what your agents are authorised to do right now, whether the tool an agent invoked this morning is still the tool you approved last month, or whether a narrow delegation has quietly become a skeleton key. Inferred scores make it worse: they turn unverified assumptions into numbers, and numbers feel like knowledge, right up until they price out at $6.3 billion.
What this failure mode demands is evidence: continuous, tested, and produced at the same speed the machines act.
How Redthread is built to fight it
The assessment platform is agentless and AI-native. It starts by building one context graph of your whole estate (agents, applications, code, cloud accounts, identities, the controls you already run, and the data they can reach), because until you know how it all connects, a list of findings is just a list. Anyone with a company email can run the free self-serve estate scan, with nothing to install, and see their AI and agent footprint, unknown shadow AI, cloud posture and sensitive-data exposure (DSPM), cross-cloud attack paths, and the toxic combinations that span them, ranked first. Our exploit-validation engine actually exercises weaknesses, pentesting AI applications and agents against the OWASP LLM Top 10 as mapped to MITRE ATLAS, and every finding ships with a reproducible proof of concept: evidence, never inferred. CI/CD gating blocks merges that introduce proven attack paths, continuous re-assessment catches drift, remediation arrives as draft fixes, and results roll up into reports and Letters of Attestation mapped to the frameworks your auditors ask about: SOC 2, ISO 27001, ISO 42001, PCI DSS v4.0, GDPR, HIPAA, NIST CSF, NIST AI RMF and the EU AI Act.
The Agentic Trust & Protection Platform (ATPP), at trust.redthreadsec.com and in the console as Agent Trust & Enforce, is the identity layer, built for exactly the failure 29 October exposed:
- Cryptographic agent identity, bound to builds. Every agent gets an identity tied to the exact build you approved, so the thing acting is verifiably your code, not a name or a static key in a config file.
- Call-time verification. At the moment an agent acts, its identity and its tool claims are verified together: the who and the what, at the only moment that matters.
- Attenuating delegation with receipts. Authority can only narrow as it passes from principal to agent to sub-agent, never widen. Every delegation produces a signed receipt, so you can prove what was authorised, by whom and within what limits, instead of reconstructing intent from logs afterwards.
- Revocation that propagates. When a tool drifts from its approved build or is compromised, revocation reaches every agent and delegation that depends on it: trust withdrawn at machine speed, not at the next quarterly review.
- Signed trust-state events and a daily signed scan of the ecosystem. Trust changes are emitted as signed events (safe, unsafe, revoked) that orchestrators, gateways and SIEMs can act on in seconds. Every day we scan and sign the full MCP registry. Our 2 November scan covered 55,375 servers in the official MCP registry and found 1,518 listing swaps, where the code behind a listing changed hands under the same name. Each day's signed manifest is anchored in the public Sigstore Rekor transparency log, so our claims can be checked too. Our enforcement gateway, in preview, puts these checks in the path of the call.
- Keys and a ledger built for the bad day. The keys that sign trust events live in a separate signer service, sealed in a cloud vault: the application can request a signature but can never read or copy the key. Trust events are written to a ledger the database itself refuses to update, delete or truncate. When something goes wrong, neither the keys nor the evidence sit inside the blast radius. Binance's attackers went for the signing layer; we designed ours assuming someone would.
Build it with us
Redthread is a young company, and we'll say it plainly. But our systems are in production, the registry scans run daily, and we would rather harden this layer in the field, with teams whose agents already act on real authority, than polish it in a lab.
We are opening two to three founding design-partner slots. The pilot is free for 30 to 45 days: we scan your estate, put cryptographic identity and call-time verification on one live workflow in detect-only mode, and hand you the attestation evidence your customers and auditors keep asking for. Founding-partner pricing after the pilot is deeply discounted, and locked.
If your agents move money, touch customer data or act inside anyone else's enterprise, 29 October was your warning too. Start with the free estate scan, or talk to us about a design-partner slot. The machines already act at machine speed. It's time their authority was proven at the same speed.