Backend kiểm tra và chuẩn hóa method, path, parameter, request body schema và thông tin security trước khi lưu vào MongoDB.

Tài liệu OpenAPI được coi là dữ liệu không tin cậy. Nội dung mô tả trong OpenAPI không bao giờ được sử dụng như chỉ dẫn điều khiển agent.

2.2. Kiến trúc hệ thống đa agent

Mỗi agent đảm nhận một vai trò riêng:

• Planner Agent: phân tích API và xây dựng kế hoạch kiểm thử.
• Authentication Agent: đánh giá các luồng đăng nhập, token và session.
• Authorization Agent: kiểm tra quyền truy cập giữa người dùng, tài nguyên và vai trò.
• Input/Fuzzing Agent: tạo các trường hợp kiểm thử schema, tham số và dữ liệu đầu vào.
• Validator Agent: đối chiếu response với hành vi mong đợi và bằng chứng thực thi.
• Reporting Agent: tổng hợp các finding đã được xác minh.
• Supervisor: điều phối trạng thái, thứ tự thực thi và giới hạn campaign.

Các agent chỉ tạo test intent hoặc đề xuất hành động. Agent không có quyền tự gửi request tới target.

2.3. Policy Engine quyết định quyền thực thi

Trước mỗi request, Policy Engine kiểm tra bằng deterministic code:

• Target có thuộc phạm vi được cấp phép không.
• Host, path và HTTP method có nằm trong allowlist không.
• Campaign có đang hoạt động không.
• Request có vượt ngân sách hoặc rate limit không.
• Hành động có làm thay đổi trạng thái hay không.
• Approval có gắn đúng campaign, testcase, endpoint, method và payload không.
• Approval còn hiệu lực hay đã hết hạn.
• Destination sau khi phân giải có còn nằm trong phạm vi không.

Nếu bất kỳ điều kiện nào không rõ ràng, hệ thống fail closed: chặn request hoặc chuyển sang trạng thái cần con người xem xét.

2.4. HTTP Execution Gateway

HTTP Execution Gateway là thành phần duy nhất được phép kết nối tới target API.

Gateway chịu trách nhiệm:

• Kiểm tra lại destination ngay trước khi gửi request.
• Không tự động theo redirect ngoài phạm vi.
• Áp dụng giới hạn request và rate limit.
• Quản lý trạng thái campaign.
• Ghi nhận thời gian, method, URL và status code.
• Làm sạch request và response trước khi lưu.
• Chặn việc phát hành request mới khi campaign bị pause, stop hoặc vượt ngân sách.

Thiết kế này tách rõ năng lực suy luận của AI khỏi quyền tác động lên hệ thống bên ngoài.

2.5. Human-in-the-loop

Các hành động có rủi ro phải được người có thẩm quyền phê duyệt.

Hai vai trò chính:

• Operator: tạo project, nhập API, cấu hình campaign và theo dõi quá trình chạy.
• Approver: xem xét và phê duyệt các testcase hoặc hành động bị giới hạn.

Approval được gắn với nội dung cụ thể, không phải một quyền chung chung cho toàn bộ campaign. Nếu testcase, endpoint, method hoặc payload thay đổi, hệ thống phải yêu cầu phê duyệt lại.

2.6. Evidence-grounded findings

Mỗi request tạo một receipt chứa dữ liệu đã được làm sạch, gồm:

• Campaign và testcase liên quan.
• Method, path và URL.
• Request headers đã sanitize.
• Response status và headers đã sanitize.
• Response body an toàn để hiển thị.
• Thời gian thực thi.
• Danh tính hoặc vai trò kiểm thử.
• Kết quả validation.

Các giá trị như Authorization, cookie, API key, token, secret và dữ liệu cá nhân không được hiển thị trực tiếp.

Kết quả do LLM đưa ra chỉ được xem là candidate. Một finding chỉ được xác nhận khi có:

