DocSentinel
English | 简体中文 | 日本語 | 한국어 | Français | Deutsch
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:
SSDLC Phase | What DocSentinel Does |
Requirements | Extract security requirements, identify compliance obligations (GDPR, PCI DSS, SOC2) |
Design | Automated threat modeling (STRIDE/DREAD), security architecture review, SDR reports |
Development | Secure coding assessment, SAST findings triage, coding guidance |
Testing | SAST/DAST report analysis, penetration test review, vulnerability prioritization |
Deployment | Configuration security review, hardening assessment, release sign-off |
Operations | Vulnerability monitoring, incident response assistance, log audit |
Built as a headless API + MCP service, DocSentinel integrates into your CI/CD pipelines, AI agents (Claude Desktop, Cursor, OpenClaw), and existing security workflows.
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.
Related MCP server: tardigrade-shield
Why DocSentinel?
Pain Point | DocSentinel Solution |
Fragmented SSDLC coverageMost tools only address testing/deployment. | Full lifecycle agents cover all 6 SSDLC phases with dedicated AI personas. |
Fragmented criteriaPolicies, standards, and precedents are scattered. | Single knowledge base ensures consistent findings and traceability. |
No automated threat modelingThreat models are created ad-hoc. | Design Agent generates STRIDE/DREAD threat models from architecture docs. |
Heavy questionnaire workflowEndless review cycles. | Automated first-pass and gap analysis reduces manual back-and-forth rounds. |
SAST/DAST report overloadToo many findings, too little context. | Testing Agent triages, prioritizes, and maps findings to threat models. |
Pre-release review pressureEverything 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. consistencyManual reviews vary by reviewer. | LangGraph workflows and unified pipeline ensure consistent, auditable assessment across projects. |
SSDLC coverage gapsSecurity 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.
Architecture
DocSentinel is built on LangGraph for stateful agent orchestration and LangChain for unified LLM access. Six phase-specific agents are coordinated by a graph-based state machine with cross-phase context sharing. The orchestrator coordinates parsing, SSDLC stage routing, the knowledge base (RAG), skills, and the LLM. You can use cloud or local LLMs and optional integrations (e.g. AAD, ServiceNow) as your environment requires.

