DEV Community: duncan n. ndegwa

I Published Security Research Papers While Building DevFortress

duncan n. ndegwa — Wed, 10 Jun 2026 07:29:55 +0000

This post originally appeared at devfortress.net/blog/research-behind-devfortress

Before DevFortress had its first subscriber, it had research papers.

Not because I planned it that way. When I started designing the credential
isolation system — the part where your monitoring platform receives token
aliases instead of real credentials — I realised I had to document the
theory properly before I could defend the architecture to anyone who
mattered. Investors. Potential acquirers. Engineers who would actually
integrate it.

So I wrote the papers. Filed the patents. Then built the product.

This post explains what I found — and why the research changed how I
built DevFortress.

Why a Solo Founder in Nairobi Published Security Research

The short answer: prior art.

If you build something genuinely new in security architecture, you face
two risks. First, someone patents the idea you just shipped. Second, no
one believes the approach is novel because there is no published record
of it.

Research papers solve both problems. Once your architecture is formally
described in a peer-reviewed preprint, it establishes a date and a
public record. No one can claim they invented it after that date. And
any engineer who reads the paper can see that the reasoning holds.

I also filed four provisional patents with the Kenya Industrial Property
Institute (KIPI KE/P/2026/005970–005973) before writing a single word
of marketing content. Filing first, publishing second — that is the
sequence that protects you.

What the Two Published Papers Found

I have two papers live on SSRN at this point. Here is what each one
actually found, in plain terms.

Paper 1 — Why API Monitoring Tools Accumulate the Credentials

They Were Built to Protect

SSRN: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6813141

This paper starts with a question that sounds obvious once you ask it:
if your security monitoring tool needs to watch your API sessions, does
it need your real session tokens to do that?

The answer is no — and the fact that nearly every existing tool does
store real tokens is the structural problem the paper addresses.

When a monitoring platform holds a copy of your real session token, you
have created a second attack surface. A breach of the monitoring tool
is now equivalent to a breach of every application it monitors. The
paper calls this the credential accumulation problem.

The proposed fix is credential isolation: the SDK generates a random
alias that has no mathematical relationship to the real token, and sends
only the alias to the monitoring platform. If the platform is breached,
attackers get random strings that authenticate nothing.

This is the core architecture of DevFortress.

Paper 2 — The Three-Mode API Protection Framework

SSRN: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6813640

Most API security tools work in one mode: they monitor traffic and alert
you when something looks wrong. The second paper examines why this is
insufficient — and what a complete protection system looks like across
three distinct operational modes.

The three modes are: Observe (monitor without intervention), Enforce
(block requests matching defined threat patterns), and Respond (close
the loop automatically when a confirmed threat appears).

The key finding: "alert and wait" security has a structural speed
problem. Attackers need seconds. Human response takes minutes or hours.
Automated closed-loop response — detect, revoke session, block IP,
confirm — closes this gap. DevFortress executes this in under 2 seconds
without waiting for a human.

The Papers and the Textbook

The papers answer a specific question: what should the architecture
guarantee?

They do not answer: here is the code that implements it.

The implementation — production TypeScript, exact algorithms, 703
validation tests, and the full architecture of all 34 patent-pending
inventions — is in the DevFortress Master Edition textbook.

The papers are free on SSRN. The textbook is the bridge from "I
understand the architecture" to "I can build this."

→ Read the research at devfortress.net/blog/research-behind-devfortress
→ Master Edition textbook: devfortress.gumroad.com/l/master-edition
Use code RESEARCH15 for 15% off — expires in 14 days.

What Comes Next

Two more papers are in the review process at Preprints.org. Once they
are accepted, I will publish a second research post with all four papers
and their findings together.

In the meantime, the platform is live and the SDK is available:
npm install devfortress-sdk

Patent Pending KIPI KE/P/2026/005970–005973 · devfortress.net

Patent Pending KIPI KE/P/2026/005970–005973
npm install devfortress-sdk | devfortress.net

DevFortress Open Core is Live — Free Credential Isolation for Node.js

duncan n. ndegwa — Tue, 02 Jun 2026 15:26:33 +0000

Last week we launched the DevFortress platform.

The most consistent response from developers: "I want to use this, but I cannot
justify a subscription right now."

That is a fair response. Today we publish the open-core edition.

What is free, permanently

Tier 1 local rule engine
SQLi, XSS, path traversal, rate limiting. Evaluation happens in under 1 millisecond.
Zero network calls. Your application does not need internet access for this to work.

