A post circulated this week showing a developer who built what he calls the "I Got Fired" button. One click. The entire company codebase goes public. Environment files with API keys and credentials are pushed to a public repository. The staging database drops. The lawyer gets a call.

He said he hopes he never needs it.

He built it anyway.

Whether this is satire or a genuine doomsday device sitting on someone's desk right now, the threat model it describes is real. And most organizations are not prepared for it.

This Is Not a New Problem

Insider threat is one of the oldest challenges in security. The disgruntled employee, the departing contractor, the engineer with access they should have lost six months ago. Security programs have modeled this for decades.

What has changed is the blast radius.

Ten years ago, a malicious insider could steal files, delete records, and send an email to a competitor. Damaging, yes. Recoverable, often. The scope of destruction was limited to what a human could do manually before detection.

Today, a developer with the right access, two hours of automation work, and enough grievance can build a dead-man's switch that executes a coordinated multi-system attack the moment a single button is pressed. The codebase exposure, the credential leak, the database deletion, the legal notification -- all of it happening simultaneously, faster than any incident response team can react.

That is a qualitatively different threat, not just a quantitatively larger one.

What Your Insider Threat Program Is Probably Missing

Most insider threat programs were designed to detect and deter. Behavioral analytics, access monitoring, and exit interview protocols. The assumption is that humans who do harmful things leave human-speed signals that enable human-speed intervention.

Automation breaks that assumption.

The malicious action in the scenario above was not taken in the moment of anger. It was built in advance. The button was ready before the firing happened. By the time the threat materialized, the preparation was already complete. There was no window to detect intent and intervene.

This requires a different frame.

The question is no longer just "what is this person doing right now?" The question is "what has this person already built?"

That distinction matters enormously for how you design controls. Monitoring current behavior is necessary but no longer sufficient. You need visibility into what automation, scripts, and tooling exist within your environment -- who built them, what they do, and whether they create concentrations of destructive access that bypass normal approval gates.

The Four Signals Read

Through the Four Signals lens, this scenario lights up across multiple dimensions.

Ownership is the first signal. Who owns the access, and is that ownership documented, reviewed, and revocable? If an engineer has broad repository access, database credentials, and the ability to push to production, that concentration of authority should trigger periodic review regardless of tenure or trust level. The question is not whether you trust the person. The question is whether the access profile makes sense given the role.

Exposure is the second. Credentials in environment files, broad repository write access, database drop permissions -- these are exposures that exist independent of insider intent. They represent an attack surface that a malicious insider can exploit, but also a surface that an external attacker would target if they compromised that user's account. The insider and external threats share the same entry points.

Authority is the third. Can one person, acting alone, execute a sequence of actions this destructive? If yes, your authority model has a gap. Destructive actions at this scale should require multiple actors, multiple approvals, or architectural controls that prevent single-point execution.

Response is the fourth, and the hardest. The scenario described executes faster than any human response loop. That means your response capability needs to be pre-positioned. Automated containment. Immutable backups. Access revocation workflows that fire in seconds, not hours. If your incident response plan still assumes you will have time to convene, assess, and act, you are planning for a threat that no longer exists.

Monday Morning Takeaway

Pull your access review list and look for users who simultaneously have write access to code repositories, production credentials, and database administration. That combination -- in a single account -- is a red flag regardless of trust level. It is not an accusation. It is an architecture problem. Fix the architecture.

Tim Reed, CPP, is Director of Security at Aurora Innovation and founder of The Reed Group, an AI governance advisory practice. Northern Signal publishes at northernsignal.com.