CyberStrikeAI Architecture: A Deep Dive into the Modular Go-Based AI Orchestrator

CyberStrikeAI is built as a modular Go service centered around a central App object that coordinates SQLite persistence, Gin-based HTTP APIs, an MCP server for tool execution, and an Agent engine for LLM interactions.

CyberStrikeAI (repository Ed1s0nZ/CyberStrikeAI) implements a layered, plugin-driven architecture designed for AI-powered cybersecurity operations. The system combines traditional web service patterns with modern LLM orchestration capabilities, making the CyberStrikeAI architecture both extensible and maintainable.

Core Architectural Pattern

The Central App Object

At the heart of the CyberStrikeAI architecture lies the App struct defined in internal/app/app.go. The app.New() function acts as a dependency injection container, instantiating and wiring together all subsystems:

• Database connections via database.NewDB()
• The MCP server via mcp.NewServer()
• Security components via security.NewAuthManager()
• The Agent engine via agent.NewAgent()
• Knowledge base components
• Skills management
• Robot integrations

This centralization ensures consistent lifecycle management and clean separation of concerns across the codebase.

Configuration and Structured Logging

The system initializes through cmd/server/main.go, which loads config.yaml via config.Load() and creates a structured zap.Logger via logger.NewLogger(). These components propagate through the dependency graph, enabling consistent observability across all layers.

HTTP API and Authentication Layer

Gin Router Setup

CyberStrikeAI exposes a RESTful API using the Gin framework. The setupRoutes function in internal/app/app.go (lines 30-52) registers handlers for:

• Authentication endpoints
• Agent control and conversation management
• Knowledge base operations
• Robot callbacks
• Skill management

Session-Based Security

The security.AuthManager in internal/security/auth_manager.go implements session-based authentication with password hashing. Middleware injected into Gin routes validates sessions before reaching business logic handlers, ensuring protected resources remain secure.

Data Persistence

SQLite Database Layer

All persistent data flows through database.NewDB() in internal/database/database.go. The system uses SQLite to store:

• Conversation histories
• Skill definitions and usage statistics
• Vulnerability records
• Optional separate knowledge database connections

This lightweight approach suits the self-contained deployment model while maintaining ACID compliance.

AI Orchestration Engine

MCP Server and Tool Registration

The Modular Command Protocol (MCP) server in internal/mcp/server.go functions as the execution backbone. It maintains a registry of tools that the LLM can invoke, with RegisterTool() accepting handler functions that implement business logic.

Built-in tools include vulnerability recorders, knowledge retrievers, and skill executors. The server handles request routing, argument validation, and result formatting.

Agent Execution Loop

The agent.Agent in internal/agent/agent.go drives the LLM interaction cycle. Its ExecuteLoop method:

1. Constructs prompts from conversation context
2. Sends requests to OpenAI via internal/openai/openai.go
3. Parses tool call responses
4. Invokes the MCP server to execute requested tools
5. Stores results and respects max_iterations limits

This loop enables autonomous cybersecurity analysis while maintaining human oversight through iteration caps.

Knowledge Base and RAG

Retrieval-Augmented Generation (RAG) capabilities reside in internal/knowledge/. The system uses:

• knowledge.Manager for document lifecycle management
• knowledge.Indexer to process and embed documents using OpenAI embeddings
• knowledge.Retriever for similarity search during agent execution

This architecture allows the agent to reference private documentation and vulnerability databases during analysis.

Extensibility Systems

Dynamic Skills Loading

The skills.Manager in internal/skills/manager.go implements a plugin system that dynamically loads YAML skill definitions from a configured directory. Each skill automatically registers as an MCP tool, with the manager tracking usage statistics and enabling hot-reloading of capabilities without binary restarts.

External MCP Client Support

CyberStrikeAI can proxy tool calls to remote MCP servers via mcp.ExternalMCPManager in internal/mcp/external_manager.go. This enables distributed AI workflows where the local agent orchestrates tools hosted on external infrastructure through gRPC or WebSocket connections.

Robot Integrations

Long-running WebSocket connections for enterprise messaging platforms are handled in internal/robot/. The robot.StartDing() and robot.StartLark() functions maintain persistent connections to DingTalk and Feishu/Lark, exposing /api/robot/* endpoints for bidirectional communication between chat platforms and the AI agent.

Entry Point and Boot Sequence

CLI Bootstrap

The application initializes through cmd/server/main.go, which orchestrates the startup sequence:

// cmd/server/main.go
cfg, err := config.Load("config.yaml")
if err != nil { log.Fatalf("load config: %v", err) }

lg, err := logger.NewLogger(cfg.Log)
if err != nil { log.Fatalf("init logger: %v", err) }

app, err := app.New(cfg, lg)
if err != nil { log.Fatalf("init app: %v", err) }

if err := app.Run(); err != nil {
    lg.Error("server stopped", zap.Error(err))
}

This pattern ensures explicit dependency injection and graceful error handling during subsystem initialization.

Summary

• Centralized Architecture: The App struct in internal/app/app.go serves as the dependency injection container, coordinating all subsystems through explicit constructor injection.
• Modular AI Stack: The system separates concerns between the MCP server (internal/mcp/server.go), Agent loop (internal/agent/agent.go), and Knowledge base (internal/knowledge/), enabling independent scaling and testing.
• Extensible Tooling: Dynamic skill loading via YAML and external MCP client support allow runtime extension without recompilation.
• Enterprise Integration: Native WebSocket support for DingTalk and Lark bridges the AI engine with enterprise messaging platforms.
• Lightweight Persistence: SQLite-based storage in internal/database/database.go provides ACID compliance without external database dependencies.

Frequently Asked Questions

What programming language is CyberStrikeAI built with?

CyberStrikeAI is implemented entirely in Go (Golang). The codebase leverages Go's strong typing, efficient concurrency model, and explicit error handling to build a reliable, modular service architecture suitable for cybersecurity automation tasks.

How does CyberStrikeAI handle LLM tool execution?

The system uses the Modular Command Protocol (MCP) implemented in internal/mcp/server.go. When the Agent in internal/agent/agent.go receives tool calls from the LLM, it routes them to the MCP server, which executes registered handlers, persists results via storage.FileResultStorage, and returns structured output to the agent loop.

Can CyberStrikeAI integrate with external AI services?

Yes. Through mcp.ExternalMCPManager in internal/mcp/external_manager.go, the platform can proxy tool calls to remote MCP servers via gRPC or WebSocket connections. Additionally, the internal/openai/openai.go wrapper can be replaced to support alternative LLM providers without modifying the core agent logic.

What database does CyberStrikeAI use for persistence?

CyberStrikeAI uses SQLite for all persistent storage, implemented in internal/database/database.go. This includes conversation histories, skill definitions, vulnerability records, and knowledge base metadata, providing a self-contained deployment model that requires no external database infrastructure.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}