In the 2012 Knight Capital runaway trading incident, a missed server deployment reactivated dormant code that sent millions of unintended equity orders into the market over 45 minutes, producing a loss of approximately $440 million and effectively destroying the firm.
On 1 August 2012, Knight Capital Group deployed new trading software to its servers ahead of a market open. The code reached seven of eight production servers. The eighth was missed. According to the SEC's order, that eighth server still carried dormant code known internally as Power Peg, which a reused configuration flag reactivated. When the market opened, the firm's systems began sending millions of unintended orders into the market.
The orders ran for roughly 45 minutes. By the time the flow was stopped, Knight had executed millions of trades and was left holding positions that produced a loss of approximately $440 million. The firm, one of the largest equities market makers in the United States, was effectively crippled within a single trading session and was acquired soon after.
The Securities and Exchange Commission later found that Knight had violated the Market Access Rule, Rule 15c3-5, which requires brokers with market access to maintain controls over the orders they send. Knight settled the charges and agreed to pay a $12 million penalty, as detailed by WilmerHale.
What actually failed - the governance gap
Two failures stacked on top of each other. The first was a deployment that did not match across the fleet. One server ran an old, unapproved code path while the rest ran the new one. Nothing in the runtime refused to act on the basis of the version it was running.
The second was the absence of a hard stop on the order flow itself. Once the dormant code began firing, there was no checkpoint that paused a high-volume, irreversible stream of orders for a human to confirm before it continued. The orders went out, settled into positions, and could not be unwound at the price they were sent. An action stream that cannot be taken back was running with nothing standing between it and the market.
Knight was a deterministic system, not an AI agent. The structural lesson is the same one that applies to automated agents today. When a process can take a consequential action without confirming what version of itself is approved to run, and without a gate on the irreversible part, a single mismatch becomes a firm-ending event.
How MakerChecker changes the outcome
MakerChecker governs the action an automated actor is allowed to take, not the quality of the code behind it. Two of its capabilities map directly onto the two failures.
Version-pinned grants address the dead-code problem. A role is granted a skill at a specific approved version. If the runtime presents an unapproved version, the grant does not match and the call is refused. A configuration like the one in the runnable example pins the order-flow skill so an unapproved version is denied before any order leaves:
role: order-router
grants:
- skill: order.submit
version: "2.0" # only the approved version may act
risk_tier: high
Dormant code running on a stray server would present a version the grant does not recognize, and the action would be refused rather than executed.
Approval gates supply the missing kill switch. Model the high-volume or over-notional path as a separate high-risk skill that routes to a gate. Routine in-tier flow runs without friction. An order stream that crosses an approved notional threshold parks and waits for named human sign-off before it continues:
skill: order.submit
risk_tier: high
gate:
threshold_notional: 50_000_000
approvals_required: 2 # n-of-m named humans
forbid_requester: true # proposer cannot self-approve
Segregation of duties through forbid_requester keeps the system that proposes
the flow from approving its own escalation. Every grant check, every denial, and
every approval is written to the tamper-evident, Ed25519-signed, hash-chained
audit. After an incident, an investigator can verify offline which version fired
which orders, rather than reconstructing it from logs after the fact.
What MakerChecker would not fix
MakerChecker would not have caught the deployment mismatch itself. It is not a CI/CD verifier and does not check that the same build reached every server. It would have changed the outcome only if the release ran through a gated skill and the order flow ran through version-pinned grants, so that the stray server's old code presented an unapproved version and was refused.
It is also not a trading risk engine. It does not judge whether an order makes economic sense, model market impact, or price positions. Knight's underlying defect was deterministic software, and MakerChecker does not repair faulty code. What it does is convert an irreversible action stream that ran unchecked into one that is refused on a version mismatch or held at a gate, with a signed record of exactly what happened.
See the configuration: examples/rogue-ai/knight-capital-440m-runaway-trading