DocSentinel

KO | EN

gitlite — search

#javascript #python #typescript #go #golang #android #machine-learning #rust #nodejs #cli #kubernetes #pytorch #ios #mcp

(★ 85)

MCP server for AI agent for cybersecurity: automate assessment of documents, questionnaires & reports. Multi-format parsing, RAG knowledge base,Risks, compliance gaps, remediations.

DocSentinel 최신버젼 다운로드

최종 버전 다운로드 (.zip)

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

</div>

<img src="docs/images/docsentinel-mascot.png" width="220" alt="DocSentinel mascot logo"/>
 
 Security review mascot logo for the DocSentinel console and documentation.

DocSentinel 
 AI-powered SSDLC platform — Secure your software from requirements to operations

---

## What is DocSentinel?

**DocSentinel** is an AI-powered **SSDLC (Secure Software Development Lifecycle) platform** for security teams. It automates security activities across all six phases of the software development lifecycle using intelligent AI agents orchestrated by **LangGraph** and powered by **LangChain**. It automates the review of security-related **documents, forms, and reports** — from requirements and design through development, testing, deployment, and operations — comparing inputs against your policy and knowledge base to produce **structured assessment reports** with risks, compliance gaps, and remediation suggestions.

Instead of only reviewing documents at the pre-release stage, DocSentinel embeds security from day one:

Built as a **React console + FastAPI service + MCP/A2A agent gateway**,
DocSentinel integrates into local security review workflows, CI/CD pipelines,
AI agents, and multi-agent platforms without giving external agents approval
authority.

- **LangGraph orchestration**: Stateful, graph-based agent workflows with conditional branching per SSDLC stage.
- **Multi-format input**: PDF, Word, Excel, PPT, text — parsed into a unified format for the LLM.
- **Knowledge base (RAG)**: Upload policy and compliance documents; the agent uses them as reference when assessing.
- **Multiple LLMs**: Use OpenAI, Claude, Qwen, or **Ollama** (local) via a single interface.
- **Structured output**: JSON/Markdown reports with risk items, compliance gaps, and actionable remediations.

Ideal for enterprises that need to scale security assessments across many projects and SSDLC stages without proportionally scaling headcount.

---

## Product Tour

