In September an attacker moved $387.5 million out of Bitget without stealing a private key. The forensic reports published since describe something more uncomfortable than a theft. The withdrawal system was never broken. It was studied for three and a half weeks, and then handed instructions it had been built to approve.
The failure was not custody and it was not cryptography. It was autosigning: funds moved because code evaluated rules, and no person evaluated meaning. Every AI agent that executes trades rests on the same arrangement, because taking the human out of the moment of execution is the entire product. The four questions below are how you find out how much authority yours has, and what it would cost you if someone learned its rules.
What autosigning is
Autosigning is any arrangement in which software produces a valid cryptographic signature for a value-moving transaction without a human reviewing that specific transaction first.
The phrase covers a wider range of setups than most people picture. An exchange's internal system that signs withdrawals after automated checks is autosigning. A trading bot holding a hot key is autosigning. A token allowance you granted once and never revoked is a form of deferred autosigning, because you pre-authorized a contract to move your funds under conditions you are no longer watching. A session key with a spending cap is autosigning with a ceiling.
What these share is one property. At the moment funds move, the decision to move them was made by code evaluating rules, not by a person evaluating meaning.
What happened at Bitget, mechanically
On 24 September 2026, Bitget detected unauthorized transfers out of its hot and warm wallets. The figure settled at $387.5 million across 11 blockchains, revised up from an initial estimate of $351.6 million. Cold wallets were not affected. Withdrawals were suspended and then restored in stages, completing on 2 October. Bitget absorbed the loss rather than passing it to users. Recovery has been small: roughly $1.1 million frozen by Circle, Tether and NEAR Intents, about 0.3% of what was taken. (BleepingComputer, CNBC)
No private key was stolen, a point Bitget's chief executive went on the record to make once the first reports had settled on key theft as the explanation. Per investigations by SlowMist and Mandiant reported at the start of October, the attackers exploited a zero-day vulnerability in a third-party security product running inside Bitget's environment, ran a hidden script to read a database password out of a service's environment variables, and established access from there. SlowMist dates the earliest malicious activity in the available logs to 31 August 2026. The transfers happened on 24 September. (The Hacker News, citing SlowMist and Mandiant)
That is roughly three and a half weeks inside before anything moved, and the attackers used the time. Mandiant found that they deployed a web shell on the compromised security appliance, established a command-and-control channel, and moved laterally to Bitget's production wallet job server, where they deployed malicious packages. SlowMist recovered a deleted tool from the environment and described it as highly tailored to the wallet system's withdrawal logic. Bitget's own account is that the attackers obtained high-level internal credentials and used them to issue fraudulent withdrawal commands, producing "abnormal transfers that bypassed existing risk controls."
So the sequence was: get in through the security software, stay three weeks, learn exactly how the withdrawal pipeline decides what to approve, build a tool that speaks that pipeline's language, and then ask it for the money.
The signing system was not broken. It was studied, and then satisfied. No cryptographic fix is available for that, because nothing cryptographic failed. Every control the pipeline enforced was enforced correctly, on instructions that no human ever read.
Bitget says IP behaviour patterns and on-chain analysis point to North Korean actors, and Elliptic and TRM Labs have reported overlaps with laundering wallets from earlier thefts. The argument below does not depend on the attribution.
The way in was a security product
The entry point was software Bitget had bought in order to be safer. A security appliance sits inside the trust boundary by definition, which is what makes it useful and what makes it worth attacking. Bitget has since notified the vendor and disabled the affected functionality pending a fix.
Carry that over to anything you let near your own funds. The agent's own code is one question. The RPC endpoints it calls, the price feeds it trusts, the libraries it imports, and the extension it signs through are all part of the same surface, and you have audited none of them.
Why this is not an exchange story
The reflex after any exchange breach is to reach for custody. Move your coins off, hold your own keys, and the problem is solved.
Custody is a real variable and it matters. But framing Bitget as a custody story misses what the incident demonstrated, which is more uncomfortable and much more current: an automated approval pipeline can be reverse-engineered by anyone who gets three weeks inside it, and then fed instructions it is designed to approve.
Now consider what the crypto industry spent 2026 building. Agents that read markets and execute. Bots that rebalance while you sleep. Assistants that take a natural-language instruction and turn it into a chain of on-chain actions. Every one of these products exists to remove the human from the moment of execution, because that removal is the product. Nobody wants an agent that needs you awake.
So the question is not whether AI agents will autosign. Most of them must, or they do nothing. The question is how much authority the autosigning has, and what the blast radius is when something feeds it a well-formed lie.
Note what makes a ruleset attackable: it is consistent. Automated approval has to be deterministic to be useful, which also means it is learnable. Given enough access and enough patience, a determined attacker does not need to defeat the rules. They need to read them.
Bitget is the first time that failure mode detonated at institutional scale in public view. It will not be the last, and the next one is more likely to be a consumer agent than an exchange.
The spectrum of signing authority
Custodial and non-custodial is too coarse. There are at least four positions, and they carry different failure modes.
| Arrangement | Who can move funds | Failure mode | Blast radius |
|---|---|---|---|
| Full custody | The platform, under its own controls | Platform internal compromise, of which Bitget is the reference case | Everything the platform holds, pooled |
| Delegated keys | A bot or agent holding a hot key on your behalf | Key extraction, or the agent being fed bad instructions | Everything that key controls |
| Session keys and allowances | A contract or agent, up to a pre-authorized limit | Forgotten standing approvals; a compromised contract draining within its cap | Whatever you pre-approved, which is often unlimited |
| Per-transaction human signature | Only you, once per transaction | Phishing, blind signing, social engineering | One transaction, if you read it |
The bottom row does not say "safe." It says the blast radius is one transaction, which is the security property actually on offer.
The four questions
Who holds the key that can move funds?
Not "who custodies the assets," which invites a marketing answer. The specific question is which party is in possession of the signing material that can produce a valid transfer.
If the answer is any party other than you, then that party's internal security is now your security, including their backend systems, their deployment pipeline, their vendors, and their worst day. Bitget's users were not compromised. A security appliance in Bitget's environment was, and that was sufficient.
There is a second half to this question that almost nobody asks: whose code can reach the thing that signs? The key holder is one answer. The list of software with a path to the key holder is a much longer one, and in Bitget's case it included a product bought specifically to reduce risk.
How much can a single forged instruction move?
This is the question nobody asks and the one that determines what a breach costs you.
An agent that can move your entire balance has an unbounded blast radius. An agent capped at a fixed amount per transaction, per day, per counterparty, has a bounded one. In an attack that works by making bad instructions look good, the cap is the only control that survives, because every other control has already been satisfied.
Ask for the number. Bitget shows what its absence costs: the pooled hot and warm wallet infrastructure had no per-instruction ceiling that stopped the sequence, $387.5 million left across 11 chains, and roughly $1.1 million of it has been frozen.
Does a human review the meaning of the transaction, or only its format?
Automated validation checks whether a transaction is well-formed: correct fields, valid signatures, consistent state, within the rules. It cannot check whether the transaction is one you wanted, because wanting is not a property of the bytes. The only component capable of evaluating meaning is a person who knows what they intended to do.
This is also why "you sign every transaction" is a weaker claim than it sounds. A human who approves a wallet prompt without reading it is a slower, more expensive version of an autosigner. The security comes from the review, not from the tap. Any product that puts a human in this loop and then designs the prompt to be skipped quickly has kept the liability and thrown away the benefit.
What standing approvals already exist on your wallet?
Most people running this test on a new agent are carrying unbounded risk from an old one.
Token approvals persist. You granted an allowance to a DEX in 2024, the interface asked for an unlimited amount because that saves gas later, and that allowance is still live. If that contract is ever compromised, the attacker does not need your key. You already signed.
This is the self-custody failure mode that the custody debate skips over. Your keys can be perfectly safe while your permissions are the problem.
Self-custody is not the answer, it is a different question
Holding your own keys does not reduce risk. It relocates it. You remove exposure to a platform's internal compromise and you accept exposure to phishing, malicious signature requests, wallet-draining sites, address-poisoning, and your own attention on a bad night. Losses in that category are not rare, and unlike Bitget's users, you have no protection fund.
The industry's own educators say this openly. Ledger Academy, whose commercial interest is in selling self-custody hardware, publishes a piece called "Addressing Self-Custody's Greatest Misconceptions." When the vendor says their own product has misconceptions worth addressing, the misconceptions are probably real.
Neither model wins outright. What you should be able to do is name which risks you have taken on, and the four questions are how you find out.
Where Nina sits
Nina is Antalpha's Web3-native AI agent (NASDAQ: ANTA). It reads markets across crypto, prediction markets and US stocks, and drafts transactions that the user signs from their own wallet.
We built Nina around a signature gate. Antalpha's documentation describes the architecture as a five-step flow where step 4 is the gate: the transaction is drafted, and the user signs. The documentation says it plainly: control of a user's assets "always stops at step 4 — in your own wallet."
Run the four questions against it. The user holds the key, because Nina connects to the user's own wallet and never stores one. The blast radius of a single forged instruction is one transaction, and only if the user signs it. The review of meaning happens at the signature gate, where approval is a separate human act the architecture cannot skip. Standing approvals are the one place Nina acts on your behalf rather than waiting: it runs a wallet approval checkup across chains, surfaces risky allowances, and revokes them with a single signature, and it scans a token contract before a swap and blocks the trade if the contract is dangerous.
The third question is only as strong as the user makes it. Nina moves the review to the user, which is where it belongs, and a user who approves without reading has given that protection away. No architecture fixes this.
Nina is an intelligence layer, and it is not a security product. It reports the freshness and origin of the data behind every answer through a badge with states for verified, delayed, partial and insufficient, and it declines to produce a number when the data does not support one. The full source list with each source's update cadence is published at How Nina Works. That is a transparency mechanism for analysis, and it is not an audit of the chains you transact on.
You should not have to take our word for the approvals part either. Any block explorer will list the allowances sitting on your address. Nina's checkup should agree with it, and if the two ever disagree, trust the explorer.
What this means for anyone running an agent
The useful work takes about ten minutes and none of it requires a tool.
Run an approval checkup on your wallet and revoke every allowance you do not currently need. Most people find at least one unlimited approval they had forgotten about, granted to an interface they no longer use. Then, for every agent, bot or platform that can touch your funds, write down the answer to the second question. If you cannot find a number, the exposure is your full balance, and the absence of a published cap is itself the answer. Finally, the next time a wallet prompt appears, read the destination and the amount before approving, because that reading is the entire value of per-transaction signing and skipping it hands the value back.
What Bitget demonstrated is not that automated systems fail. It is that they succeed, exactly as specified, for whoever has taken the time to learn what they will accept. An approval pipeline is a published ruleset to anyone standing inside it, and the only component that cannot be studied into compliance is a person who knows what they meant to do.
Frequently asked questions
What is autosigning in crypto?
Autosigning is any arrangement in which software produces a valid signature for a value-moving transaction without a human reviewing that specific transaction first, including exchange backend signing pipelines, bots holding hot keys, and standing token allowances.
Was the Bitget hack caused by stolen private keys?
No. Investigations by SlowMist and Mandiant found that attackers exploited a zero-day vulnerability in a third-party security product inside Bitget's environment, moved laterally to the production wallet job server, and used high-level internal credentials to issue fraudulent withdrawal commands that bypassed existing risk controls. No private key was stolen.
Does self-custody make crypto safe?
No. Self-custody removes exposure to a platform's internal compromise and adds exposure to phishing, malicious signature requests, wallet drainers, and forgotten token approvals. It changes which risks you hold rather than removing risk.
What is the most overlooked wallet security risk?
Standing token approvals. An unlimited allowance granted once to a contract remains active indefinitely, and a later compromise of that contract lets an attacker move funds without ever touching a private key.
Can Nina move funds without the user's signature?
No. Nina connects to the user's own self-custodial wallet, never stores a private key, and requires the user to sign every transaction from their own wallet.
How did attackers get into Bitget?
According to SlowMist and Mandiant, the attackers exploited a zero-day vulnerability in a third-party security product running in Bitget's environment, with the earliest malicious activity dated to 31 August 2026, then moved laterally to Bitget's production wallet job server before transferring funds on 24 September 2026.
Are AI crypto trading agents safe?
Safety depends on the signing architecture rather than on the quality of the model. Ask who holds the key that can move funds, how much a single instruction can move, whether a human reviews transaction meaning, and what standing approvals already exist.
Nina is the Web3-native AI agent from Antalpha (NASDAQ: ANTA), covering crypto, prediction markets and US stocks: conclusion-first analysis with named sources and freshness badges, and Sentinel mode for continuous monitoring. Self-custodial. Never holds funds, never trades for the user, takes no cut of principal or profits; a transparent routing fee applies on the execution path. Nothing here is investment advice or a price prediction. Official channels: antalpha.com, "Antalpha AI" on the App Store and Google Play, x.com/antalpha_ai.
Related reading: Most Polymarket "edges" are not real: the five-step check for 2026.
