Agent Construction - Planning Session

Date: 2024-12-02 Project: CyberOrigen

Goal

Build and deploy vendor-independent, trainable AI agents for the CyberOrigen security platform.

Current Architecture Analysis

Existing Agents (8 total)

Located in /backend/agents/:

discovery_agent.py - Asset discovery, subdomain enumeration
enumeration_agent.py - Service enumeration
exploit_check_agent.py - Exploit checking
prioritization_agent.py - Vulnerability prioritization
remediation_agent.py - Remediation suggestions
reporting_agent.py - Report generation
threat_intel_agent.py - Threat intelligence
vuln_scan_agent.py - Vulnerability scanning

MCP Tool Servers (14 integrations)

Located in /backend/mcp_servers/:

Scanning: Nmap, Nuclei, SQLMap, Semgrep, WPScan, TestSSL
Discovery: Subfinder, Katana, HTTPX
Automation: Ansible
Integrations: DefectDojo, MISP, Wazuh, Reporting

Current AI Service

Located in /backend/services/ai_service.py:

Multi-provider support: Gemini, Claude, OpenAI
Persona system: default, red_teamer, auditor, soc_analyst
Features: Chat, reporting, compliance analysis

Base Agent Pattern

python

class BaseAgent:
    def __init__(self, scan_id: str, target: str, config: Dict[str, Any] = None):
        self.scan_id = scan_id
        self.target = target
        self.config = config or {}
        self.results: List[Dict] = []
        self.errors: List[str] = []

    def execute(self) -> Dict[str, Any]:
        raise NotImplementedError("Subclasses must implement execute()")

    def add_result(self, result: Dict):
        self.results.append(result)

    def success_response(self, message: str) -> Dict[str, Any]:
        return {'success': True, 'message': message, 'results': self.results, 'errors': self.errors}

    def failure_response(self, error: str) -> Dict[str, Any]:
        return {'success': False, 'error': error, 'results': self.results, 'errors': self.errors}

Requirements

Vendor Independence - No lock-in to OpenAI, Google, or Anthropic
Trainable - Ability to fine-tune models on security domain data
Self-Hosted - Run on local infrastructure

Recommended Stack

1. Open-Source LLM Options

Model	Size	Strengths
Qwen 2.5	7B-72B	Excellent tool-use, reasoning, multilingual
Llama 3.1/3.2	8B-70B	Strong overall, great community
Mistral/Mixtral	7B/8x7B	Fast, efficient MoE architecture
DeepSeek-V2.5	Various	Strong coding/reasoning

2. Inference Options

Ollama - Easy local deployment, great for development
vLLM - Production-grade, high throughput
llama.cpp - CPU/GPU efficient inference

3. Agent Framework (LLM-Agnostic)

LangGraph - State machines for complex workflows
CrewAI - Multi-agent orchestration
smolagents (Hugging Face) - Lightweight, tool-use focused

4. Fine-Tuning/Training

Unsloth - 2-5x faster LoRA/QLoRA training
Axolotl - Flexible fine-tuning configs
Dataset: Security scan data, vulnerability reports

Memory Requirements

By Model Size (Ollama)

Model	Quantization	RAM Required	VRAM (GPU)	Notes
7B (Qwen2.5, Llama3.1)	Q4_K_M	~4-5 GB	~5 GB	Great for agents, fast
7B	Q8_0	~8 GB	~9 GB	Better quality
13B	Q4_K_M	~8-9 GB	~9 GB	Good balance
32B (Qwen2.5)	Q4_K_M	~20 GB	~22 GB	Excellent reasoning
70B (Llama3.1, Qwen2.5)	Q4_K_M	~40-45 GB	~45 GB	Near-frontier quality
70B	Q5_K_M	~50-55 GB	~55 GB	Higher quality

Target Hardware

Minisforum AI X1 Pro:

96GB RAM
AMD Ryzen AI 9

Capabilities:

70B Q4/Q5 models (~45-55GB)
32B models with room to spare
Multiple smaller models simultaneously
Fine-tune 7B-13B models with LoRA

Recommended Starting Point

Option A: Balanced (Recommended)

Qwen2.5:32B-Instruct (Q4_K_M)

~20GB RAM
Excellent tool-use and reasoning
Fast enough for interactive agents
Leaves headroom for backend services

Option B: Maximum Capability

