Every Tool Is a Weapon You Haven't Renamed Yet
There’s a moment that keeps repeating in my work. I build something useful, something genuinely good, and then — usually within minutes of finishing it — I see the other side. The dark mirror. The same capability, same code, same architecture, aimed differently.
It happens every single time. And if you’re building at the edge of what’s possible and it’s not happening to you, you’re not paying attention.
The Pattern
I build a security scanner in Rust that analyses codebases at 807,000 files per second, designed to catch placeholder code and technical debt left behind by AI coding assistants. It’s a quality tool. A good thing. But a targeted scanner that fast, pointed at a different list of patterns, isn’t a quality tool anymore. It’s a vulnerability finder. The code doesn’t know which list it’s reading. It just searches.
I build a background removal model that processes hundreds of images per second. The demo is fun — cut people out, drop them on silly backgrounds, make a video. Then you realise what else you could do with the ability to isolate human figures from any photograph, automatically, at scale. The model doesn’t know who’s in the image. It just removes backgrounds.
I build a flight tracker app with AI-assisted OCR, a database deduplication system, note-taking, and pattern analysis. Designed for one dataset, it’s an investigative research tool. But the architecture — ingest unstructured data, parse it, deduplicate, find connections, take notes, flag patterns — that’s a general-purpose intelligence analysis system. Swap the data source and the field labels, and the same system maps a completely different kind of network.
I build encrypted self-destructing notes with a zero-knowledge split-token model. It’s a privacy tool. It protects secrets in transit. But a link to encrypted content that self-destructs after reading and leaves no forensic trail is also a delivery mechanism that evades inspection. The cryptography doesn’t know what’s inside the envelope.
Every single time. The tool doesn’t care what it’s used for. It never has. It never will.
The Semantic Layer
Here’s the thing that should genuinely concern anyone thinking about AI security.
Modern AI systems don’t operate on raw machine instructions. They operate on language. They understand context through words. And words can be substituted.
A “flight” can be an airline route or a network path. A “plane” can be an aircraft or a payload. A “destination” can be an airport or an IP address. A “scanner” can look for code quality issues or for vulnerabilities to exploit. The system underneath doesn’t care about the semantics. It cares about the structure. And the structure is identical.
This means any tool that processes natural language instructions — which is every AI agent — has an inherent vulnerability: the gap between what the system thinks it’s doing and what it’s actually doing can be manipulated entirely through language. You don’t need to hack the code. You don’t need to jailbreak the model. You just need to describe the task in terms the safety layer considers benign while the execution layer carries out something else entirely.
The AI’s willingness to help is the attack surface. Its trust in the described context is the exploit.
Why This Matters
I’m not writing this as a warning from the outside. I’m writing it as someone who builds these things and sees the duality from the inside every time. That perspective changes how you think.
When you’ve held the tool and felt both edges, you develop an instinct for it. You start asking “what’s the worst version of this?” before you ship, not after someone demonstrates it. You build the safety scanner because you know what the vulnerability scanner looks like. You add the reveal gate to the encrypted notes because you know what happens if bots can consume the content silently.
The people who are most dangerous with AI aren’t the ones who understand the models. They’re the ones who understand context manipulation — who know that the distance between a helpful tool and a weapon is often nothing more than a rename and a redirect.
And the people who are most valuable in AI safety aren’t the ones writing policy papers. They’re the ones who build things, see both sides, and choose the constructive one while understanding exactly why the destructive one works.
The Uncomfortable Truth
Every encryption tool is also an evidence-destruction tool. Every scanner is also a vulnerability finder. Every autonomous agent is also an autonomous attacker. Every privacy feature is also an evasion feature.
This isn’t a flaw in how we build technology. It’s a fundamental property of capability itself. A knife cuts. What it cuts is a human decision, not a technical one.
The current debate about AI guardrails — whether companies or governments should decide how AI is used — misses this entirely. You can’t put guardrails on capability without also limiting legitimate use. And you can’t remove guardrails for legitimate use without also enabling misuse. The tool doesn’t know the difference.
The only thing that ever knows the difference is the person holding it.
Which is exactly why “who gets to hold it” is the only question that actually matters.
This is the second post in an ongoing series. The machines are here. What now?