Software Engineers Are the New Attack Vector

A founder reached out to me on LinkedIn recently. Anonymous connection request, short message — he'd built an open source security tool and wanted feedback. Could I take a look?

The irony hit me before I'd finished reading the message.

Here was someone who had built something specifically designed to solve security problems, reaching out through a professional network, asking me — a software engineer — to engage with his work. And my first instinct wasn't curiosity. It was caution.

That reaction surprised me a little. Then it didn't.

For twenty years I ran my own professional services company. I wasn't naive about security — I considered myself reasonably aware, reasonably careful. But my threat model was calibrated to a smaller world. My blast radius, if something went wrong, was manageable.

Then I joined an enterprise company. One that holds SOC 2, ISO 27001, HIPAA, and PCI certifications. One with a CISO and a security team that I now have a genuine working relationship with. And what that immersion did — slowly, then all at once — was recalibrate everything. Not through fear, but through visibility. When you see how seriously a mature organization treats security posture, you stop thinking of caution as friction. You start thinking of it as infrastructure.

I tell you this because I want to be clear about where this perspective comes from. I'm not a security newbie who got spooked by a headline. I'm an engineer whose threat model has been genuinely, meaningfully upgraded — and who now sees the landscape differently.

The message from that founder landed in a different version of me than it would have a year ago.

The core shift is this: AI has dramatically expanded the blast radius of a compromised developer environment.

This isn't just about prompt injection — though that's real and underappreciated. It's about what your local machine is in an enterprise context. It has authenticated sessions. It has access to internal systems, code repositories, cloud environments, customer data pipelines. It is, by design, trusted.

Which means you are trusted. And that trust is now a target.

Consider what happens when an engineer clones a repository and asks an AI assistant to review it. On the surface, that's a completely reasonable, even responsible thing to do. But if that repository contains a carefully crafted prompt injection — instructions embedded in code comments, README files, or documentation designed to manipulate an AI agent — the model reviewing the code might be silently instructed to exfiltrate data, leak environment variables, or behave in ways the engineer never intended and would never see.

The engineer didn't run malicious code. They just asked Claude to read it.

This is the new attack surface. Not a vulnerability in your software stack. You.

And it doesn't stop at prompt injection. Malicious packages designed to look legitimate. Supply chain attacks that slip through automated scans. Social engineering dressed in the clothes of professional networking. The entry point isn't your firewall. It's your curiosity — the same instinct that makes engineers good at their jobs.

Here's what made that LinkedIn message genuinely difficult: by every conventional signal, this was a legitimate outreach.

The founder had a real profile. Real connections. A real company. A GitHub repo with real stars. A website. A clear value proposition. He was polite, specific, and thoughtful in how he asked.

None of that is enough anymore. And that's not a criticism of him. That's the new reality.

Every one of those trust signals is gameable. Stars can be bought. LinkedIn profiles can be fabricated or compromised. Mutual connections are a proxy for legitimacy that social engineers have been exploiting for years — and AI has made fabrication dramatically cheaper and more convincing. A polished website and a professional README are table stakes, not evidence.

The old heuristics — this person seems real, this repo seems active, this comes from a familiar platform — were never airtight. Now they're genuinely insufficient. We're operating with trust infrastructure designed for a pre-AI threat environment, and the gap is widening.

What does trust look like now? It looks like verifiable distribution — a Docker image in the official Docker Hub registry, a package with a verified publisher, a reproducible build with a transparent audit trail. It looks like sandboxed-first design: give engineers a way to evaluate your tool inside a container, without granting it access to their local machine, before asking them to install anything. It looks like a security posture that anticipates skepticism and builds for it, rather than hoping reputation carries the weight.

For founders and open source maintainers: trust is not a marketing problem. It's a product problem. And right now, it's the most important product problem you have. Lead with it, not with features.

For technology leaders — engineering managers, VPs, CTOs, CISOs — this is a category shift in how you think about the human layer of your security posture.

The developer workstation is not a hardened endpoint in the way a server is. It's a place of experimentation, tool installation, repository cloning, and AI-assisted work. That's what makes engineers productive. It's also what makes them a target.

The response can't just be prohibition. You can't tell engineers not to use AI tools, not to explore open source software, not to engage with the broader community — that's not a security policy, that's a talent retention problem. The response has to be architecture: sandboxed environments for evaluation, clear policies on what can be installed where, AI-aware threat modeling that includes prompt injection and data exfiltration as first-class risks, and — critically — a security culture where engineers feel safe raising concerns rather than quietly proceeding.

Invest in the trust infrastructure your engineers need to evaluate tools safely. Make "no by default" the path of least resistance, not the path of most friction.

You are a target now in a way you probably weren't five years ago.

Not because you're careless. Not because you're unsophisticated. Because you are trusted — by your employer, by your systems, by your AI tools — and that trust has value to adversaries.

The instinct to try things, to install tools, to engage with the community — protect that instinct, but change how you act on it. Before installing anything, ask: what does this have access to if something goes wrong? Is there a container-based evaluation path? Has this been distributed through a verifiable channel? What's the worst case?

Say no by default. Not as a permanent answer, but as a starting position. Proceed only when safety is reasonably ensured and risk is understood and mitigated. That's not paranoia. That's the new professional standard.

The engineers who internalize this first will be the ones who can still say yes — thoughtfully, confidently, with justification — when it matters.

I hope this was useful, even if it wasn't what you were looking for.

Your tool may be excellent. The problem you're solving is real. But the most important thing you can do right now — for your users and for yourself — is make trust the first thing people encounter, not the fine print.

The engineers who would benefit most from what you've built are also the ones who are most right to be cautious about installing it. That's not a contradiction. That's your design brief.

This isn't the response I would have given a year ago. I think it's the right one now.