Qwen2.5:72B-Instruct (Q4_K_M)

~45GB RAM
Near-Claude/GPT-4 quality
Great for complex security analysis

Implementation Plan

Phase 1: Infrastructure Setup

[ ] Install Ollama
[ ] Download and test base model (Qwen2.5:32B recommended)
[ ] Create OpenAI-compatible API wrapper for existing ai_service.py

Phase 2: Agent Framework Integration

[ ] Design LLM-agnostic agent base class
[ ] Integrate with existing MCP servers as tools
[ ] Create tool-use prompt templates for security domain

Phase 3: Custom Agent Development

[ ] Build new specialized agents using local LLM
[ ] Implement multi-agent orchestration
[ ] Add agent memory/state management

Phase 4: Fine-Tuning Pipeline

[ ] Collect training data from scans and reports
[ ] Set up Unsloth/Axolotl for LoRA training
[ ] Create security-domain fine-tuned model
[ ] Evaluate and iterate

Daniel Miessler's Personal AI Infrastructure (PAI) Analysis

Source: danielmiessler.com/blog/personal-ai-infrastructure

Core Philosophy

"The system, the orchestration, and the scaffolding are far more important than the model's intelligence."

A well-designed system with an average model outperforms a brilliant model with poor architecture.

Key Architecture Components

1. Text-Based Orchestration

Markdown and file-system-based configurations
"Mastering text manipulation approximates mastering thought itself"
Everything is text files that can be versioned, shared, and composed

2. Universal File-based Context (UFC)

Structure: ~/.claude/context/

context/
├── architecture/      # Architecture patterns
├── projects/          # Project-specific configs
├── methodologies/     # Workflows
├── troubleshooting/   # Guides
└── memory/            # Persistent memory

3. Four-Layer Context Enforcement

Master context documentation
UserPromptSubmit hooks (intercept every prompt)
Aggressive CLAUDE.md instructions with explicit compliance
Redundant symlinks ensuring discoverability

4. Specialized Agents

Multiple agents: engineer, pentester, designer, marketer
Shared context files (no duplication)
Each maintains domain expertise

5. MCP Servers

Tools exposed via Model Context Protocol:

httpx - Web stack detection
naabu - Port scanning
Content archival
Life logging integration

6. Modular Tools (UNIX Philosophy)

Solve each problem once, reuse perpetually
Composable, chainable functionality
Fabric patterns for consistent outputs

Critical Success Factors

Factor	Why It Matters
Tool Descriptions	Determines how agents route requests - must be detailed and precise
Central Documentation	Single `tools/CLAUDE.md` eliminates scattered docs
Mandatory Context Loading	Force actual file reads before proceeding
System Over Features	Evaluate capabilities by contribution to infrastructure, not isolation

Mapping to CyberOrigen Architecture

Miessler's PAI	CyberOrigen Equivalent
MCP Servers (httpx, naabu)	MCP servers (nmap, nuclei, subfinder)
Specialized Agents	Security agents (discovery, vuln_scan, etc.)
UFC Context System	Gap: Add `context/` for scan policies, compliance rules
Four-Layer Enforcement	CLAUDE.md + config.py + persona prompts
Fabric Patterns	Report templates, AI prompts

Key Insight

CyberOrigen's infrastructure is already aligned with Miessler's philosophy. The gap is the orchestration layer - a unified system that coordinates agents with shared context and memory.

Recommended Additions for CyberOrigen

Context Directory Structure

backend/context/
├── scan_policies/        # Default scan configurations
├── compliance/           # SOC2, PCI-DSS, HIPAA rules
├── threat_intel/         # Known threat patterns
├── remediation/          # Fix templates by vuln type
└── memory/               # Scan history, learned patterns

Orchestration Layer
- Central coordinator that routes tasks to appropriate agents
- Shared state between agents during scan lifecycle
- Context injection based on target type and scan phase
Tool Description Enhancement
- Detailed MCP server descriptions for accurate routing
- Input/output schemas for each tool
- Example usage patterns

Implementation Log

2024-12-02: SearchSploit Integration

Status: ✅ Completed

Files Created/Modified:

