Designing an AI-Powered, Zero-Impact Checker Attack‑Defense System for AliExpress

1. Background & Challenges

global‑ump‑checker is the core data‑validation component of AliExpress’s marketing system, guarding over 700 error‑code checks that ensure coupon eligibility, activity qualification, and other business rules. Manual verification of these rules is costly (30 minutes to several hours per rule), hard to exhaustively enumerate attack surfaces, risky due to shared pre‑release/production databases, and impossible to scale for the N² growth of test cases during large promotions.

2. Core Concept of Checker Defence

The solution introduces an AI‑driven Checker defence script generator that combines a multi‑stage AI analysis pipeline with an MQ‑driven step engine and the Saiga Mock platform’s sub‑call mocking capability, enabling end‑to‑end, zero‑impact generation of defence scripts from a single error code.

3. Overall Design

3.1. Where AI Adds Value

Complexity handling : AI agents parse Java call chains, enumerate trigger scenarios, and trace data fields.

Execution orchestration : A step engine driven by MQ messages manages state, retries, and asynchronous AI callbacks.

3.2. Platform Architecture

The system is organized into five layers:

User layer : HTTP controller AiDefenceGeneratorCheckerController, task interface CheckerDefenceGenerateProcessor, and query interface AiDefenceCheckerEveryService.

Service layer : CheckerDefenceTaskService (task management), CheckerDefenceScriptGenerateService (AI session handling), SaigaTrafficServiceImp and SaigaMockTestServiceImp (integration with Saiga).

Core engine layer : Eight Phase sub‑engines (Phase 1‑8) form the analysis pipeline, coordinated by a total engine.

Data layer : DefenceGenerateTaskCheckerDO stores task records; AutoScriptInfoCheckerDO stores generated scripts.

External dependencies : Aone Agent LLM (Qwen3.5 Plus) for AI analysis, Saiga traffic and mock platforms, and Checker Fresh for HSF services.

3.3. Core Design Principles

Task decomposition : Each AI call solves a single focused problem; outputs feed the next step.

Trigger‑scenario granularity : The minimal unit is a trigger scenario rather than a location, ensuring precise field‑level analysis.

Step‑engine orchestration : Pluggable sub‑engines are invoked via MQ, keeping high cohesion and low coupling.

Saiga sub‑call mock : Instead of modifying production data, Saiga intercepts DB queries, HSF calls, etc., and returns AI‑crafted anomalous data, achieving truly non‑destructive testing.

4. Detailed Design

4.1. AI Analysis Pipeline (8 Steps)

Step 1 – Error‑code usage analysis : AI searches the codebase (e.g., errors_en_AA.properties) for all occurrences of the target error code, extracting file, method, line, and condition expressions.

Step 2 – Trigger‑condition enumeration : For each location, AI drills down into the condition expression, enumerating every possible trigger scenario that can activate the error.

Step 3 – Data source tracing & test‑case design : AI identifies the ultimate data source of each field (DB, HTTP, HSF, Diamond, Switch) and classifies the attack type into A (pure DB), B (mixed DB + service), or C (pure service) mock categories.

Step 4 – Traffic‑query parameter generation : Using the data‑source map, AI builds a TrafficQueryRequest (populating nBizKvs such as buyerId, activityId, topic, tag) to retrieve real traffic records.

Step 5 – Traffic query execution : Synchronous step that calls the Saiga traffic API with the parameters from Step 4 and stores matching records.

Step 6 – Mock‑plan generation : AI combines the data‑source trace and real traffic to produce a Saiga Mock configuration, specifying which sub‑calls to intercept and how to mutate their responses.

Step 7 – Mock‑rule creation : Synchronous step that invokes Saiga Mock’s API to create the actual mock rule, persisting the rule ID.

Step 8 – Defence‑script generation : Final synchronous step assembles all prior outputs into a standardized, executable defence script and stores it for automated scheduling.

4.2. Non‑Destructive Defence via Saiga Mock

Traditional defence altered database rows to trigger validation, exposing data‑corruption risk, limited coverage of external‑service‑dependent checks, and rollback difficulties. Saiga Mock instead intercepts sub‑calls at runtime and returns crafted anomalous data, eliminating any modification of production code or databases while covering DB, HSF, and HTTP‑based checks.

4.3. MQ‑Driven Step Engine

The total engine follows a uniform pattern: create or locate a StepRecord, invoke the corresponding sub‑engine, update the record based on StepCallbackResult, and persist. Sub‑engines are auto‑registered via Spring ( @Autowired List<ICheckerDefenceGenStepEngine>) and mapped by CheckerTaskStepEnum. Asynchronous AI steps submit an Aone Agent session, receive callbacks through MQ, and trigger the next step; synchronous steps execute directly and return success immediately. This design provides decoupled state management, easy extensibility, observability, and reliable retry.

4.4. Sub‑Engine Implementations

public interface ICheckerDefenceGenStepEngine {
    // Retrieve the step enum this engine implements
    CheckerTaskStepEnum getStep();
    // Execute business logic, create Aone Agent session if needed
    AoneAgentSessionResponse executeTask(DefenceGenerateTaskCheckerDO taskRecord);
    // Process AI callback, return step result (success/failure/ignore)
    StepCallbackResult handleCallback(DefenceGenerateTaskCheckerDO taskRecord,
                                      String sessionId, String aoneAgentStatus, String timestamp);
}

Each concrete engine (e.g., ErrorCodeUsageAnalysisEngine, TriggerConditionSceneEnumEngine, DataSourceAndTestCaseDesignEngine, etc.) implements the interface, handling either AI‑driven or synchronous logic as described in the pipeline.

4.5. Key Design Decisions

Combining data‑source tracing and test‑case design into a single AI call reduces token consumption and preserves context.

Centralised StepRecord management isolates state handling from business logic, improving traceability and simplifying step addition.

MQ‑asynchronous execution accommodates unpredictable AI latency, prevents thread blocking, enables persistence‑based recovery, and supports fine‑grained retries.

5. Platform Impact

By integrating AI analysis with MQ orchestration and Saiga Mock, the system achieves:

Zero data risk : No production data is ever modified.

Full‑scenario coverage : All trigger paths, including pure external‑service cases, are exercised.

Minute‑level turnaround : Manual 30‑minute‑plus analyses are compressed to minutes.

Higher precision : Field‑level data tracing yields accurate mock configurations.

Scalable extensibility : New analysis steps are added by implementing the engine interface without touching the core engine.