1. Receipt của request thực tế.
2. Bằng chứng đã được sanitize.
3. Hành vi mong đợi và hành vi thực tế.
4. Kết quả xác minh độc lập bằng deterministic logic.

Điều này giúp giảm false positive và tạo báo cáo có thể truy vết, kiểm tra và tái hiện.

2.7. Công nghệ sử dụng

• Frontend: Vue 3 và Vite.
• Backend: Node.js, Express và Mongoose.
• AI Runtime: Python 3.11 và FastAPI.
• Điều phối agent: LangGraph/LangChain trong kiến trúc agent runtime.
• Cơ sở dữ liệu: MongoDB.
• Triển khai local: Docker Compose.
• Kiểm thử: pytest, HTTPX và test framework của Node/Vue.

Kiến trúc MVP được tổ chức theo hướng modular monolith. Các thành phần được tách theo trách nhiệm nhưng chưa tách mỗi agent thành một microservice độc lập, giúp giảm độ phức tạp triển khai trong giai đoạn đầu.

3. Tính khả thi

Vertical slice đã hoạt động

MVP đã chứng minh được luồng chính:

1. Người dùng đăng ký hoặc đăng nhập.
2. Tạo project và khai báo target staging.
3. Import OpenAPI hoặc nhập endpoint thủ công.
4. Chọn operation và tạo campaign.
5. AI xây dựng draft test plan.
6. Operator xem lại kế hoạch.
7. Hệ thống chạy testcase qua Execution Gateway.
8. Frontend theo dõi trạng thái và sự kiện của run.
9. Request/response được lưu dưới dạng evidence đã sanitize.
10. Hệ thống phân loại kết quả và hiển thị finding có liên kết bằng chứng.

Dữ liệu project, campaign và run được lưu trong MongoDB, vì vậy lịch sử vẫn có thể được xem lại sau khi tải lại giao diện.

Các cơ chế an toàn đã được thiết kế thành ranh giới hệ thống

MVP ưu tiên các cơ chế có thể kiểm chứng bằng code:

• Chỉ Gateway được kết nối target.
• Target phải được khai báo và xác nhận có quyền kiểm thử.
• FE chỉ gọi backend; không gọi trực tiếp AI hoặc target.
• AI output được validate trước khi sử dụng.
• Request ngoài scope bị chặn trước network call.
• Hành động state-changing cần điều kiện phê duyệt.
• Không truyền password hoặc token vào prompt AI.
• Evidence được sanitize trước khi lưu và hiển thị.
• LLM không thể tự xác nhận finding.
• Có deterministic fallback khi LLM không khả dụng.

Có khả năng chạy không phụ thuộc hoàn toàn vào LLM

Planner có chế độ deterministic fallback. Khi thiếu API key, provider bị lỗi hoặc output không đúng schema, hệ thống vẫn có thể:

• Duy trì campaign đã tạo.
• Sinh kế hoạch cơ bản bằng rule.
• Không lưu output không hợp lệ.
• Không tự động thực thi một hành động không rõ ràng.

Điều này giúp MVP ổn định hơn khi demo và phù hợp với nguyên tắc fail closed.

Có kiểm thử tự động

Các lớp quan trọng được kiểm thử riêng, bao gồm:

• Parser và converter OpenAPI.
• Validation target URL.
• Scope và method allowlist.
• Approval binding.
• Request budget và rate limit.
• Redirect handling.
• Secret và PII masking.
• Agent state transition.
• Evidence grounding.
• API ownership và access control.
• Frontend campaign, review và run-monitor flows.

Bộ hồ sơ Demo Day sử dụng một snapshot kiểm thử gồm 370 AI tests, 59 backend tests và 31 frontend tests, cùng kiểm tra build và launcher. Các con số này nên được chạy lại và cập nhật ngay trước thời điểm nộp bản cuối.

Giới hạn hiện tại

