Skip to main content
Glama

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.

DocSentinel Architecture

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 & Local

Data flow (simplified):

  1. User selects SSDLC phase(s) and uploads documents (or optionally lets the SSDLC Router auto-detect the stage).

  2. Parser converts files (PDF, Word, Excel, PPT, SAST/DAST reports, etc.) to text/Markdown.

  3. LangGraph Router dispatches to the appropriate Phase Agent(s), loading stage-specific skill + checklist.

  4. Phase Agent queries KB (phase-specific collections) and applies Skills; Policy+Evidence run in parallel, then Drafter+Reviewer.

  5. LLM (via LangChain) produces structured findings with cross-phase traceability.

  6. 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.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:

{
  "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

  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.


Quick Start

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

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 8000

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.example

Configuration

Variable

Description

Default

LLM_PROVIDER

ollama or openai

ollama

OLLAMA_BASE_URL / OLLAMA_MODEL

Local LLM

http://localhost:11434 / llama2

OPENAI_API_KEY / OPENAI_MODEL

OpenAI

--

CHROMA_PERSIST_DIR

Vector DB path

./data/chroma

PARSER_ENGINE

Parser: auto, docling, or legacy

auto

ENABLE_GRAPH_RAG

Enable LightRAG graph retrieval

true

LANGGRAPH_CHECKPOINT_DIR

LangGraph checkpoint persistence

./data/checkpoints

SSDLC_DEFAULT_PHASES

Default phases for full assessment

requirements,design,development,testing,deployment,operations

SSDLC_DEFAULT_STAGE

Default SSDLC stage if not specified

auto

UPLOAD_MAX_FILE_SIZE_MB / UPLOAD_MAX_FILES

Upload limits

50 / 10

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

chmod +x test_integration.sh
./test_integration.sh

Option B: Manual

pip install -r requirements-dev.txt
pytest
pytest tests/test_skills_api.py   # Run specific test

Contributing

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

Star History Chart


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 tools
assess_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).

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYes
scenario_idNodefault

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.9/5.0
Behavior2/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYes
top_kNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.1/5.0
Behavior2/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

  1. 2 tool updatesv0.2.0
    • First observedassess_document
    • First observedquery_knowledge_base

TDQS

B3.1/5.0

Scored across 2 tools

Disambiguation5/5

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.

Naming Consistency5/5

Both tools follow a consistent verb_noun naming pattern (assess_document, query_knowledge_base). The naming is predictable and readable across the set.

Tool Count2/5

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.

Completeness2/5

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

ActivityActive
ResponsivenessSlow

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    MCP server enabling AI assistants to interact with the Qualys vulnerability management platform. Supports investigation, risk assessment, compliance, remediation, security overview, and report management.
    10 npm
    2
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    Model-agnostic cybersecurity MCP server for CMMC 2.0 compliance workflows with air-gapped Ollama mode.
    MIT
  • A
    license
    C
    quality
    C
    maintenance
    AI-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.
    31
    MIT
  • F
    license
    Not graded
    quality
    C
    maintenance
    A production-style MCP server providing AI models with cybersecurity tools including port scanning, WHOIS, DNS, threat intelligence, CVE lookup, and more.
    -