Most security conversations about geopolitics focus on nation-state hackers breaking in from the outside. But some of the most consequential risks come from people who already have a badge, a laptop, and a Slack account.

As AI model weights, training data, and chip-level designs become strategic assets, the engineers who touch them become strategic targets. That doesn’t mean anyone is a spy. It means your access model should assume that pressure, coercion, recruitment, and deception are all realistic threats, and that none of them require a villain on your team.

The Threat Isn’t Always a “Bad Employee”

Insider risk is usually discussed as malice, but in practice it falls into three buckets:

Malicious insiders, who knowingly exfiltrate data.
Coerced or compromised insiders, who are pressured through family ties, financial stress, or blackmail.
Deceptive hires, who aren’t who they claim to be. Publicly documented schemes involving fraudulent remote IT workers using falsified identities show this isn’t hypothetical.

Remote-first hiring widened your talent pool, and it also widened the attack surface for identity fraud. Your threat model has to account for all three buckets, not just the first.

Treat Model Weights Like Production Secrets

If your organization trains or fine-tunes models, the weights are a crown-jewel asset, probably more valuable than your source code. Yet many teams store them in shared storage with broad read access “for convenience.”

A few baseline controls:

No standing access. Engineers request time-boxed access with a reason attached, and it expires on its own.
Fresh authentication. Access to sensitive artifacts should require a recent multi-factor check, not a login from three days ago.
Trusted networks only. Reads should come from known, managed environments rather than any laptop on any Wi-Fi.
Two-person rules for bulk export or cross-region replication.
Egress monitoring tuned to large, unusual transfers, not just known-bad destinations.
Immutable audit logs stored outside the blast radius of the people being audited.

None of these is a complete solution on its own, but together they remove a lot of silent, long-lived access.

Offboarding Is Where Good Intentions Go to Die

Teams invest heavily in onboarding and almost nothing in exit. Yet departures, especially to competitors or across borders, are a classic window for data loss.

A solid offboarding process should be automated and consistent, not a checklist someone forgets:

End all active sessions and rotate any shared secrets the person touched.
Remove repository, registry, and deployment permissions.
Revoke personal access tokens and SSH keys, then check for keys they created for automated systems.
Review the last 30 to 90 days of access logs for unusual bulk downloads or clones.
Retrieve and wipe devices, and revoke device certificates.

If this takes a ticket and three chat pings, it will fail under pressure, so tie it directly to your HR system’s termination event.

Make Security Culture Human, Not Paranoid

There’s a real risk of overcorrecting into a culture of suspicion. Surveillance-heavy environments burn out good engineers and push people to hide mistakes. The goal isn’t to distrust your colleagues, it’s to design systems where no single person’s compromise is catastrophic.

That means:

Normalizing “I got a weird LinkedIn message” as a reportable event, not an embarrassing one.
Giving employees a safe channel to say they’re being pressured, without career consequences.
Training on social engineering with realistic scenarios, like fake recruiters, conference contacts, or “research collaborators” asking for just a little detail.

The Open Source Angle

Many of the same dynamics apply to open source, where trust is built over years and can be exploited in a single release. Maintainers are often unpaid, overloaded, and isolated, which is exactly the profile that social engineering preys on. If your product depends on a critical library, consider funding it, contributing review capacity, or at least pinning and verifying what you consume.

Final Thoughts

Geopolitics shows up in the dev stack in unglamorous ways: an over-permissive access role, an unrotated token, an offboarding step that never ran. The engineers who treat these as security fundamentals rather than compliance chores are the ones who make their organizations resilient.

You don’t need to follow every headline to act on this. You just need to ask, for every sensitive asset you touch: If one person with access were compromised tomorrow, what’s the worst that could happen, and how quickly would we know?