Credential isolation
Real session tokens never leave your application boundary. If you connect to the
DevFortress platform, it receives only non-derivable aliases — never your real tokens.
Even a complete platform breach yields no usable credentials.

Agent scope enforcement
Define which tools your AI agents are permitted to call. Unsanctioned tool calls
are blocked before execution. This is the structural answer to prompt injection —
the injection string alone does not cause the damage; the unsanctioned tool
execution does.

Local ML inference (embedded, optional)
In-process threat scoring using an ONNX model. No network call required.
Bring your own model or rely on the built-in heuristic fallback.

Local audit trail
Every security decision is logged: timestamp, source, decision, score. JSON export.
Compliance-ready without sending data to any external service.

What is commercial

Cross-customer threat intelligence (B1), platform ML inference — cloud-scored
cross-customer model (B2), predictive attack trajectory (B12), cloud webhook
delivery, automated response, dashboard.

The dividing line: local security is free. Platform intelligence is commercial.

The license

BUSL-1.1. In plain language:

You can use it in your own applications, free.
You can read the source code and verify exactly what data it touches.
You cannot build a competing API security SaaS using our code.
Four years after each release, the code converts to Apache 2.0.

Security tools should be transparent about what they do.
That is why we publish the source.

Install

npm install devfortress-sdk@4.9.0

GitHub: github.com/duncan982/devfortress
Docs: devfortress.net/docs

Core credential isolation and threat response inventions are patent-pending.
KIPI KE/P/2026/005970–005973.

We built credential isolation and automated closed-loop response into an API security SDK — here is why and how

duncan n. ndegwa — Fri, 22 May 2026 16:59:31 +0000

Security monitoring tools store your real session tokens.

Every JWT. Every credential. For every user, across every application they protect — sitting in a third-party database. If that vendor is breached, every application they monitor is compromised. This is not a theoretical risk. It is the architecture of almost every API security platform on the market today.

We spent 18 months building a different approach. DevFortress launches today.

The Core Problem: Credential Accumulation

When you integrate a traditional API security monitor, your SDK sends real session tokens to the monitoring platform for analysis. The platform logs them, correlates them, runs ML models on them. The platform needs the real token to do its job.

This means the security tool designed to protect you is also the largest single point of credential exposure in your infrastructure.

The Fix: Credential Isolation

When the DevFortress SDK intercepts a session token, it generates a completely random alias — no mathematical relationship to the real token — and sends only that alias to the platform. The real token never leaves your application boundary.

If DevFortress is breached tomorrow: attackers get a database of random strings that authenticate nothing, anywhere.

The Second Problem: Alert Fatigue

Traditional security tools detect a threat and send you an alert. The attacker's session stays active while you wake up, read the alert, triage it, and decide what to do. Average human response time: hours. Time an attacker needs to exfiltrate data: seconds.

DevFortress closes the loop automatically. When a threat is detected, the platform fires a signed HMAC-SHA256 webhook to your application. Your application revokes the session, blocks the IP, and confirms back to the platform. The entire cycle completes in under 2 seconds. No human in the loop.

AI Agent Security

AI agents introduced a new attack surface. A LangChain or AutoGen agent running in production holds real API keys with broad scope. One successful prompt injection and an attacker has those credentials.

DevFortress for agents:

AgentScopeEnforcer — define a tool allowlist per agent; block any unsanctioned tool call before execution
Token aliasing for agents — master API keys never exposed; the agent operates on scoped aliases
Auto-quarantine — compromised agent is isolated with full tool-call sequence preserved as evidence

What We Validated

133/133 attack events blocked
26 distinct attack scenarios
7 reference applications
100% SDK pass rate
Sub-millisecond internal blocking (<1ms)
4 patent filings, 34 inventions
Patent Pending — KIPI KE/P/2026/005970–005973

Three Ways to Start

Install the SDK (free):

npm install devfortress-sdk@4.8.0

Read the full architecture writeup:
https://www.devfortress.net/blog/devfortress-launch

Get the Master Edition textbook (full architecture deep-dive + interactive demos):
https://devfortress.gumroad.com/l/master-edition

Subscribe to the weekly security journal:
https://devfortress.substack.com

Happy to go deep on any of the inventions in the comments — especially the credential isolation mechanism, the closed-loop webhook architecture, or the AI agent scope enforcement.