DocSentinel

Purpose

DocSentinel is an AI-driven SSDLC (Secure Software Development Lifecycle) platform for security teams. It automates security activities across all six phases of the software development lifecycle, carried out by intelligent AI agents orchestrated by LangGraph and powered by LangChain. It automatically reviews security-related documents, forms, and reports—from requirements, design, development, testing, deployment, and operations—compares inputs against your policies and knowledge base, and generates structured assessment reports containing risks, compliance gaps, and remediation recommendations.

It does not just review documents in the pre-release phase; it embeds security from day one.

Key Capabilities

Full SSDLC Lifecycle Coverage

Six dedicated AI agents, each with phase-specific skills, prompts, and knowledge base collections. You can run a single phase or a complete 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, penetration testing assessment.
• Deployment: release readiness, configuration security, hardening.
• Operations: incident response, vulnerability monitoring, log auditing.

Automated Security Assessment

Submit security questionnaires, design documents, or audit reports, and DocSentinel uses the configured LLM to analyze and identify:

• Security risks: classified by severity (critical, high, medium, low).
• Compliance gaps: missing controls against frameworks such as ISO 27001, PCI DSS, etc.
• Remediation steps: actionable recommendations to fix identified issues.

Governance and Compliance Workflows

PallasGuard governance capabilities have been merged into DocSentinel as first-class project workflows:

• Policy packs: generic-ssdlc plus eight public overlays, corresponding to 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 processes, supported by SQLModel and Alembic migrations.
• Control generation: framework overlays generate applicable SCD controls and expected evidence, without replacing DocSentinthe existing assessment engine.
• Pallas Lens: project readiness scoring that aggregates control coverage, evidence depth, and follow-up actions in the React governance portal.

Agent Orchestration (LangGraph)

• Structured workflow: LangGraph nodes separate context collection, drafting, evidence review, schema transformation, and governance persistence.
• Cross-stage traceability: threats from the design stage link to test cases from the testing stage and monitoring rules from the operations stage.
• Conditional routing: agents activate based on project risk level, compliance requirements, or user selection.
• Human in the loop: assessments created by agents enter a review queue and cannot approve themselves.
• Planned hardening: explicit planning gates, persistent LangGraph checkpoints, and resumable execution are tracked in the development roadmap.

Threat Evidence Review (Threat Evidence Critic)

STRIDE threats from the design stage are checked independently against the currently uploaded architecture document in a single reasoning process:

• Each threat receives a supported, contradicted, or insufficient_evidence verdict, with a support score and reviewer-facing rationale.
• Evidence citations use content hashes plus stable line locators and include the exact source excerpt shown in the assessment workbench.
• Only passages from the current project document are accepted. Fabricated, missing, policy, or historical references cannot make a threat appear supported.
• Validation failures fail safe to insufficient_evidence; all verdicts still require human review.
• No training or fine-tuning pipeline is required. The reviewer uses configured OpenAI, Anthropic, Qwen, DeepSeek, compatible, or local runtime models.

RAG Knowledge Base

Upload the organization's security policies, standards, and past audits. Stage-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

API-first, with MCP and A2A support

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

Reproducible Evaluation Tooling

DocSentinel includes evals/ tooling to measure assessment quality against public and future golden datasets without going through HTTP or the UI. The first implementation path covers OWASP Benchmark v1.2 SAST triage:

• Dataset hygiene: raw benchmark data is fetched locally into an ignored path; only the fetch script, checksums, manifest, and a 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 remaining self-contained.
• Hard-key scoring: M1 scores CWE-based binary triage with accuracy, precision, recall, F1, and false positive rate, with no LLM judging.
• Threat-grounded scoring: the evidence review scorer measures verdict accuracy, support precision/recall/F1, contradiction recall, abstention rate, citation validity, and a full verdict confusion matrix.
• Scorecards: each run writes a machine-readable scorecard.json and a human-readable scorecard.md under evals/reports/<run_id>/.

Usage

DocSentinel is a React console + FastAPI application with three governed entry paths: a REST API for the console and CI, MCP tools for coding agents, and A2A JSON-RPC for remote agent delegation. These entry points converge on the same AssessmentService, LangGraph assessment pipeline, knowledge base, and human review lifecycle.

The local React console centralizes the main workflows into a single operational interface:

• Command center: real-time API and LLM status, assessment throughput, review needs, remediation queue, and recent activity.
• Assessment workbench: upload project documents, select 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 standardsUsed for RAG-supported review.
• Agent integration: 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 a masked preview is displayed.

Data flow (simplified): security personnel work in the React console; the REST client calls /api/v1/*; coding agents call MCP or A2A through the agent gateway. 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. Assessment submissions enter AssessmentService, create an asynchronous task, parse uploaded or approved local documents, apply guardrails, and invoke the LangGraph assessment pipeline. The LangGraph pipeline loads the selected skill, wraps untrusted document content as data, retrieves policy/history/evidence context from the KB, requests draft/review text from the LLM, and converts the result into a structured assessment schema. Deterministic services remain authoritative for governance decisions: policy package schema, the S2O rules engine, control applicability, and schema validation cross-check LLM output before it enters the review queue. When an assessment is linked to a project, findings are persisted as Gate 3 control evidence. The governance workflow then uses the same SQLModel storage to handle projects, controls, submissions, audit logs, Pallas Lens scoring, and exports. The KB persists chunks in Chroma, optional graph artifacts in LightRAG, and retains prior assessment history for reuse. Runtime LLM settings are loaded from .env plus llm_config.json, and each provider base URL is checked by network guardrails before the client is built.

Applicable Scenarios

Suitable for enterprises that need to scale security assessments across multiple projects and SSDLC stages without proportionally increasing manpower. It can be integrated into local security review workflows, CI/CD pipelines, AI agents, and multi-agent platforms without granting external agents approval authority.

Limitations

• Assessments created by agents enter the review queue and cannot approve themselves; all determinations still require human review.
• External agents do not receive approval authority.
• Threat evidence review only accepts paragraphs from current project documents; fabricated, missing, policy, or historical references cannot make a threat appear supported.
• Validation failures safely abstain as insufficient_evidence.
• Some capabilities (such as explicit plan gates, persistent LangGraph checkpoints, and resumable execution) are marked as planned work in the development roadmap and are not yet implemented.
• Specific information such as fees, pricing, and platform support scope is not yet provided in the materials.