MVP chưa được trình bày như một nền tảng pentest tự trị hoặc sản phẩm production-ready.

Một số giới hạn còn tồn tại:

• Chỉ sử dụng mock server hoặc staging target được cấp phép.
• Chưa có credential vault hoàn chỉnh cho production.
• Coverage cho identity/session setup vẫn cần mở rộng.
• Browser E2E trên môi trường deployment chưa hoàn thiện toàn bộ.
• Chưa có benchmark chính thức cho precision, recall và time-to-report.
• Chính sách lưu trữ raw evidence và retention vẫn cần được chốt.
• Approval production-grade và atomic consumption cần được hoàn thiện thêm.

4. Hướng phát triển

Giai đoạn 1 — Ổn định MVP

• Triển khai hệ thống trên một môi trường staging ổn định.
• Hoàn thiện browser end-to-end test.
• Bổ sung logging, metrics và tracing đã sanitize.
• Xây dựng runbook cho cài đặt, vận hành và xử lý sự cố.
• Hoàn thiện pause, resume, cancel và recovery cho campaign.
• Chuẩn hóa cấu hình secret và môi trường triển khai.

Kết quả mong đợi: hệ thống có thể demo và vận hành lặp lại với kết quả ổn định.

Giai đoạn 2 — Mở rộng khả năng kiểm thử

• Bổ sung identity và session setup theo từng testcase.
• Mở rộng kiểm thử authentication và authorization.
• Hỗ trợ nhiều biến thể payload có kiểm soát.
• Cải thiện expected-behavior oracle.
• Hoàn thiện approval binding và single-use approval.
• Mở rộng coverage cho các testcase business logic được phê duyệt.
• Bổ sung attack-chain dựa trên quan hệ và evidence cụ thể.

Kết quả mong đợi: tăng độ bao phủ mà không phá vỡ các safety invariant.

Giai đoạn 3 — Pilot trên staging được cấp phép

• Chạy pilot với một API staging thực tế.
• So sánh kết quả với chuyên gia kiểm thử thủ công.
• Đo precision, recall và false-positive rate.
• Đo thời gian từ lúc nhập API tới khi có báo cáo.
• Đo tỷ lệ endpoint và testcase được bao phủ.
• Thu thập phản hồi từ security reviewer và đội phát triển API.

Kết quả mong đợi: chứng minh giá trị thực tế và xác định những phần cần cải thiện trước production.

Giai đoạn 4 — Sẵn sàng cho vận hành thực tế

• Tích hợp credential vault và secret manager.
• Bổ sung audit log chống sửa đổi.
• Áp dụng phân quyền theo tổ chức và dự án.
• Xây dựng retention policy cho evidence.
• Tích hợp CI/CD và security workflow.
• Xuất báo cáo theo định dạng chuẩn.
• Hỗ trợ theo dõi remediation và retest.
• Tăng cường cô lập execution worker.

Kết quả mong đợi: đưa hệ thống từ pilot sang một nền tảng kiểm thử bảo mật API có khả năng quản trị.

5. Giá trị mang lại

PentestSyndicate không nhằm thay thế chuyên gia bảo mật. Hệ thống giúp chuyên gia:

• Giảm thời gian cho các thao tác lặp lại.
• Chuẩn hóa quy trình từ scope tới báo cáo.
• Tăng khả năng bao phủ endpoint và testcase.
• Kiểm soát chặt quyền thực thi của AI.
• Giảm false positive bằng evidence và validation.
• Dễ dàng audit, truy vết và tái hiện kết quả.
• Giữ con người ở vị trí quyết định đối với hành động rủi ro.

Giá trị cốt lõi của dự án là kết hợp khả năng lập kế hoạch và phân tích của hệ thống đa agent với các rào chắn kỹ thuật có tính quyết định, tạo ra quy trình kiểm thử API nhanh hơn, an toàn hơn và có bằng chứng rõ ràng hơn.