![DocSentinel console demo](https://raw.githubusercontent.com/arthurpanhku/DocSentinel/main/docs/images/docsentinel-console-demo.gif)

The local React console brings the main workflow into one operational surface:

- **Command Center**: live API and LLM status, assessment throughput, review
  demand, remediation queues, and recent activity.
- **Assessment Workbench**: upload project documents, choose SSDLC phase/skill,
  inspect AI-generated risks, and complete human review.
- **Governance Portal**: create projects, apply public framework overlays,
  generate controls, submit evidence, and track Pallas Lens readiness.
- **Knowledge Base**: ingest policies and standards for RAG-backed review.
- **Agent Integrations**: expose governed MCP and A2A tools to coding agents and
  multi-agent platforms without granting approval authority.
- **Settings**: switch providers such as DeepSeek, OpenAI, Anthropic, Qwen, or
  Ollama; API keys are accepted locally and only shown as masked previews.

---

## Why DocSentinel?

| Pain Point | DocSentinel Solution |
| :--- | :--- |
| **Fragmented SSDLC coverage** Most tools only address testing/deployment. | **Full lifecycle agents** cover all 6 SSDLC phases with dedicated AI personas. |
| **Fragmented criteria** Policies, standards, and precedents are scattered. | Single **knowledge base** ensures consistent findings and traceability. |
| **No automated threat modeling** Threat models are created ad-hoc. | **Design Agent** generates STRIDE/DREAD threat models from architecture docs. |
| **Heavy questionnaire workflow** Endless review cycles. | **Automated first-pass** and gap analysis reduces manual back-and-forth rounds. |
| **SAST/DAST report overload** Too many findings, too little context. | **Testing Agent** triages, prioritizes, and maps findings to threat models. |
| **Pre-release review pressure** Everything lands on security at the end. | **Shift-left** approach catches issues early in requirements and design. **Structured reports** help reviewers focus on decision-making. |
| **Scale vs. consistency** Manual reviews vary by reviewer. | **LangGraph workflows** and **unified pipeline** ensure consistent, auditable assessment across projects. |
| **SSDLC coverage gaps** Security involvement is uneven across lifecycle stages; early stages get less scrutiny. | **Stage-aware assessment** covers all 6 SSDLC stages with dedicated skills and checklists. |

*See the full problem statement and SSDLC phase details in [SPEC.md](./SPEC.md).*

---

## Architecture

DocSentinel is a **React Console + FastAPI** application with three governed
entry paths: REST APIs for the console and CI, MCP tools for coding agents, and
A2A JSON-RPC for remote agent delegation. These entry paths converge on the
same `AssessmentService`, LangGraph assessment pipeline, knowledge base, and
human-review lifecycle. Governance workflows from PallasGuard are now a
first-class domain beside assessment, backed by SQLModel records, policy packs,
control evidence, audit trails, and Pallas Lens readiness scoring.

![DocSentinel Architecture](https://raw.githubusercontent.com/arthurpanhku/DocSentinel/main/docsentinel_architecture.png)

```mermaid
flowchart TB
 subgraph Access["Users and Agent Access"]
 direction LR
 Staff["Security staff"]
 Console["React Console (Vite + Tailwind)"]
 RESTClient["REST / CI clients"]
 AgentClient["MCP / A2A clients"]
 end

subgraph Runtime["FastAPI Runtime"]
 direction LR
 Security["Security boundary CORS, rate limit, JWT/RBAC, gateway token or loopback"]
 REST["REST API routers assessments, KB, skills, settings, governance"]
 Gateway["Agent Gateway MCP tools + A2A JSON-RPC"]
 Tasks["AssessmentService async tasks, activity log, human review queue"]
 end

subgraph Pipeline["Assessment Pipeline"]
 direction LR
 Parse["Parse + guardrails Docling or legacy"]
 Graph["LangGraph workflow skill, isolated document data, policy/history/evidence context"]
 Review["LLM draft + review via LangChain"]
 Validate["Schema validation + S2O rule checks"]
 Report["Structured report risks, gaps, remediations"]
 end

subgraph Governance["Governance / Pallas Domain"]
 direction LR
 Projects["Projects + framework selection"]
 Controls["Control generator questionnaires + applicability"]
 Evidence["Gate submissions evidence + audit logs"]
 Lens["Pallas Lens readiness + exports"]
 end

subgraph Support["Shared Support Services"]
 direction LR
 KB["KnowledgeBaseService Chroma + LightRAG + history"]
 Policies["Policy packs + overlays schema service + S2O ontology"]
 LLMFactory["LLM factory settings + llm_config.json base_url SSRF guard"]
 Providers["OpenAI, Anthropic, Qwen, DeepSeek, Ollama, local OpenAI"]
 DB["SQLModel DB SQLite or Postgres"]
 end

Staff --> Console
    Console --> Security
    RESTClient --> Security
    AgentClient --> Security
    Security --> REST
    Security --> Gateway
    REST --> Tasks
    Gateway --> Tasks
    REST --> Projects
    REST --> KB
    Tasks --> Parse --> Graph --> Review --> Validate --> Report
    Report --> Tasks
    Report -->|project_id present| Evidence
    Projects --> Controls --> Evidence --> Lens
    Graph --> KB
    Graph --> Policies
    Review --> LLMFactory --> Providers
    Validate --> Policies
    Policies --> Controls
    Projects --> DB
    Controls --> DB
    Evidence --> DB
```

**Data flow (simplified):**

1.  Security staff work in the React console; REST clients call `/api/v1/*`;
    coding agents call MCP or A2A through the agent gateway.
2.  REST write paths use JWT/RBAC dependencies. Agent protocols use a bearer
    gateway token or loopback-only development access. LLM-costly POST paths are
    rate limited by IP or bearer token.
3.  Assessment submissions enter `AssessmentService`, which creates an async
    task, parses uploaded or approved local documents, applies guardrails, and
    invokes the LangGraph assessment pipeline.
4.  The LangGraph pipeline loads the selected skill, wraps untrusted document
    content as data, retrieves policy/history/evidence context from the KB, asks
    the LLM for draft/review text, and converts the result into the structured
    assessment schema.
5.  Deterministic services remain authoritative for governance decisions:
    policy-pack schemas, the S2O rule engine, control applicability, and schema
    validation cross-check LLM output before it enters the review queue.
6.  When an assessment is linked to a project, findings are persisted as Gate 3
    control evidence. Governance workflows then use the same SQLModel store for
    projects, controls, submissions, audit logs, Pallas Lens scoring, and exports.
7.  The KB persists chunks in Chroma, optional graph artifacts in LightRAG, and
    prior assessment history for reuse. Runtime LLM settings are loaded from
    `.env` plus `llm_config.json`, and every provider base URL is checked by the
    network guard before client construction.

*Detailed architecture: [ARCHITECTURE.md](./ARCHITECTURE.md) and [docs/01-architecture-and-tech-stack.md](./docs/01-architecture-and-tech-stack.md).*

---

## Core Capabilities

### SSDLC Full Lifecycle Coverage
Six dedicated AI agents, each with phase-specific skills, prompts, and knowledge base collections. Run individual phases or a full end-to-end SSDLC assessment:
- **Requirements**: Security requirements, compliance mapping, initial risk analysis.
- **Design**: Architecture review, STRIDE/DREAD threat modeling, SDR.
- **Development**: Secure coding standards, code review findings.
- **Testing**: SAST/DAST report triage, pen-test evaluation.
- **Deployment**: Release readiness, config security, hardening.
- **Operations**: Incident response, vulnerability monitoring, log audit.

### Automated Security Assessment
Submit security questionnaires, design documents, or audit reports. DocSentinel analyzes them using configured LLMs and identifies:
- **Security Risks**: Classified by severity (Critical, High, Medium, Low).
- **Compliance Gaps**: Missing controls against frameworks like ISO 27001, PCI DSS.
- **Remediation Steps**: Actionable advice to fix identified issues.

### Governance & Compliance Workflows
PallasGuard governance capabilities are merged into DocSentinel as first-class
project workflows:
- **Policy packs**: `generic-ssdlc` plus eight public overlays for NIST SSDF,
  MAS TRM, ISO 27001:2022, EU AI Act, ISO 42001, China MLPS 2.0, OWASP SAMM,
  and EU CRA.
- **Gate workflows**: Gate 1/3 questionnaire, submission, approval, audit, and
  evidence tracking flows backed by SQLModel and Alembic migrations.
- **Control generation**: Framework overlays generate applicable SCD controls
  and expected evidence without replacing DocSentinel's existing assessment
  engine.
- **Pallas Lens**: Project readiness scoring summarizes control coverage,
  evidence depth, and next actions in the React governance portal.

### Intelligent Agent Orchestration (LangGraph)
- **Structured workflows**: LangGraph nodes separate context collection, drafting,
  evidence review, schema conversion, and governance persistence
- **Cross-phase traceability**: Threats from Design link to test cases in Testing and monitoring rules in Operations
- **Conditional routing**: Agents activate based on project risk level, compliance requirements, or user selection
- **Human-in-the-loop**: Agent-created assessments enter a review queue and cannot
  approve themselves
- **Planned hardening**: Explicit plan gates, durable LangGraph checkpoints, and
  resumable execution are tracked in the development roadmap below

### Threat Evidence Critic
Design-phase STRIDE threats are independently checked against the currently
uploaded architecture documents in one inference-time pass:

- Every threat receives a `supported`, `contradicted`, or
  `insufficient_evidence` verdict with a support score and reviewer-facing
  rationale.
- Evidence references use content hashes plus stable line locators and include
  the exact source excerpt shown in the Assessment Workbench.
- Only current-project document passages are accepted. Invented, missing, policy,
  or historical references cannot make a threat appear supported.
- Verification failures safely abstain as `insufficient_evidence`; all verdicts
  still require human review.
- No training or fine-tuning pipeline is required. The critic uses the configured
  OpenAI, Anthropic, Qwen, DeepSeek, compatible, or local runtime model.

For a public-demo input and walkthrough, see
[`examples/evidence-critic-architecture.md`](./examples/evidence-critic-architecture.md)
and [`examples/README.md`](./examples/README.md).

### RAG-Powered Knowledge Base
Upload your organization's security policies, standards, and past audits. Phase-specific collections ensure each agent retrieves the most relevant context:
- Requirements: compliance frameworks, security policies
- Design: threat catalogs, security patterns
- Development: secure coding standards (OWASP)
- Testing: vulnerability databases, remediation guides
- Deployment: CIS benchmarks, hardening guides
- Operations: CVE databases, incident playbooks

### LangGraph Agent Orchestration
Powered by **LangChain + LangGraph** — stateful, graph-based agent workflows with conditional routing per SSDLC stage. Parallel execution of Policy and Evidence agents, followed by Drafter and Reviewer agents.

### API-First, MCP & A2A Ready
Use the local React console for human review, integrate CI/CD pipelines through the
REST API, or expose the same assessment capabilities to AI agents (Claude Desktop,
Cursor, OpenClaw) through MCP. A2A-compatible platforms can delegate assessment
tasks to DocSentinel as a specialist security agent.

### Reproducible Evaluation Harness
DocSentinel includes an `evals/` harness for measuring assessment quality against
public and future golden datasets without going through HTTP or the UI. The first
implemented path covers OWASP Benchmark v1.2 SAST triage:

- **Dataset hygiene**: raw benchmark data is fetched locally into ignored paths;
 only the fetch script, checksum, manifest, and tiny test fixture are committed.
- **Direct pipeline execution**: the runner calls `AssessmentService.submit()`
 with `phase="testing"` and `skill_id="ssdlc-testing"`, matching production task
 semantics while staying self-contained.
- **Hard-key scoring**: M1 scores CWE-based binary triage with accuracy,
 precision, recall, F1, and false-positive rate, with no LLM judge.
- **Threat grounding scoring**: the Evidence Critic scorer measures verdict
 accuracy, supported precision/recall/F1, contradiction recall, abstention rate,
 citation validity, and the full verdict confusion matrix.
- **Scorecards**: every run writes machine-readable `scorecard.json` and a
 human-readable `scorecard.md` under `evals/reports/<run_id>/`.

```bash
python evals/datasets/owasp_benchmark/fetch.py
python -m evals.runner.run_eval \
  --dataset-id owasp_benchmark \
  --raw-dir evals/datasets/owasp_benchmark/raw/BenchmarkJava-master \
  --run-id local-owasp \
  --repeats 1
```

See [docs/07-evaluation-plan.md](./docs/07-evaluation-plan.md) for the full
methodology and milestone roadmap.

---

## Agent Architecture Development Roadmap

This roadmap turns the project's agent-safety principles into implementation
work that can be delivered and reviewed incrementally. It is informed by
Microsoft Learn's
[Designing Agent Architecture and SDLC Integration](https://learn.microsoft.com/en-us/training/modules/design-agent-architecture-integration/)
module and follows one governing rule: **agents propose; deterministic policy
and authorized humans accept**.

The target control flow is:

```text
Task contract -> Visible plan -> Bounded execution -> Objective evaluation
              -> Human/policy approval -> Published result
```

Status legend: `[x]` implemented baseline, `[ ]` planned work. Priorities indicate
delivery order rather than release dates.

### Current Baseline

- [x] Phase-specific SSDLC skills and a shared assessment pipeline for REST,
  MCP, and A2A entry points.
- [x] Human review is mandatory for agent-gateway submissions; external agents
  cannot approve their own work.
- [x] MCP document-root confinement, token/loopback boundaries, bounded KB
  results, input guardrails, and LLM base-URL network checks.
- [x] Structured reports with citations, document hashes, confidence, threat
  evidence verification, and remediation tracking.
- [x] Reproducible evaluation harness with OWASP triage and threat-grounding
  scorecards.

### M0 — Repository Governance (P0)

Goal: make the pull request the enforceable control point for human and
agent-generated changes.

- [ ] Add `CODEOWNERS` for security-sensitive paths, including
  `.github/workflows/`, `app/core/`, `app/agent_gateway/`, migrations,
  deployment files, and policy packs.
- [ ] Expand the pull request template with required Goal, Scope, Plan, Success
  Criteria, Risk/Mitigations, Evidence, and Rollback/Escalation sections.
- [ ] Add a required Plan Gate workflow that validates meaningful PR fields and
  classifies changes as low, medium, high, or critical risk.
- [ ] Configure the `main` ruleset to require pull requests, passing CI and Plan
  Gate checks, resolved conversations, and CODEOWNERS approval for sensitive
  changes.
- [ ] Upload test, coverage, contract, and evaluation outputs as durable GitHub
  Actions artifacts named with the workflow run ID and commit SHA.

Exit criteria: a planless change or an unreviewed sensitive-path change cannot
be merged into `main`.

### M1 — Task Contract and Plan–Act–Evaluate Graph (P1)

Goal: make agent intent, authority, outputs, and success conditions inspectable
before effects occur.

- [ ] Define a versioned `AgentTaskContract` schema containing goal, inputs,
  allowed paths/tools, expected outputs, success criteria, risk tier, approval
  mode, retry limit, and escalation owner.
- [ ] Persist the task contract and expose it through the assessment API and
  review console.
- [ ] Add an explicit read-only planning node and immutable `PlanArtifact` to the
  assessment graph.
- [ ] Implement a risk policy: low-risk tasks may use plan + execution in one
  review; workflow, authentication, infrastructure, and production-impacting
  tasks require plan-first approval.
- [ ] Separate evaluation from generation so schema validation, evidence
  grounding, deterministic rules, and evaluation thresholds remain independent
  of the drafting agent.
- [ ] Add transition and authorization tests proving that agents cannot skip the
  plan/evaluation stages or approve their own output.

Exit criteria: every assessment can answer what was requested, what the agent
was allowed to do, what plan it followed, and which signals determined success.

### M2 — Durable Execution and Reliability (P1)

Goal: make long-running assessments restart-safe, bounded, and recoverable.

- [ ] Replace in-memory assessment task state with database-backed task,
  revision, activity, and review records.
- [ ] Compile LangGraph workflows with a database-backed checkpointer using
  `task_id` as the stable execution/thread identifier.
- [ ] Make nodes idempotent and store node input/output hashes to prevent
  duplicate side effects during resume.
- [ ] Add bounded retries for transient failures only; after two repeated
  failures, stop and escalate with attempted actions, evidence, and a suggested
  human next step.
- [ ] Add cancellation, timeout, resume, and disaster-recovery tests.

Exit criteria: a process restart can resume an assessment without losing review
history, duplicating effects, or entering an infinite retry loop.

### M3 — Observability, Tools, MCP, and Secrets (P2)

Goal: make every meaningful agent action attributable and enforce least
privilege independently of model instructions.

- [ ] Create an evidence manifest for each run containing task and graph-run
  IDs, node, source channel, document/output hashes, skill and policy-pack
  versions, model/prompt identifiers, citations, timestamps, and reviewer
  decision.
- [ ] Define capability profiles: planning and review agents are read-only;
  execution agents receive narrow allowlisted tools for the current task.
- [ ] Treat additions or expansions to MCP tools as high-risk governed changes
  with explicit security tests and owner review.
- [ ] Add pre-action policy hooks, post-action audit hooks, and error hooks for
  escalation; hooks must be able to block actions without relying on the LLM.
- [ ] Scope secrets to the smallest runtime component and environment, prevent
  secret values from entering prompts/artifacts, and document network-egress
  policy for hosted deployments.

Exit criteria: operators can determine who or what performed an action, against
which inputs and code state, under which capability policy, and with what result.

### M4 — Evaluation and Release Gates (P2)

Goal: turn assessment quality and production safety into objective release
signals.

- [ ] Expand the evaluation harness across all SSDLC phases and add held-out
  expert-labelled cases with inter-annotator agreement.
- [ ] Version approved scorecard baselines and fail CI on agreed grounding,
  recall, false-positive, calibration, or latency regressions.
- [ ] Report variance across repeated runs and preserve judge rationales and
  human-audit results as reviewable artifacts.
- [ ] Require protected GitHub Environments and authorized reviewers for
  production-impacting exports or deployments; agents may prepare but not
  approve or execute the final release action.
- [ ] Deploy sensitive configuration from an explicit commit or tag rather than
  an unpinned branch head, with a tested rollback procedure.

Exit criteria: releases have reproducible quality evidence, an approved code
reference, a human decision for critical effects, and a verified rollback path.

### Definition of Done for Roadmap Work

Every roadmap PR must include:

- a bounded plan and changed-path scope;
- verifiable functional and security success criteria;
- automated tests for allowed and denied behavior;
- durable evidence or artifacts linked to the commit under test;
- documentation and migration notes where contracts or persistence change; and
- rollback and escalation guidance for high-risk changes.

Implementation should proceed in milestone order because M0 establishes the
repository controls used to review M1–M4 safely. Each unchecked item is intended
to be small enough to become a dedicated GitHub issue and pull request.

---

## Agent Integration (MCP + A2A)

Use MCP to expose bounded tools to Claude Desktop, Cursor, coding agents, and
workflow platforms. Use A2A to expose DocSentinel as a remote specialist agent.
REST, MCP, and A2A submissions share the same task lifecycle and activity log.
Agent-created assessments always remain drafts until a human reviewer approves
them in the console.

MCP exposes five governed tools:

- `submit_document_assessment`
- `get_assessment_status`
- `assess_document` (compatibility tool)
- `query_knowledge_base`
- `get_agent_gateway_status`

The A2A Agent Card advertises assessment submission, assessment retrieval, and
security knowledge query skills.

### What can it do?
Once connected, you can ask your AI agent:
> "Analyze the attached `requirements.pdf` for missing security requirements using DocSentinel."
>
> "Run a STRIDE threat model on `system-design.pdf` using the Design Agent."
>
> "Triage these SonarQube SAST findings and prioritize by risk."

### Configuration Guide

#### 1. Claude Desktop
Add to your `claude_desktop_config.json`:
```json
{
  "mcpServers": {
    "docsentinel": {
      "command": "/path/to/DocSentinel/.venv/bin/python",
      "args": ["/path/to/DocSentinel/app/mcp_server.py"],
      "env": {
        "OPENAI_API_KEY": "sk-...",
        "CHROMA_PERSIST_DIR": "/absolute/path/to/data/chroma",
        "MCP_DOCUMENT_ROOTS": "/absolute/path/to/approved/documents"
      }
    }
  }
}
```

`assess_document` only reads files inside `MCP_DOCUMENT_ROOTS`. Use `:` to
separate multiple roots on macOS/Linux, or `;` on Windows. If unset, the
server only allows `./examples`.

FastAPI also serves Streamable HTTP MCP at `/mcp/` and publishes the A2A Agent
Card at `/.well-known/agent-card.json`. Tokenless protocol access is
loopback-only. External agents cannot approve, reject, or bypass human review.

For network, Docker, or reverse-proxy access, configure:

```dotenv
AGENT_GATEWAY_TOKEN=generate-a-long-random-value
AGENT_GATEWAY_PUBLIC_URL=https://docsentinel.internal.example
AGENT_GATEWAY_ALLOWED_HOSTS=docsentinel.internal.example
AGENT_GATEWAY_ALLOWED_ORIGINS=https://trusted-agent-console.internal.example
```

Clients send `Authorization: Bearer <AGENT_GATEWAY_TOKEN>`. Keep
`MCP_DOCUMENT_ROOTS`, allowed hosts, and allowed origins as narrow as possible.
Docker bridge traffic is not treated as loopback, so published MCP/A2A ports
require a token.

#### 2. Cursor
1. Go to **Settings > Features > MCP**.
2. Click **+ Add New MCP Server**.
   - **Name**: `docsentinel`
   - **Type**: `stdio`
   - **Command**: `/path/to/DocSentinel/.venv/bin/python`
   - **Args**: `/path/to/DocSentinel/app/mcp_server.py`

*See full guide in [docs/06-agent-integration.md](docs/06-agent-integration.md).*

---

## Quick Start

### Option A: One-Click Deployment (Recommended)

```bash
git clone https://github.com/arthurpanhku/DocSentinel.git
cd DocSentinel
chmod +x deploy.sh
./deploy.sh
```

-   **React Console**: [http://localhost:8000/console](http://localhost:8000/console)
-   **Agent Integrations**: [http://localhost:8000/console/integrations](http://localhost:8000/console/integrations)
-   **API Docs**: [http://localhost:8000/api-docs](http://localhost:8000/api-docs)
-   **A2A Agent Card**: [http://localhost:8000/.well-known/agent-card.json](http://localhost:8000/.well-known/agent-card.json)

To connect an external agent through the published Docker port, set
`AGENT_GATEWAY_TOKEN` in `.env` before running `./deploy.sh`.

### Option B: Manual Setup

**Prerequisites**: **Python 3.11+** and **Node.js 20+**. Optional:
[Ollama](https://ollama.ai) (`ollama pull llama2`).

```bash
git clone https://github.com/arthurpanhku/DocSentinel.git
cd DocSentinel
python3 -m venv .venv
source .venv/bin/activate   # Windows: .venv\Scripts\activate
pip install -r requirements.txt
cp .env.example .env        # Edit if needed: LLM_PROVIDER=ollama or openai
npm install --prefix frontend
npm run build --prefix frontend
uvicorn app.main:app --reload --host 0.0.0.0 --port 8000
```

#### DeepSeek example

Set these values in `.env`, or use the **Settings** page after the server is
running. Never commit real API keys.

```dotenv
LLM_PROVIDER=deepseek
DEEPSEEK_BASE_URL=https://api.deepseek.com
DEEPSEEK_MODEL=deepseek-chat
DEEPSEEK_API_KEY=sk-your-deepseek-key
```

-   **API docs**: [http://localhost:8000/api-docs](http://localhost:8000/api-docs) · **Health**: [http://localhost:8000/health](http://localhost:8000/health)
-   **React Console**: [http://localhost:8000/console](http://localhost:8000/console)
-   **Agent Integrations**: [http://localhost:8000/console/integrations](http://localhost:8000/console/integrations)
-   **MCP Streamable HTTP**: `http://localhost:8000/mcp/`
-   **A2A Agent Card**: [http://localhost:8000/.well-known/agent-card.json](http://localhost:8000/.well-known/agent-card.json)
-   **Legacy Review Console (HITL)**: [http://localhost:8000/docs/review-console.html](http://localhost:8000/docs/review-console.html)

### React Console

DocSentinel includes a React + TypeScript + Vite + Tailwind CSS console for assessments, knowledge base operations, skills, and system status.

![DocSentinel React Console](https://raw.githubusercontent.com/arthurpanhku/DocSentinel/main/docs/images/react-console-dashboard.png)

```bash
npm install --prefix frontend
npm run build --prefix frontend
uvicorn app.main:app --reload --host 0.0.0.0 --port 8000
```

Open [http://localhost:8000/console](http://localhost:8000/console). For frontend-only development, run:

```bash
npm run dev --prefix frontend
```

The Vite dev server proxies `/api`, `/health`, and `/config` to `http://localhost:8000`.

The **Settings** page can update the running server's LLM provider, model, base URL, and API key. API keys are only returned to the UI as masked previews. For persistent startup defaults, set the matching values in `.env`.

---

### Example: Submit an SSDLC assessment

```bash
# Run a Design phase assessment (threat modeling)
curl -X POST "http://localhost:8000/api/v1/assessments" \
  -F "files=@examples/architecture-doc.pdf" \
  -F "phase=design" \
  -F "scenario_id=threat-modeling"

# Response: { "task_id": "...", "status": "accepted" }
# Get the result
curl "http://localhost:8000/api/v1/assessments/TASK_ID"
```

### Example: Upload to KB and query

```bash
# Upload a security policy to the requirements KB collection
curl -X POST "http://localhost:8000/api/v1/kb/documents" \
  -F "file=@examples/sample-policy.txt" \
  -F "collection=kb_requirements"

# Query the KB (RAG)
curl -X POST "http://localhost:8000/api/v1/kb/query" \
  -H "Content-Type: application/json" \
  -d '{"query": "What are the access control requirements?", "top_k": 5}'
```

---

## Hosted deployment

A hosted deployment is available on [Fronteir AI](https://fronteir.ai/mcp/arthurpanhku-docsentinel).

## Project Layout

```text
DocSentinel/
├── frontend/             # React + TypeScript + Vite + Tailwind console
├── app/                  # Application code
│   ├── api/              # REST routes: assessments, KB, health, skills
│   ├── agent_gateway/    # MCP/A2A adapters, auth boundary, Agent Card
│   ├── agent/            # LangGraph orchestrator, phase agents, skills
│   │   ├── orchestrator.py    # LangGraph state machine & phase routing
│   │   ├── agents/            # Phase-specific agent implementations
│   │   ├── ssdlc/             # SSDLC pipeline: stage router, stage skills, checklists
│   │   ├── skills_registry.py # Built-in skills per SSDLC phase
│   │   └── skills_service.py  # Skill CRUD and management
│   ├── core/             # Config, guardrails, security, DB
│   ├── kb/               # Knowledge Base (Chroma + LightRAG graph RAG)
│   ├── llm/              # LangChain LLM abstraction (OpenAI, Ollama)
│   ├── parser/           # Document parsing (Docling + SAST/DAST + legacy)
│   ├── models/           # Pydantic / SQLModel models
│   ├── services/         # Shared assessment task lifecycle
│   ├── main.py           # FastAPI app entry point
│   └── mcp_server.py     # MCP stdio + Streamable HTTP tools
├── tests/                # Automated tests (pytest)
├── evals/                # Reproducible quality eval harness and scorecards
├── examples/             # Sample files (questionnaires, policies, reports)
├── docs/                 # Design & Spec documentation
│   ├── 01-architecture-and-tech-stack.md
│   ├── 02-api-specification.yaml
│   ├── 03-assessment-report-and-skill-contract.md
│   ├── 04-integration-guide.md
│   ├── 05-deployment-runbook.md
│   ├── 06-agent-integration.md
│   ├── 07-evaluation-plan.md
│   └── schemas/
├── .github/              # Issue/PR templates, CI (Actions)
├── Dockerfile
├── docker-compose.yml
├── docker-compose.ollama.yml
├── CONTRIBUTING.md
├── CODE_OF_CONDUCT.md
├── CHANGELOG.md
├── SPEC.md               # PRD with SSDLC phase definitions
├── ARCHITECTURE.md        # System architecture with LangGraph design
├── LICENSE
├── SECURITY.md
├── requirements.txt
├── requirements-dev.txt
└── .env.example
```

---

## Configuration

*See [.env.example](./.env.example) and [docs/05-deployment-runbook.md](./docs/05-deployment-runbook.md) for full options.*

---

## Tech Stack

---

## Documentation and PRD

-   **[ARCHITECTURE.md](./ARCHITECTURE.md)** — System architecture: LangGraph design, SSDLC agents, data flow, deployment.
-   **[SPEC.md](./SPEC.md)** — Product requirements: SSDLC phases, features, security controls.
-   **[CHANGELOG.md](./CHANGELOG.md)** — Version history; [Releases](https://github.com/arthurpanhku/DocSentinel/releases).
-   **Design docs** [docs/](./docs/): Architecture, API spec (OpenAPI), contracts, integration guides, deployment runbook.
-   **[docs/07-evaluation-plan.md](./docs/07-evaluation-plan.md)** — Evaluation methodology and milestone plan for `evals/`.

---

## Development & Testing

### Option A: One-Click Test (Recommended)
```bash
chmod +x test_integration.sh
./test_integration.sh
```

### Option B: Manual
```bash
pip install -r requirements-dev.txt
pytest
pytest tests/test_skills_api.py   # Run specific test
pytest evals/tests                # Run evaluation harness tests
```

## Contributing

Issues and Pull Requests are welcome. Please read [CONTRIBUTING.md](CONTRIBUTING.md) for setup, tests, and commit guidelines. By participating you agree to the [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md).

AI-Assisted Contribution: We encourage using AI tools to contribute! Check out [CONTRIBUTING_WITH_AI.md](CONTRIBUTING_WITH_AI.md) for best practices.

Submit a Skill Template: Have a great security persona for an SSDLC phase? Submit a [Skill Template](https://github.com/arthurpanhku/DocSentinel/issues/new?template=new_skill_template.md) or add it to `examples/templates/`.

---

## Security

-   **Vulnerability reporting**: See [SECURITY.md](./SECURITY.md) for responsible disclosure.
-   **Security requirements**: Follows security controls in [SPEC §7.2](./SPEC.md).
-   **Document confinement**: MCP/A2A document paths must resolve inside `MCP_DOCUMENT_ROOTS`; symlink escapes are rejected before file reads.
-   **Agent authority**: External agents may submit and inspect drafts, but cannot approve their own assessments.
-   **Remote access**: Tokenless MCP/A2A access is loopback-only. Network deployments require a bearer token, TLS, and narrow Host/Origin allow-lists.

---

## License

This project is licensed under the **MIT License** — see the [LICENSE](./LICENSE) file for details.

---

## Star History

[![Star History Chart](https://api.star-history.com/svg?repos=arthurpanhku/DocSentinel&type=Date)](https://star-history.com/#arthurpanhku/DocSentinel&Date)

---

## Author and Links

-   **Author**: PAN CHAO (Arthur Pan)
-   **Repository**: [github.com/arthurpanhku/DocSentinel](https://github.com/arthurpanhku/DocSentinel)
-   **SPEC and design docs**: See links above.

If you use DocSentinel in your organization or contribute back, we'd love to hear from you (e.g. via GitHub Discussions or Issues).

DocSentinel

DocSentinel 최신버젼 다운로드

오늘의 추천 프로젝트

Was this content helpful?

Recent Feedback

DocSentinel

DocSentinel 최신버젼 다운로드

오늘의 추천 프로젝트

Was this content helpful?

Recent Feedback

Download README