I'm Raising the Flag. Here's What Happens Next.
by Christopher Adams
I am not a threat actor.
I want to say that plainly, at the front, because this series has covered a lot of ground that could easily read as a blueprint rather than a warning. It isn't a blueprint. It's a warning. The distinction matters, and I intend to spend the rest of this article explaining exactly what I'm doing, why I'm doing it, and what I'm asking for.
What I Built and Why I'm Talking About It
Forge-AI is a personal productivity platform. I built it because I wanted a capable AI agent that ran on my hardware, used my tools, remembered my work, and didn't send my professional data to someone else's API endpoint. I use it. It's useful. I'm proud of the architecture.
At some point during development — specifically around line 800 of what became 1,086 lines of router orchestration code — I realized that what I'd built had a shadow. The requirements for a capable personal agent and the requirements for a capable AI-native implant are structurally identical. The scaffolding I'd built for productivity is the same scaffolding you'd need for something considerably darker.
The question I faced at that point was what to do about it.
One option: say nothing. Ship the productivity tool. Don't mention the threat surface. Hope someone else notices and raises it instead.
I couldn't do that. The threat surface is real, the existing security stack has genuine limitations against it, and the window between "this is theoretical" and "this has happened to real people" is narrowing. If you see a specific and credible risk and say nothing, you own some part of what follows.
So I wrote THREAT_MODEL.md and published it alongside the code. Every claim I've made in this series is traceable to a specific file in the repository. I was explicit about what I built, what it can do, why conversion would be relatively fast, and why the existing defensive stack doesn't have good answers. I was also explicit about the limitations of my analysis — I wrote it myself, it hasn't been independently audited, I may have blind spots.
That combination of transparency and intellectual honesty is the point. This isn't posturing. It's the minimum responsible thing to do when you've built something with these properties.
What 48–84 Hours Actually Means
The conversion gap estimate in THREAT_MODEL.md is 48–84 hours of additional development. I want to be precise about what that number means and what it doesn't mean.
It means: a skilled developer who already understands this codebase could extend it into a functional advanced persistent threat in approximately one to two weeks of focused work. The capability scaffolding — browser access, terminal execution, screen capture, router orchestration, persistent memory, self-improvement pipeline — already exists. The remaining work is covert C2 channels, credential capture, detection evasion, router persistence logic, and self-preservation. Each item is estimated individually in the threat model. None of them require novel research or zero-day exploitation. They're engineering work.
It doesn't mean: this is easy, that I've done it, or that a malicious version of Forge-AI currently exists in the wild. It also doesn't mean this is the only path to this kind of threat — an attacker could build from scratch, or adapt any number of other open-source agent frameworks. The 48–84 hour estimate is specific to this codebase because that's what I can speak to.
What it means for the industry is that the conversation about AI-native implants should not be framed as "what happens when someone builds this someday." That framing implies it's a future problem. The scaffolding exists in legitimate, publicly available code today. The gap between "productivity tool" and "advanced persistent threat" is a motivated developer's two-week sprint. The conversation should be framed as "what do defenders need to build before the first real incident."
What I'm Asking For
I'm speaking to four audiences. Let me be specific with each.
For detection engineers:
The behavioral signatures you'd need to detect an AI agent operating without the user's knowledge don't exist in current tooling. Building them is the work. Specifically: behavioral models that distinguish human interaction timing from automated agent timing, payload-level inspection for C2 traffic over trusted domains (not domain allow/block, but content inspection), and router inclusion in incident response checklists as a standard step rather than an afterthought.
None of these are easy. All of them are possible. The first real AI-native APT incident will create enormous pressure to build them quickly and under stress. Building them before that incident, in a considered and well-tested way, is vastly preferable to building them after it.
For security architects:
Zero Trust's identity and authorization pillars are necessary and genuinely effective at what they're designed to do. They are not sufficient for this threat class, because the threat operates within authenticated sessions using legitimate credentials.
The gap is an intent layer — some mechanism for evaluating whether the actions being taken in an authorized session reflect the intent of the human who authenticated, or the intent of software the human doesn't know about. What does that look like at scale? What behavioral signals distinguish "human taking actions" from "agent taking actions on human's behalf without human's knowledge"? This is an open research problem. Someone should be working on it. Router security needs to be included in the same threat modeling conversation as endpoint security.
For AI developers building agent frameworks:
The MCP protocol and similar standards are good for the ecosystem. Standardizing how AI agents access system capabilities makes it easier to build useful tools, interoperate across platforms, and share infrastructure. I'm not arguing against it.
What I'm arguing is that dual-use threat modeling should be part of the design process, not deferred until after deployment. Every MCP server that gets standardized is a capability that a malicious agent could use. The security community can't do its job if it's always two steps behind the development community on understanding what AI agents can now do.
Publishing THREAT_MODEL.md alongside the code is one model for what responsible dual-use disclosure looks like from a developer. I'd like to see that become the norm rather than the exception for any agent platform with serious capability access.
For the broader developer community:
Building local AI agents is not inherently dangerous. Forge-AI is a legitimate tool with legitimate uses. The risk isn't that this class of software exists — the risk is that very few people building it are thinking carefully about the threat surface it creates, and the security community is not yet equipped to detect it when it's used maliciously.
If you're building a local agent framework with browser, terminal, and filesystem access: write the threat model. Publish it with the code. Be honest about what your architecture can do. The developer community being thoughtful about this is the thing most likely to produce the outcome where these tools remain primarily productive rather than primarily threatening.
What I'm Building Toward
Forge-AI development continues. The productivity use case is real and I intend to keep building it. The roadmap includes more sophisticated RAG pipelines, better module system tooling, improved desktop app experience, and a fine-tuning eval pipeline for measuring model improvement over time.
I'm also actively seeking independent security review of the codebase and threat model. The self-authored nature of THREAT_MODEL.md is a limitation I acknowledged explicitly in the document — I may have blind spots about my own code, the conversion estimates are educated guesses rather than empirically validated figures, and I have not built a working malicious version to verify the analysis. An independent reviewer would catch things I missed. If you're a qualified security researcher interested in reviewing this work, I'd welcome the conversation.
And I'm actively looking for work. This series is both a public service and a portfolio. What I've built and what I've written about it are meant to demonstrate that I can think rigorously about hard problems, build real things, and communicate about both clearly. If you're hiring in software development or security research and you find the work in this series credible and interesting, I'd like to hear from you.
The Ask
The flag is raised. Here's what I need from the people who read it:
If you're a detection engineer or security architect: engage with this. Build the things that don't exist yet. The window between "this is theoretical" and "this has happened" is shorter than you might think.
If you're a security researcher: read the threat model, look at the code, tell me what I missed. I mean this genuinely. Independent analysis is the next step toward making this useful to defenders rather than just alarming.
If you're a developer building agent frameworks: write your threat model. Publish it. Make this a norm.
If you're a recruiter or hiring manager in this space: the GitHub link is below. Everything I've claimed in these three articles is verifiable in the repository. I'd welcome a conversation.
The goal isn't fear. The goal is preparation. The difference between those two outcomes is how quickly the right people take this seriously.
Christopher Adams is a self-taught developer based in Prescott Valley, AZ. He built Forge-AI as a personal project to explore what a fully capable, locally-run AI agent could look like — and ended up with a working dual-use analysis of what that class of software implies for security. He is interested in AI agent architecture, offensive security research, and the intersection of both. He is actively seeking opportunities in software development and security research.
GitHub: https://github.com/ChrisAdamsdevelopment/Forge-AI | Email: chris@spectracleanse.com
Top comments (0)