Agent Swarm Architecture

Cerberus is not a single monolithic scanner. Its 59-check native catalog is organized into nine weighted agent domains. The CLI adds a separately scored ALIGNMENT agent plus external feeder evidence without changing those native weights.

How an examination runs

The web app and CLI share the native pipeline driven by checks.json. After native evaluation, the CLI can inspect agent-policy surfaces and orchestrate selected external tools:

1

Resolve

Parse the target (GitHub URL or local path), resolve the default branch/SHA, and fetch the file tree.

2

Fetch

Download eligible files (≤2,000 files, ≤2 MB each) via the GitHub raw CDN, respecting global_exclude and test_paths.

3

Evaluate

Every check in every agent runs over the fetched files, resolving to pass, fail, not_applicable, or skipped.

4

Score & orchestrate

Native agent scores sum to 100. CLI ALIGNMENT and feeder results remain separate and feed a combined policy result.

Because a single file can trip checks from more than one agent (for example, a route file can trigger both a SENTINEL injection check and a GATEKEEPER auth check), a finding is attributed to whichever specific check matched — there is no cross-agent deduplication step to reason about; each check is independent and always reports its own state.

What Cerberus does not do

Native catalog agents and ALIGNMENT execute no repository code. Optional feeders are separate, allowlisted executables run with argv-only subprocesses, bounded output, timeouts, filtered inputs, and no automatic installation. They expand coverage but also expand the trust boundary.

ALIGNMENT — Repository & Agent Policy

Separate score 17 rule categories

ALIGNMENT inspects agent instructions, contribution/security guidance, package scripts, Makefiles and Justfiles, setup scripts, and GitHub Actions. It detects conflicting or destructive directions, disabled validation, secret exposure, remote-script execution, unsafe trust of repository/web content, hidden directives, prompt-injection-like overrides, missing guidance, project-command mismatches, broad workflow permissions, unpinned actions, and untrusted workflow interpolation.

ALIGNMENT findings include severity, location, explanation, remediation, confidence, category, and a stable fingerprint. Its score and grade never alter the native 100 points.

SENTINEL — Code Analysis

Code Analysis 11 checks · weight 14

SENTINEL is the first line of defense against classic application vulnerabilities. It performs static analysis over source files, looking for unsafe execution paths, weak cryptography, and improper handling of untrusted input.

Checks S-01 → S-10, plus S-06P

Example finding: a hardcoded API key assigned directly in source triggers S-01 with a CRITICAL severity.

Full detail — detector patterns, CWE, risk, and remediation — for every SENTINEL check is on the Check Catalog.

GATEKEEPER — Access Control

Access Control 6 checks · weight 12

GATEKEEPER audits what controls who can access the application and what they can do once inside.

Checks G-01 → G-06

Example finding: a JWT decoder configured with verify_signature: False triggers G-01 with a CRITICAL severity.

Full detail for every GATEKEEPER check is on the Check Catalog.

VAULT — Data Security

Data Security 8 checks · weight 13

VAULT protects data at rest: hashing, cipher choices, and anything sensitive that ends up committed or logged.

Checks V-01 → V-08

Example finding: hashlib.md5 used for a password triggers V-01 with a HIGH severity.

Full detail for every VAULT check is on the Check Catalog.

CONDUIT — Network & API

Network & API 5 checks · weight 11

CONDUIT inspects the network boundary: CORS, TLS verification, and services bound to all interfaces.

Checks C-01 → C-05

Example finding: Access-Control-Allow-Origin: * triggers C-01 with a HIGH severity.

Full detail for every CONDUIT check is on the Check Catalog.

WATCHTOWER — Application Config

Application Config 8 checks · weight 11

WATCHTOWER scans Dockerfiles, CI workflows, and repository-level configuration for dangerous defaults.

Checks W-01 → W-08

Example finding: a Dockerfile with no non-root USER instruction triggers W-02 with a HIGH severity.

Full detail for every WATCHTOWER check is on the Check Catalog.

LIBRARIAN — Dependencies

Dependencies 6 checks · weight 12

LIBRARIAN audits manifests and CI workflows for supply-chain risk. Vulnerable-version matching is a static regex against known bad version ranges committed in checks.json — it is not a live CVE database lookup.

Checks L-01 → L-06

Example finding: a manifest pinning a known-vulnerable lodash version triggers L-02 with a HIGH severity.

Full detail for every LIBRARIAN check is on the Check Catalog.

SHIELD — Client Security

Client Security 6 checks · weight 11

SHIELD audits the client-side attack surface: DOM sinks, token storage, and cross-window messaging.

Checks F-01 → F-06

Example finding: localStorage.setItem("token", ...) triggers F-01 with a HIGH severity.

Full detail for every SHIELD check is on the Check Catalog.

AUDITOR — Logging & Monitoring

Logging & Monitoring 4 checks · weight 8

AUDITOR checks what ends up in logs and error responses, and whether CI exists at all.

Checks A-01 → A-04

Example finding: a logger call including a password field triggers A-01 with a HIGH severity.

Full detail for every AUDITOR check is on the Check Catalog.

ARCHITECT — Infrastructure

Infrastructure 5 checks · weight 8

ARCHITECT looks at infrastructure-as-code and repository-level structural hygiene.

Checks R-01 → R-05

Example finding: a hardcoded IPv4 address in source triggers R-01 with a MEDIUM severity.

Full detail for every ARCHITECT check is on the Check Catalog.

Why organize checks into agents instead of one flat list?

A single static-analysis tool is optimized for one thing: pattern matching. Grouping checks by domain gives Cerberus structure. Doing this lets us:

Next step

See the exact checks each agent runs in the Check Catalog reference.