Sentinel Methodology

How Matproof Sentinel runs penetration tests — the agents, the tools, what we test, what we don’t claim, and how findings map to compliance frameworks.

What Sentinel is

Matproof Sentinel is an AI-orchestrated penetration testing engine built in-house. Each scan is driven by ten specialised agents that coordinate to enumerate, probe, and validate a target’s attack surface — then ship a structured report with findings mapped to your active compliance frameworks (DORA, NIS2, ISO 27001, SOC 2, PCI DSS, HIPAA, NEN 7510).

This page is the technical methodology reference. If you need the customer-facing workflow guide instead — how to create scans, view reports, mark findings remediated — see Penetration Tests.

The agents

A scan runs ten agents in five staged groups. Each agent has a narrow remit, its own toolchain, and writes structured findings to a shared store. The orchestrator coordinates dependencies between them.

Stage 1 · ReconAgent

Goal: Map the target’s attack surface.

Tools: nmap (port scan + service detection), subfinder (passive DNS subdomain enumeration), amass intel (OSINT — ASNs, netblocks, related domains), dnsx (DNS resolution), httpx (HTTP probing, technology fingerprinting, TLS, headers).

Emits: open ports, live subdomains, server versions, exposed paths, weak TLS configurations, missing security headers.

Stage 2 · InfraAgent

Goal: Test TLS, DNS security, and infrastructure hygiene at depth.

Tools: testssl.sh (TLS deep audit), nmap with NSE scripts, DNS-security probes (SPF, DKIM, DMARC, CAA, DNSSEC), cloud bucket probes (S3 / GCS / Azure unintended-public-access checks).

Emits: weak ciphers, expired/misconfigured certs, missing email-auth records, exposed buckets, missing DNS security records.

Stage 2 · WebAppAgent

Goal: Black-box web application testing against discovered HTTP surface.

Tools: nuclei (CVE templates + exposure templates), sqlmap (SQL injection), ffuf (directory/file fuzzing), jwt_tool (JWT analysis), raw HTTP probes.

Emits: known CVEs on detected stacks, SQLi, exposed admin paths, insecure JWT validation, sensitive file exposure.

Stage 2 · BrowserAgent (DAST)

Goal: Catch JS-rendered vulnerabilities the HTTP-only agents miss.

Tools: OWASP ZAP daemon — AJAX Spider (Selenium-driven JS rendering) + traditional spider + active scan, DOM XSS detection.

Emits: DOM-based XSS, client-side prototype pollution, JS-rendered authentication issues.

Stage 2 · CloudAgent (opt-in)

Goal: Audit your cloud account configuration when you provide a read-only STS role.

Tools: prowler (AWS-focused, ~300 controls covering CIS / NIST / PCI).

Emits: IAM misconfigurations, exposed storage, missing CloudTrail / encryption, untagged production resources.

Opt-in: disabled by default. Activate by passing cloud_audit config at scan creation.

Stage 2 · MobileAgent (opt-in)

Goal: Static analysis of mobile binaries (iOS .ipa, Android .apk).

Tools: MobSF (Mobile Security Framework).

Emits: hardcoded secrets, insecure cryptography, weak SSL pinning, exposed components, insecure data storage.

Opt-in: disabled by default. Provide a mobile_binary_path to enable.

Stage 3 · ApiAgent

Goal: Property-based API fuzzing on discovered OpenAPI / GraphQL surfaces.

Tools: OpenAPI auto-discovery, Schemathesis property-based fuzzing.

Emits: broken object-level authorization (BOLA), broken function-level authorization (BFLA), mass assignment, schema-violation responses.

Dependency: runs after WebAppAgent so endpoint discovery is complete.

Stage 3 · SourceCodeAgent (opt-in)

Goal: Static analysis of your source code when you connect a repo.

Tools: semgrep (SAST across 1000+ rules covering OWASP Top 10, language-specific patterns), gitleaks (committed-secret scanning including git history), pattern grep for custom rules.

Emits: code-level vulnerabilities (SQLi, XSS, command injection), secrets in code, historical secret commits, unsafe deserialisation, insecure cryptography use.

Opt-in: triggered by providing repoUrl at scan creation. Authentication via either the Matproof GitHub App (recommended), OAuth, or a Personal Access Token.

Stage 4 · SupplyChainAgent (opt-in)

Goal: Vulnerability surface from dependencies, containers, and IaC.

Tools: trivy (npm/pip/maven/etc CVE scan + container image CVE scan + IaC misconfiguration scan + secret scan).

Emits: vulnerable dependencies (with CVE + CVSS + remediation paths), exposed secrets in IaC, container CVEs, Terraform/Helm/Dockerfile misconfigurations.

Dependency: reuses the SourceCodeAgent’s clone — same opt-in gate.

Stage 5 · ValidatorAgent

Goal: Confirm or reject findings by reproducing them.

For each non-INFO finding from earlier agents, the ValidatorAgent re-probes the target with a targeted reproduction attempt, then attaches one of:

• VALIDATED — confirmed exploitable with PoC evidence
• UNVERIFIED — could not reproduce in available time, finding still ships
• FALSE_POSITIVE — verified non-issue and demoted in the report

Validated findings ship with concrete PoC payloads, request/response pairs, and step-by-step reproduction details. Unverified findings stay visible because absence of a successful reproduction is not absence of vulnerability — it’s signal you can investigate manually.

What we test