/backend/mcp_servers/searchsploit_server.py (NEW)
- Full MCP server implementation for SearchSploit
- Searches offline Exploit-DB archive
- Features: CVE search, keyword search, exploit type filtering
- Includes simulation mode for testing without installation
/backend/mcp_servers/__init__.py (MODIFIED)
- Added SearchSploitServer to exports
- Added to MCPToolExecutor servers
/backend/agents/exploit_check_agent.py (MODIFIED)
- Integrated SearchSploit MCP server
- Replaces simulated ExploitDB check with real search
- Fallback to known exploits list if SearchSploit unavailable
/docker/Dockerfile.worker (MODIFIED)
- Added SearchSploit/ExploitDB installation
- Clones exploit-database from GitLab

Usage Example:

python

from mcp_servers import search_cve, check_exploit_exists

# Search by CVE
result = await search_cve('CVE-2021-44228')
print(f"Exploits found: {result.output['total_exploits']}")

# Check software for exploits
info = await check_exploit_exists('apache', '2.4.49')
print(f"Risk increase: {info['risk_increase']}")

DefectDojo Status

Status: ✅ Already Implemented

MCP server at /backend/mcp_servers/defectdojo_server.py
Connects via API (no Docker container needed)
Supports: get_findings, import_scan, create_finding, get_statistics

2024-12-02: Trivy Integration

Status: ✅ Completed

Purpose: Container image, SBOM, and dependency vulnerability scanning - a capability not covered by existing tools.

Files Created/Modified:

/backend/mcp_servers/trivy_server.py (NEW)
- Full MCP server implementation for Trivy
- Supports scan types: image, fs, repo, sbom, config
- Scanners: vulnerabilities, secrets, misconfigurations, licenses
- SBOM generation in CycloneDX/SPDX formats
- Severity filtering and ignore unfixed options
/backend/mcp_servers/__init__.py (MODIFIED)
- Added TrivyServer, TrivyOptions exports
- Added convenience functions: scan_image, scan_filesystem, scan_repository, generate_sbom, scan_sbom, scan_iac, quick_image_scan
- Added to MCPToolExecutor servers
/backend/agents/vuln_scan_agent.py (MODIFIED)
- Added _run_trivy_scan() method for container/SBOM/dependency scanning
- Added _convert_trivy_findings() to normalize Trivy output
- Integrated as 5th scan type in VULN_SCAN phase
- Supports config options:
  - container_images: List of Docker images to scan
  - source_code_path: Filesystem path for dependency scanning
  - sbom_path: Path to existing SBOM file
/docker/Dockerfile.worker (MODIFIED)
- Added Trivy installation via official APT repository
- GPG key and repository setup for secure installation

Usage Example:

python

from mcp_servers import scan_image, scan_filesystem, generate_sbom

# Scan a container image
result = await scan_image('nginx:latest')
print(f"Vulnerabilities: {result.output['total_vulnerabilities']}")
print(f"Critical: {result.output['severity_breakdown']['CRITICAL']}")

# Scan project dependencies
result = await scan_filesystem('/app/project')
for vuln in result.output['vulnerabilities']:
    print(f"{vuln['package']}: {vuln['id']} ({vuln['severity']})")

# Generate SBOM
result = await generate_sbom('/app/project', sbom_format='cyclonedx')
print(f"Components: {len(result.output['components'])}")

Scan Configuration:

python

# In vuln_scan_agent config:
config = {
    'container_images': ['myapp:v1.0', 'redis:7'],  # Images to scan
    'source_code_path': '/app/source',               # Dependency scanning
    'sbom_path': '/app/sbom.json',                   # Existing SBOM
}

What Trivy Adds (Not Covered by Other Tools):

Capability	Description
Container CVEs	OS package vulnerabilities in Docker images
Dependency Scanning	npm, pip, go.mod, Gemfile, etc.
SBOM Generation	CycloneDX/SPDX compliance
SBOM Vulnerability Scan	Scan existing SBOMs
Secret Detection	API keys, passwords in code/containers
IaC Misconfigs	Terraform, Kubernetes, Dockerfile

Tool Implementation Status

