Knowledge Base

The Knowledge Base persists engagement state -- findings, attack results, lessons learned, and agent performance metrics. It is a structured query layer that supports single-user local operation and multi-user team deployments.

Dual Backend Architecture

              Agent / Pipeline
                    |
            Knowledge Base Interface
                    |
        +-----------+-----------+
        |                       |
   SQLite (local)        PostgreSQL (team)
   single-user            multi-user
   zero config            shared state

SQLite Mode

Local file-based storage. Zero configuration. Used for single-operator engagements where all state lives on the operator's machine. The database file is stored in the engagement output directory.

PostgreSQL Mode

Team server storage. Multiple operators share engagement state, findings, and handoffs. Required for collaborative engagements where findings flow between operators.

Dual Mode

Both backends active simultaneously. SQLite serves as a local cache for read-heavy operations (finding lookups during active scanning). PostgreSQL is the source of truth. Writes go to PostgreSQL first and propagate to SQLite asynchronously.

What Is Stored

Table	Contents
engagements	Scope, targets, operators, timeline
findings	1,044+ stored findings with CVSS, PoC status, remediation
attack_results	Tool outputs, payloads used, responses received
attack_lessons	Technique effectiveness, WAF bypasses, payload patterns
engagement_handoffs	State transfer between operators in team mode
executor_performance	Agent success rates, tool preferences, timing data

Configuration

Variable	Values	Purpose
KB_CONFIG_TYPE	sqlite, postgres, dual	Backend selection
PG_CONNECTION_STRING	PostgreSQL URI	Team server connection
KB_SQLITE_PATH	File path	Local database location

Pipeline Integration

The Pipeline reads engagement state from the Knowledge Base at session startup. It loads existing findings so new sessions continue where previous sessions left off. As tools produce results, findings are written back to the Knowledge Base and become available to parallel agents and follow-on sessions.

The interface is read-heavy during scanning (frequent finding lookups to avoid duplicate work) and write-heavy during result processing (bulk inserts after tool completion).