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
Top comments (0)