REMN: Persistent State for AI Agents in Offensive Security
When offensive security research runs for several hours, resuming the work is not as simple as reopening the transcript. I need to know which access is still valid, which processes are still running, what changed on the target, and which conclusions have enough evidence behind them.
That was the problem I kept encountering in research sessions with Codex, Claude, and other models. The commands and outputs were still there, but the conversation could not tell me clearly what state the investigation was actually in.
REMN grew out of that loss of time. Its name comes from remnant and points to what an execution leaves behind. I do not mean only the history. I mean the state that may change the agent's next decision.
In my labs, preserving that state produced a visible reduction in repeated work. Some workflows that once stretched across hours began to finish much faster and, in some cases, in a matter of minutes. REMN does not discover a vulnerability by magic. It prevents the agent from wasting part of the session reconstructing work it has already completed.
All work described in this series was conducted in isolated, authorized environments.
When the transcript stops being enough
A transcript lets me review what happened, but it mixes observations, conclusions, and current state. To continue an investigation, I need to keep those three things separate.
An observation is something I can see in tool output or an artifact. An inference is a conclusion drawn from that evidence. It may be correct and useful, but it does not carry the same weight as a direct observation.
During an offensive assessment, confidence is built one step at a time.
An open port shows that something is listening.
A banner may identify the product.
The version may suggest a CVE.
I consider the capability demonstrated when I can reproduce the effect and recognize it through a concrete signal.
I apply the same standard to binary exploitation. A crash demonstrates a failure under specific conditions. Exploitation still requires control of the instruction pointer, a stable primitive, or some other verifiable impact.
This is why writing down that "the vector works" is not enough. The phrase does not explain which output supports the conclusion, under which conditions it was reproduced, or whether those conditions still hold.
REMN separates what happened from what can be concluded from it. Every normalized fact retains its source, confidence level, timestamps, and relevant attributes. Identity proofs are tied to a command digest, while recon events point back to their artifacts. This lets me review a conclusion without turning the agent's interpretation into original evidence.
I chose SQLite because I needed a local database that could stay with each investigation and reopen from another session. WAL, or write ahead logging, allows one process to keep reading while another writes. The hooks and the watcher also maintain independent cursors, so both can move through the same stream without consuming events from one another.
I did not change the model or the way it reasons. I changed the information it finds when a task begins or resumes.
Four states that change the next decision
During a penetration test, an AI agent receives observations, proposes hypotheses, acts on capabilities it considers demonstrated, and relies on a channel to exercise them. Those distinctions are often blurred in the conversation.
REMN represents them through four categories.
Observation. Data produced by a tool or extracted from an artifact.
Hypothesis. An interpretation that still requires validation.
Capability. A reproducible effect paired with a concrete signal.
Transport. The channel available to exercise a capability.
The distinction between capability and transport is especially important. A reverse shell may die without invalidating the vulnerability used to obtain it. The opposite can happen as well. A connection remains active, but a change to the target invalidates the original exploit conditions.
If I store both cases as "access obtained", I lose a distinction that affects the next decision. In one case I need to restore the channel. In the other, I need to verify whether the capability still exists.
The model can propose interpretations, but it cannot turn them into facts on its own. When a mechanical validator exists, code requires a concrete signal before accepting the transition. An HTTP response or a claim made by the model is not enough to record access.
How REMN works
The diagram separates responsibilities, not independent services. Most blocks live inside the same local runtime and share one SQLite database.
The agent sits at the top. It receives project instructions, skills, MCP tools, and hooks. A hook runs code at a specific moment, such as session startup or after a tool call. MCP stands for Model Context Protocol and lets the agent query or update state through operations with defined inputs and outputs.
The agent still decides what to investigate and what to execute. The review block represents a second pass performed manually or with another model. That review may challenge a conclusion, but it does not automatically become verified state.
At the center, REMN connects execution with two persistent views.
Event log. It records what happened and in which order.
Current state. It shows which facts remain active, which routes are still open, and which information is no longer valid.
Both views live in SQLite. One preserves the history while the other summarizes the current situation.
Watchers read recon events through their own cursor and deliver new information without running scans or attacks. MCP tools query or update state. The control layer records routes, attempts, and supervised processes to reduce repeated work.
Replay does not mean attacking the target again. It passes recorded inputs through the same parsers to check that they produce the same decisions. Automatic rollback of every target modification remains part of the design rather than a current guarantee.
The implementation already covers the following functions.
Persistence of events, facts, and selected artifacts.
Deterministic parsers and explicit registrations.
Typed tools for querying and updating state.
Supervision of processes and routes.
Invalidation of data after an instance change.
Replay of evidence extraction cases.
The main repository contains 195 tests covering invariants, parsers, and lifecycle behavior. In daily use, the value becomes visible when an investigation resumes. The agent receives a view of validated access, closed routes, current services, and registered processes without reconstructing everything from the transcript.
Technical references
Several projects helped me frame the problem. ReAct describes the reasoning and action loop used by tool driven agents. PentestGPT addresses context loss during penetration testing, while Lost in the Middle shows how information can remain in a long context without influencing the result.
The work on structured memory is also relevant. Hindsight separates facts, experiences, and beliefs. Eywa preserves source evidence before deriving facts. The broader idea of recording where information came from predates LLMs and is formalized in W3C PROV.
What comes next
REMN is still under development, and I continue to refine it as I use it in new investigations. I want to improve how it represents state, expand its invalidation rules, and make it easier to integrate with other workflows.
I will also share progress and practical examples on the blog without tying the series to a particular test or format. Later, I want to publish the repository so it can be used outside my environment. Before that, I need to separate a few internal dependencies and stabilize the interface.
For now, this article presents the idea that guides the project. An agent may execute tools quickly, but that advantage disappears if it has to reconstruct its own work every time a new session begins. REMN is my attempt to preserve that continuity.