Layer	Agents	Surface
Reconnaissance	Recon	Subdomains, ports, TLS, headers, technology fingerprinting
Network/Infra	Infra	TLS depth, DNS security, cloud bucket probes
HTTP application	WebApp + Browser	OWASP Top 10 patterns, CVE templates, DOM XSS
API	Api	OpenAPI / GraphQL fuzzing, BOLA / BFLA
Source code	SourceCode + SupplyChain	SAST + secrets + dependencies + IaC + containers
Cloud (opt-in)	Cloud	AWS configuration audit via Prowler
Mobile (opt-in)	Mobile	Static analysis of .ipa / .apk binaries
Validation	Validator	Exploit reproduction for every non-INFO finding

What we don’t claim

A penetration test that’s worth its compliance evidence is honest about its limits. Sentinel makes the following explicit non-claims:

• No social-engineering testing. Phishing, vishing, physical access. If your framework requires red-team SE assessment (TLPT under DORA Article 26 for significant entities), you still need a human red team for that workstream.
• No destructive testing. Sentinel does not run payloads that modify data, drop tables, escalate privileges with write side-effects, or trigger DoS conditions. Validated findings stop at the boundary of demonstrating exploitability.
• No zero-day discovery. Sentinel finds known-vulnerability classes (CVEs, OWASP patterns, misconfigurations). Discovering novel zero-days requires human exploit research and is out of scope.
• No human verification. Findings are produced by AI agents and validated by an AI agent. We mark validated findings as such, but we do not employ a human pentester to manually re-confirm every result before report delivery. For evidence-quality requirements beyond what Sentinel produces, engage a human firm.
• No business-logic discovery beyond template patterns. Sentinel catches business-logic issues that match well-known patterns (BOLA, mass assignment, BFLA), but it does not deeply reason about your domain’s specific business rules.

Compliance framework coverage

Every finding Sentinel emits is automatically tagged with references to the compliance controls it satisfies. This is the mapping per finding category, used by the matproof platform to populate evidence rows on the relevant framework requirements.

Framework	Article / Control	Sentinel coverage
DORA	Art. 24-27 — Digital operational resilience testing	All scans satisfy basic DORA Art. 25 testing. TLPT (Art. 26) requires human red team for significant entities.
NIS2	Art. 21 — Risk-management measures, technical effectiveness	All scans
ISO 27001	A.8.8 Technical vulnerability management; A.8.29 Security testing; A.18.2.3 Technical compliance review	All scans
SOC 2	CC7.1 System monitoring & penetration testing	All scans
PCI DSS	Requirement 11.4 — annual penetration testing	All scans (with caveats — PCI scope requires segmentation testing also)
HIPAA	§164.308(a)(8) Periodic technical evaluation	All scans
BaFin MaRisk / BAIT	AT 7.2 Tz. 13 — Penetration testing of critical systems	All scans
NEN 7510	A.18.2.3 — Independent review of information security	All scans

The mapping logic is in apps/api/src/security-penetration-tests/control-mapping.ts if you want to inspect the per-finding rules.

Authentication & scoping

Target authorization. Sentinel will not scan a target until you’ve proven domain ownership via either DNS TXT or HTTP file challenge. This is a hard requirement enforced at scan creation; it protects both Matproof and customers from accidental scans of third-party infrastructure.

Authenticated scanning. Many real vulnerabilities only manifest behind login. You can pass session cookies or Bearer tokens at scan creation via the authHeaders field — Sentinel includes them on every HTTP probe so the agents can test post-login surface (IDOR, privesc, mass assignment).

Multi-target scope. A single scan can include the primary target plus up to 50 additional target URLs. Useful when your domain hosts multiple apps (qa1/qa2/qa3/dev/api) and you want all of them in scope explicitly rather than relying on subdomain auto-pivot.

Source-code access. Three options in order of preference:

1. GitHub App (recommended): you install Matproof Sentinel on your GitHub org and choose exactly which repositories we can read. Works regardless of org-level third-party OAuth-app policies.
2. OAuth: simpler one-click flow, but blocked by orgs that restrict third-party OAuth apps.
3. Personal Access Token: paste a classic GitHub PAT with repo scope. Works for any user.

Data handling

• Scan inputs (target URLs, auth headers, repo URLs, configuration) are stored encrypted at rest on EU infrastructure.
• Findings are persisted in the Matproof database (EU region) and linked to your organization. We don’t share findings across tenants.
• Source code cloned during a scan is processed in a temporary workspace and deleted after the scan finishes. Source code is never persisted beyond the scan’s lifetime; only the resulting findings + line references remain.
• Reports (Markdown + PDF + SARIF) are retained for the lifetime of your account. You can delete a scan and its report at any time via the API; cascading deletes remove findings, agent error logs, and webhook delivery records.
• AI provider (Anthropic) sees the target URL, scan configuration, and tool outputs for the agent’s reasoning step. Anthropic does not retain customer data per our enterprise agreement.

Deliverables

Every completed scan produces:

• Markdown report with executive summary, per-severity findings, per-agent coverage, and remediation guidance per finding.
• PDF report suitable for compliance auditors.
• SARIF 2.1.0 export for ingestion into GitHub Advanced Security, GitLab, or Azure DevOps.
• Evidence rows linked to every relevant compliance requirement in your active frameworks — populated automatically via the per-finding control mapping.

Reproducibility

Scan inputs and outputs are deterministic with respect to the target’s state at the time of scanning. Re-running the same scan a week later will produce different findings if the target has changed (new code deployed, patches applied, new subdomains added) — which is what you want from a continuous-testing program.

The full agent execution log, including every tool invocation and its raw output, is retained server-side for audit. Available on request via the API; not shown in the customer-facing report to keep it readable.