#	Tool	Phase	Status	Notes
1	Subfinder	DISCOVERY	✅ Implemented	Subdomain enumeration
2	Nmap	DISCOVERY/ENUM	✅ Implemented	Port scanning
3	HTTPX	ENUMERATION	✅ Implemented	HTTP probing
4	Katana	ENUMERATION	✅ Implemented	Web crawling
5	Nuclei	VULN_SCAN	✅ Implemented	Vulnerability scanning
6	SQLMap	VULN_SCAN	✅ Implemented	SQL injection
7	TestSSL	VULN_SCAN	✅ Implemented	TLS/SSL testing
8	Semgrep	VULN_SCAN	✅ Implemented	SAST code analysis
9	WPScan	VULN_SCAN	✅ Implemented	WordPress scanning
10	Trivy	VULN_SCAN	✅ Implemented	Container/SBOM/dependency scanning
11	MISP	THREAT_INTEL	✅ Implemented	Threat intelligence
12	Wazuh	THREAT_INTEL	✅ Implemented	SIEM integration
13	SearchSploit	EXPLOIT_CHECK	✅ Implemented	Exploit database search
14	DefectDojo	PRIORITIZATION	✅ Implemented	Vuln management
15	Ansible	REMEDIATION	✅ Implemented	Automated remediation
16	Reporting	REPORTING	✅ Implemented	Report generation

Total: 16 tools implemented

Next Steps

Install Ollama + download capable model
Create agent framework integrated with existing MCP servers
Set up fine-tuning pipeline for security domain training
NEW: Implement UFC-style context directory for CyberOrigen
NEW: Build orchestration layer following PAI principles

Agent Construction - Planning Session ​

Goal ​

Current Architecture Analysis ​

Existing Agents (8 total) ​

MCP Tool Servers (14 integrations) ​

Current AI Service ​

Base Agent Pattern ​

Requirements ​

Recommended Stack ​

1. Open-Source LLM Options ​

2. Inference Options ​

3. Agent Framework (LLM-Agnostic) ​

4. Fine-Tuning/Training ​

Memory Requirements ​

By Model Size (Ollama) ​

Target Hardware ​

Recommended Starting Point ​

Option A: Balanced (Recommended) ​

Option B: Maximum Capability ​

Implementation Plan ​

Phase 1: Infrastructure Setup ​

Phase 2: Agent Framework Integration ​

Phase 3: Custom Agent Development ​

Phase 4: Fine-Tuning Pipeline ​

Daniel Miessler's Personal AI Infrastructure (PAI) Analysis ​

Core Philosophy ​

Key Architecture Components ​

1. Text-Based Orchestration ​

2. Universal File-based Context (UFC) ​

3. Four-Layer Context Enforcement ​

4. Specialized Agents ​

5. MCP Servers ​

6. Modular Tools (UNIX Philosophy) ​

Critical Success Factors ​

Mapping to CyberOrigen Architecture ​

Key Insight ​

Recommended Additions for CyberOrigen ​

Implementation Log ​

2024-12-02: SearchSploit Integration ​

Files Created/Modified: ​

Usage Example: ​

DefectDojo Status ​

2024-12-02: Trivy Integration ​

Files Created/Modified: ​

Usage Example: ​

Scan Configuration: ​

What Trivy Adds (Not Covered by Other Tools): ​

Tool Implementation Status ​

Next Steps ​

Agent Construction - Planning Session

Goal

Current Architecture Analysis

Existing Agents (8 total)

MCP Tool Servers (14 integrations)

Current AI Service

Base Agent Pattern

Requirements

Recommended Stack

1. Open-Source LLM Options

2. Inference Options

3. Agent Framework (LLM-Agnostic)

4. Fine-Tuning/Training

Memory Requirements

By Model Size (Ollama)

Target Hardware

Recommended Starting Point

Option A: Balanced (Recommended)

Option B: Maximum Capability

Implementation Plan

Phase 1: Infrastructure Setup

Phase 2: Agent Framework Integration

Phase 3: Custom Agent Development

Phase 4: Fine-Tuning Pipeline

Daniel Miessler's Personal AI Infrastructure (PAI) Analysis

Core Philosophy

Key Architecture Components

1. Text-Based Orchestration

2. Universal File-based Context (UFC)

3. Four-Layer Context Enforcement

4. Specialized Agents

5. MCP Servers

6. Modular Tools (UNIX Philosophy)

Critical Success Factors

Mapping to CyberOrigen Architecture

Key Insight

Recommended Additions for CyberOrigen

Implementation Log

2024-12-02: SearchSploit Integration

Files Created/Modified:

Usage Example:

DefectDojo Status

2024-12-02: Trivy Integration

Files Created/Modified:

Usage Example:

Scan Configuration:

What Trivy Adds (Not Covered by Other Tools):

Tool Implementation Status

Next Steps