Fired, then the servers started deleting: engineers who wiped their old companies
Developers have deleted their old employer’s data on the way out, and more than one has gone to prison for it. The stories run together: someone leaves or gets pushed out, the company forgets to close a door, and weeks later the servers start disappearing. None of it needed a sophisticated hack. It needed access that outlived the person, and nobody watching what that access did.
The Cisco engineer who deleted 456 machines
A cloud engineer resigned from Cisco in April 2018, and his access to the company’s AWS environment was never switched off. Months later he logged back in and deleted 456 virtual machines that ran WebEx Teams.
The damage was not small. More than 16,000 accounts went dark for up to two weeks, and Cisco spent roughly $1.4 million in staff time putting it back together, plus over a million in refunds to customers. He was sentenced to two years in prison and fined. The Department of Justice filing is blunt about the cause: the credentials should have been dead, and they weren’t.
The Singapore engineer who scripted the wipe
A different flavour of the same story played out at NCS in Singapore. An engineer let go for poor performance kept working credentials after his exit, logged back in more than a dozen times, and eventually ran a script that deleted 180 virtual servers.
He didn’t write anything clever. Reporting says he found the script online and pointed it at the test environment he still had access to. Recovery ran to around S$678,000, and he was jailed. He didn’t break in anywhere. He was simply never locked out.
Eaton: the bomb that armed itself
The Cisco and NCS cases needed the person to come back and pull the trigger. The Eaton case didn’t. A developer there planted a logic bomb designed to go off the moment his account was disabled, so the company’s own offboarding lit the fuse.
That’s the version that should worry a small team most. It gets set up while the person still looks like a trusted employee, then sits inside the normal pile of automation, waiting for a trigger nobody knows is there.
The thread running through all of them
Across these three, it kept coming back to the same gap. Access that outlived the person, and no one watching the actions.
Offboarding is where the first one hides. Most checklists close the login and assume the rest followed, but a leftover key or a scheduled job the person set up keeps running on its own. Disabling an account does nothing to a script that already carries its own permissions.
The second is quieter. These companies had logs. But a log is a recording of what happened, not a brake, so by the time anyone read it the machines were already gone.
How not to be the next headline
Better hiring won’t save you here. These were trusted employees, vetted and paid, until the day they weren’t, and no interview catches that. The fix is structural, and it holds up the same way whether the danger is a bitter former employee, a stolen key, or an AI agent that goes off the rails.
Close every path in the day someone leaves, not just the login. Remove standing admin rights so no single person carries account-wide delete, and hand out access just-in-time so it expires on its own, leaving nothing lingering to abuse. Then watch the privileged actions themselves, so a run that starts emptying the account gets cut while it’s running, not found the next morning.
If you want the mechanics of how a departing engineer actually sets one of these up, and how each layer stops it, we broke it down in the offboarding time bomb.
Where Korvalis fits
This is the gap Korvalis is built for. It runs inside your own cloud account and reads what a session is doing as it happens, so the moment a run starts tearing through resources it can pull the plug in seconds, on its own. Whoever set it off, a leaver, a stolen key, an agent gone wrong, the account never has to wait for someone to be awake and paying attention.
It also stops handing out permanent keys. Access is granted for the task and expires by itself, so far less standing power sits around for anyone to inherit or leave behind. It goes in watching first, blocks only once you trust it, and is running in an afternoon without a dedicated security person.
It won’t turn a vengeful leaver into a saint or make your checklist airtight. What it does is make sure that when access slips through and offboarding misses something, the destructive part gets caught in the act instead of read back to you from a log. If any of these stories felt a little too close, take a look at the waitlist and we’ll walk you through it on your own account.
Common questions
Has a developer ever deleted their company’s data after being fired? Yes, and courts have jailed them. A former Cisco engineer deleted 456 virtual machines months after resigning, a fired NCS engineer in Singapore scripted the deletion of 180 servers, and an Eaton developer planted code set to fire when his account was disabled.
What is a logic bomb? Code left behind that runs on a trigger, like the moment its author’s account is disabled, so firing the person sets it off. It stays invisible without monitoring of what privileged automation actually does.
How do companies let this happen? Offboarding revokes the login and stops there, so keys, roles, and scheduled jobs the person made keep working, and with no live monitoring a mass deletion is only caught once the outage starts.
How do you stop an insider from deleting everything? No single control does it. Cut every route back in on their last day, make sure no one person can wipe an account alone, keep access short-lived so nothing lingers, and put a live check on privileged actions so a mass deletion is stopped mid-run rather than after.