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

> Explore the CyberStrikeAI architecture a modular Go service. Understand its central App object coordinating SQLite persistence Gin APIs MCP server and Agent engine for LLM interactions.

- Repository: [公明/CyberStrikeAI](https://github.com/Ed1s0nZ/CyberStrikeAI)
- Tags: architecture
- Published: 2026-03-09

---

**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`](https://github.com/Ed1s0nZ/CyberStrikeAI/blob/main/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`](https://github.com/Ed1s0nZ/CyberStrikeAI/blob/main/cmd/server/main.go), which loads [`config.yaml`](https://github.com/Ed1s0nZ/CyberStrikeAI/blob/main/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`](https://github.com/Ed1s0nZ/CyberStrikeAI/blob/main/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`](https://github.com/Ed1s0nZ/CyberStrikeAI/blob/main/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`](https://github.com/Ed1s0nZ/CyberStrikeAI/blob/main/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`](https://github.com/Ed1s0nZ/CyberStrikeAI/blob/main/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`](https://github.com/Ed1s0nZ/CyberStrikeAI/blob/main/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`](https://github.com/Ed1s0nZ/CyberStrikeAI/blob/main/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`](https://github.com/Ed1s0nZ/CyberStrikeAI/blob/main/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`](https://github.com/Ed1s0nZ/CyberStrikeAI/blob/main/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`](https://github.com/Ed1s0nZ/CyberStrikeAI/blob/main/cmd/server/main.go), which orchestrates the startup sequence:

```go
// 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`](https://github.com/Ed1s0nZ/CyberStrikeAI/blob/main/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`](https://github.com/Ed1s0nZ/CyberStrikeAI/blob/main/internal/mcp/server.go)), Agent loop ([`internal/agent/agent.go`](https://github.com/Ed1s0nZ/CyberStrikeAI/blob/main/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`](https://github.com/Ed1s0nZ/CyberStrikeAI/blob/main/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`](https://github.com/Ed1s0nZ/CyberStrikeAI/blob/main/internal/mcp/server.go). When the Agent in [`internal/agent/agent.go`](https://github.com/Ed1s0nZ/CyberStrikeAI/blob/main/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`](https://github.com/Ed1s0nZ/CyberStrikeAI/blob/main/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`](https://github.com/Ed1s0nZ/CyberStrikeAI/blob/main/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`](https://github.com/Ed1s0nZ/CyberStrikeAI/blob/main/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.