flowchart TB
subgraph User["User / Security Staff"]
end
subgraph Access["Access Layer"]
API["REST API / MCP"]
end
subgraph Orchestration["SSDLC Orchestration (LangGraph)"]
Router["Phase Router"]
A1["Requirements Agent"]
A2["Design Agent"]
A3["Development Agent"]
A4["Testing Agent"]
A5["Deployment Agent"]
A6["Operations Agent"]
end
subgraph Core["Core Services"]
KB["Knowledge Base (RAG)"]
Parser["Parser"]
Skill["Skills"]
Mem["Memory"]
end
subgraph LLM["LLM Layer (LangChain)"]
Abst["LLM Abstraction"]
end
subgraph Backends["LLM Backends"]
Cloud["OpenAI / Claude / Qwen"]
Local["Ollama / vLLM"]
end
User --> API
API --> Router
Router --> A1 & A2 & A3 & A4 & A5 & A6
A1 & A2 & A3 & A4 & A5 & A6 --> KB & Parser & Skill
A1 & A2 & A3 & A4 & A5 & A6 --> Abst
Abst --> Cloud & LocalData flow (simplified):
User selects SSDLC phase(s) and uploads documents (or optionally lets the SSDLC Router auto-detect the stage).
Parser converts files (PDF, Word, Excel, PPT, SAST/DAST reports, etc.) to text/Markdown.
LangGraph Router dispatches to the appropriate Phase Agent(s), loading stage-specific skill + checklist.
Phase Agent queries KB (phase-specific collections) and applies Skills; Policy+Evidence run in parallel, then Drafter+Reviewer.
LLM (via LangChain) produces structured findings with cross-phase traceability.
Returns assessment report (risks, threats, gaps, remediations, confidence, SSDLC stage).
Detailed architecture: ARCHITECTURE.md and 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.
Intelligent Agent Orchestration (LangGraph)
Stateful workflows: LangGraph state machine maintains context across phases
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: Interrupt points for human review at phase boundaries
Checkpointing: Long-running assessments persist state and resume
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 Ready
Designed as a headless service. Integrate into CI/CD pipelines via REST API, or use as a super-tool within AI agents (Claude Desktop, Cursor, OpenClaw) via MCP.
Agent Integration (MCP)
Connect DocSentinel to Claude Desktop, Cursor, or OpenClaw to use it as a powerful SSDLC security skill.
What can it do?
Once connected, you can ask your AI agent:
"Analyze the attached
requirements.pdffor missing security requirements using DocSentinel.""Run a STRIDE threat model on
system-design.pdfusing the Design Agent.""Triage these SonarQube SAST findings and prioritize by risk."
Configuration Guide
1. Claude Desktop
Add to your claude_desktop_config.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"
}
}
}
}2. Cursor
Go to Settings > Features > MCP.
Click + Add New MCP Server.
Name:
docsentinelType:
stdioCommand:
/path/to/DocSentinel/.venv/bin/pythonArgs:
/path/to/DocSentinel/app/mcp_server.py
See full guide in docs/06-agent-integration.md.
Quick Start
Option A: One-Click Deployment (Recommended)
git clone https://github.com/arthurpanhku/DocSentinel.git
cd DocSentinel
chmod +x deploy.sh
./deploy.shAPI Docs: http://localhost:8000/docs
Option B: Manual Setup
Prerequisites: Python 3.10+. Optional: Ollama (ollama pull llama2).
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
uvicorn app.main:app --reload --host 0.0.0.0 --port 8000API docs: http://localhost:8000/docs · Health: http://localhost:8000/health
Review Console (HITL): http://localhost:8000/docs/review-console.html
Example: Submit an SSDLC assessment
# 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
# 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.
Project Layout
DocSentinel/
├── app/ # Application code
│ ├── api/ # REST routes: assessments, KB, health, skills
│ ├── 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
│ ├── main.py # FastAPI app entry point
│ └── mcp_server.py # MCP Server for agent integration
├── tests/ # Automated tests (pytest)
├── 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
│ └── 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.exampleConfiguration
Variable | Description | Default |
|
|
|
| Local LLM |
|
| OpenAI | -- |
| Vector DB path |
|
| Parser: |
|
| Enable LightRAG graph retrieval |
|
| LangGraph checkpoint persistence |
|
| Default phases for full assessment |
|
| Default SSDLC stage if not specified |
|
| Upload limits |
|
See .env.example and docs/05-deployment-runbook.md for full options.
Tech Stack
Layer | Technology | Purpose |
Agent Orchestration | LangGraph | Stateful graph-based SSDLC workflow engine |
LLM Framework | LangChain | Unified LLM abstraction, prompts, tools, RAG |
Web/API | FastAPI | Async REST API with auto OpenAPI |
Vector Store | ChromaDB + LightRAG | Hybrid vector + graph RAG |
Parsing | Docling + legacy fallback | Multi-format document parsing |
LLM Providers | OpenAI, Ollama | Cloud and local LLM support |
Language | Python 3.10+ | Primary development language |
Documentation and PRD
ARCHITECTURE.md — System architecture: LangGraph design, SSDLC agents, data flow, deployment.
SPEC.md — Product requirements: SSDLC phases, features, security controls.
CHANGELOG.md — Version history; Releases.
Design docs docs/: Architecture, API spec (OpenAPI), contracts, integration guides, deployment runbook.
Development & Testing
Option A: One-Click Test (Recommended)
chmod +x test_integration.sh
./test_integration.shOption B: Manual
pip install -r requirements-dev.txt
pytest
pytest tests/test_skills_api.py # Run specific testContributing
Issues and Pull Requests are welcome. Please read CONTRIBUTING.md for setup, tests, and commit guidelines. By participating you agree to the CODE_OF_CONDUCT.md.
AI-Assisted Contribution: We encourage using AI tools to contribute! Check out CONTRIBUTING_WITH_AI.md for best practices.
Submit a Skill Template: Have a great security persona for an SSDLC phase? Submit a Skill Template or add it to examples/templates/.
Security
Vulnerability reporting: See SECURITY.md for responsible disclosure.
Security requirements: Follows security controls in SPEC §7.2.
License
This project is licensed under the MIT License — see the LICENSE file for details.
Star History
Author and Links
Author: PAN CHAO (Arthur Pan)
Repository: 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).
Available Tools
2 toolsassess_documentC
Assess a security document (PDF, Word, etc.) and return a risk report.
Args: file_path: Absolute path to the file to be assessed. scenario_id: The assessment scenario ID (default: "default").
Returns: JSON string containing the assessment report (risks, gaps, remediations).
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | ||
| scenario_id | No | default |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool returns a risk report but doesn't disclose behavioral traits like what types of security documents are supported beyond 'PDF, Word, etc.', whether the assessment is read-only or modifies the file, authentication requirements, rate limits, or error conditions. The description is minimal and lacks critical operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the core purpose in the first sentence and parameter details in a structured format. Every sentence earns its place, though it could be slightly more concise by integrating the 'Args' and 'Returns' sections more fluidly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (assessing security documents), no annotations, and an output schema present (which handles return values), the description is partially complete. It covers the basic purpose and parameters but lacks context on usage scenarios, behavioral traits, and detailed parameter semantics, making it adequate but with clear gaps for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining that 'file_path' is for 'the file to be assessed' and 'scenario_id' is for 'the assessment scenario ID', which clarifies the purpose of each parameter beyond their titles. However, it doesn't detail format constraints (e.g., valid file paths, scenario ID options) or provide examples, leaving gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Assess a security document (PDF, Word, etc.) and return a risk report.' This specifies the verb ('assess'), resource ('security document'), and output ('risk report'), distinguishing it from the sibling tool 'query_knowledge_base'. However, it doesn't explicitly differentiate from that sibling beyond the different resource focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions a sibling tool 'query_knowledge_base' but gives no context about when to choose one over the other, nor any prerequisites or exclusions for using this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_knowledge_baseB
Query the internal security knowledge base (policies, standards).
Args: query: The search query (e.g., "password complexity requirements"). top_k: Number of results to return.
Returns: JSON string with retrieved document chunks.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| top_k | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool queries a knowledge base and returns JSON with document chunks, but lacks critical details like authentication requirements, rate limits, error handling, or whether it's read-only (implied but not explicit).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns) and uses minimal sentences. Each part earns its place, though the 'Returns' section could be slightly more detailed given the lack of annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (returns JSON string), the description doesn't need to detail return values. However, with no annotations and a sibling tool, it lacks guidance on usage context and behavioral traits. The parameter explanations help, but overall completeness is adequate with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides meaningful context for both parameters: 'query' is explained with an example ('password complexity requirements'), and 'top_k' specifies it controls the number of results. This adds value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Query') and resource ('internal security knowledge base') with specific content scope ('policies, standards'). It distinguishes from the sibling 'assess_document' by focusing on retrieval rather than assessment. However, it doesn't explicitly contrast with the sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the sibling 'assess_document' or any alternatives. It mentions the tool's purpose but offers no context about appropriate use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v0.2.0- First observed
assess_document - First observed
query_knowledge_base
TDQS
Scored across 2 tools
The two tools have clearly distinct purposes: assess_document analyzes security documents for risks, while query_knowledge_base searches an internal knowledge base. There is no overlap in functionality or ambiguity between them.
Both tools follow a consistent verb_noun naming pattern (assess_document, query_knowledge_base). The naming is predictable and readable across the set.
With only two tools, the server feels thin for its apparent security document assessment domain. This limited set may force agents to work around gaps in functionality, such as missing operations for managing documents or updating the knowledge base.
The tool surface is severely incomplete for a security document assessment system. There are no tools for creating, updating, or deleting documents or knowledge base entries, and no way to manage assessment scenarios or reports beyond the basic assess_document operation.
Maintenance
Related MCP Connectors
EU compliance corpus across 8 frameworks (NIS2, DORA, AI Act, ISO 27001 + more) via MCP.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
AI governance MCP server for EU AI Act compliance and jurisdiction verification
Compliance frameworks (SOC 2, ISO 27001, CMMC, NIST, more) delivered to AI agents as MCP tools.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceMCP server enabling AI assistants to interact with the Qualys vulnerability management platform. Supports investigation, risk assessment, compliance, remediation, security overview, and report management.10 npm2MIT
- AlicenseNot gradedqualityDmaintenanceModel-agnostic cybersecurity MCP server for CMMC 2.0 compliance workflows with air-gapped Ollama mode.MIT
- AlicenseCqualityCmaintenanceAI-powered security scanning MCP server that exposes 25+ professional tools, enabling penetration testing and security assessments through natural language interaction with AI agents like Claude Desktop.31MIT
- FlicenseNot gradedqualityCmaintenanceA production-style MCP server providing AI models with cybersecurity tools including port scanning, WHOIS, DNS, threat intelligence, CVE lookup, and more.-