Prancer Blog / SSE Evidence Gap
Inside Exploit-Validated SSE Assessment: 18 Agents, 47 SKUs, One Report
How SwarmHack produces exploit-validated SSE evidence: 18 specialized agents, a 47-entry Cisco capability map, default-deny safety gates, and an 8-section upsell-validated report — proven on a 200-second lab run.
Prancer Research · 2026-05-26 · 12 min
TL;DR
- The swarm model — why coordinated multi-agent beats single-purpose scanners for SSE assessment.
- 18 specialized SSE agents sharing findings through a typed intelligence bus, orchestrated by a Goal-Oriented Action Planner.
- The 47-entry Cisco capability map that turns a finding into a named, prioritized SKU recommendation.
- Safety architecture — signed authz-docs, per-call scope checks, three destructive-attack gates, TLS verification on by default.
- The 8-section upsell-validated report — the actual artifact an SE hands a CISO.
- A real lab run: 200 seconds, 11 findings, 18 crown jewels, 5 distinct Cisco SKUs surfaced.
SSE Evidence Gap series
- ← Part 1 — The SSE Evidence Gap
- Part 2 — Inside the Platform (you are here)
Part 1 named the gap. This part is the technical-credibility part. A security architect evaluating SwarmHack will want to know three things:
1. Can it actually exercise an SSE control surface at depth? 2. Is it safe to run in a production environment? 3. Does the output actually map to a control SKU in a way an SE can act on?
This post answers each, grounded in the actual platform.
The swarm model — why coordinated multi-agent, not a single scanner
A traditional vulnerability scanner is built around one primary capability — port discovery, web crawling, vulnerability fingerprinting — executed against a target. The architecture is correct for what it does and structurally wrong for SSE assessment.
SSE is a *cross-capability* surface:
- ZTNA failure is interesting only when paired with the identity context that should have prevented it.
- SWG file-inspection bypass is interesting only when combined with the URL-category policy that delivered the file.
- DLP egress is interesting only when paired with the channel — multipart form, JSON API, raw POST — through which the egress flowed.
A single-purpose scanner can probe each axis. It cannot correlate them, and the correlation is where the evidence lives.
SwarmHack solves this with a swarm of specialized agents sharing findings through a typed intelligence bus:
┌─────────────────────────────────────┐
│ Typed Intelligence Bus │
└──────────┬──────────────────────────┘
│ shared findings, no shared state
┌──────────┬───────┴───────┬──────────┬──────────┐
sse_ztna sse_swg sse_dlp sse_casb sse_genai
│ │ │ │ │
▼ ▼ ▼ ▼ ▼
bypass EICAR / URL PII / PCI tenant LLM prompt
path categories exfil paths gating exfilWhen the auth-bypass agent confirms a session-token leak, the SQLi agent inherits the session and tests post-authentication endpoints. When SQLi extracts a credential, the DLP agent uses that credential to test the egress channel that would carry it out. The chain of inference is the evidence.
The orchestration is a Goal-Oriented Action Planner (GOAP) using A* search over a typed action library. Recent engineering work moved a failing 3-goal kill-chain test from 14 hours to 0.19 seconds — a 17,100× speedup. The relevant fact: the planner reliably terminates and the swarm reliably finishes.
The 18 SSE agents
Eighteen specialized agents constitute the SSE family in the current release. The first 16 are probe agents; the last two synthesize.
| Agent | What it probes | Primary Cisco SKU it informs |
| --- | --- | --- |
| sse_ztna | ZTNA bypass — anonymous reach, origin reachability, IdP group binding | Cisco Secure Access — Private Application Access |
| sse_identity | MFA / step-up enforcement, session-revocation latency | Cisco Duo + Secure Access — Identity-Aware Policy |
| sse_device_posture | Posture-asserting header / cert / managed-device gates | Cisco Secure Client + Posture Profiles |
| sse_traffic_steering | Egress bypass — no_proxy, alternate resolvers, direct egress | Cisco Secure Access — App Connector + DNS Sinkhole |
| sse_dns | DNS blocklist, tunneling / C2 beacon detection | Cisco Umbrella DNS Security |
| sse_swg | URL category bypass, EICAR / AMP file-inspection, vendor block-page fingerprinting | Cisco Secure Access SWG — URL Categories + File Inspection |
| sse_casb | Sanctioned / unsanctioned SaaS reach, corp-vs-personal tenant gating | Cisco Secure Access CASB — SaaS Inventory + Tenant Restrictions |
| sse_dlp | PII / PCI / PHI / secrets exfiltration across multipart, form, JSON, raw channels | Cisco Secure Access — Inline DLP |
| sse_fwaas | L4 + L7 outbound policy and application-aware control bypass | Cisco Secure Access FWaaS — Outbound Policy + App Control |
| sse_rbi | Native-render-vs-isolated on high-risk URL classes | Cisco Secure Access RBI |
| sse_genai | LLM prompt-as-exfiltration testing across public AI frontends | Cisco Secure Access — GenAI Policy + Inline DLP for GenAI |
| sse_policy_assurance | Cross-capability policy conflict, stale-exception detection | Cisco Secure Access — Unified Policy Engine |
| sse_observability | Log-correlation latency, IR chain assembly | Cisco Secure Access — Activity Search + SIEM Forwarding |
| sse_shadow_asset | OSINT-discovered assets outside the SSE perimeter (CT logs, passive DNS, RDAP) | Cisco SSE expansion candidate — asset onboarding |
| sse_c2 | Simulated DNS + HTTPS + TCP C2 beacons against operator-owned callback FQDNs | Cisco Secure Access — Multi-Control C2 Correlation |
| sse_scorecard | Per-domain scoring, capability mapping, executive narrative synthesis | Scorecard self-summary |
Two further agents — an SWG vendor block-page fingerprint matcher and a continuous-assurance drift detector — round out the family.
Each finding is keyed by a typed VulnerabilityCategory::Sse(String) variant so the SSE token (e.g. SSE.sse_swg_002) propagates cleanly through the OCSF emitter and the report renderer.
The Cisco capability map
The capability map turns a finding into an SE-actionable recommendation. It is a YAML file with 47 entries: 33 SSE scenarios plus 14 legacy CWE → Cisco SKU mappings so that confirmed SQLi, XSS, or command-injection findings from the broader exploit family also surface the right Cisco SKU.
Each entry carries five fields, the most important of which is capability_kind:
| capability_kind | Meaning | Engagement motion |
| --- | --- | --- |
| deployed-misconfigured | Customer owns the SKU and has it deployed; policy is wrong | Policy tightening; no procurement |
| licensed-not-enabled | Customer licenses the capability; the toggle is off | Toggle on; fast close, no procurement |
| not-licensed | Customer does not own the SKU | Net-new SKU expansion; budget item |
| feature-gap | A specific WAF / DLP / RBI feature would close this | Feature add-on or upsell |
| expansion-candidate | OSINT-surfaced asset outside the SSE perimeter | Onboarding play |
A five-line excerpt makes the structure concrete:
- category: "SSE.sse_swg_002"
cisco_capability: "Cisco Secure Access SWG — File Inspection (EICAR / AMP)"
capability_kind: licensed-not-enabled
license_tier: add-on
remediation_short: "Enable inline file inspection (EICAR/AMP) on SWG."The map is updatable by an SE during a POV. Adding a new entry, changing a SKU's marketing name, or refining a remediation requires a one-line YAML edit and a re-run of the renderer — no agent rebuild, no platform recompile.
The Cisco SE owns the marketing copy. The SwarmHack engineering team owns the detection.
The safety architecture
This is the surface a customer's CISO and legal counsel will read twice. SwarmHack is designed so the default behavior is safe and unsafe behavior requires explicit, named opt-in.
1. Per-engagement signed authorization. Every run requires an --authz-doc: a JSON document with in-scope hostnames, a 24-hour expiry, the authorized tester's identity, and a contract reference. SwarmHack refuses to run without it. Drift between the CLI target and the authz scope is a fatal error.
2. Runtime per-agent scope check. 61 networking-capable agents enforce the authorization scope at every cross-origin probe through AgentContext::is_host_in_scope. Strict label-boundary matching closes the classic *.acme.com over-match against dev.acme.com.evil.com.
3. Three destructive-attack gates. ZeroLogon (CVE-2020-1472), NTLM relay, and blast-radius classification (recon / exploit / destructive) are all default-deny. Destructive payloads (e.g. DROP TABLE-class SQLi) are filtered at the payload gate.
4. TLS verification on by default. Both pre-flight reachability and recon banner-fetch verify TLS by default. Env-var opt-ins exist only for lab self-signed certs.
5. OCSF 1.1.0 strict evidence. All findings emit as OCSF 1.1.0 class_uid=2001 (Vulnerability Finding) records with a strict validator. Crown jewels carry a SHA-256 fingerprint of the artifact, not a screenshot.
The default-deny posture on destructive gates and the runtime scope check are the controls that make SwarmHack safe to run repeatedly against a production environment. A platform without these properties should not be pointed at a customer's live network, regardless of marketing copy.
The architecture in one diagram
┌────────────────────┐ ┌────────────────────┐
│ Operator + signed │ ───► │ SwarmHack │
│ authz-doc (24h) │ │ Orchestrator │
└────────────────────┘ └─────────┬──────────┘
│
▼
┌─────────────────────────┐
│ 18 SSE agents + web/AD │
│ agents · 64-slot pool │
└─────────┬───────────────┘
│ findings
▼
┌─────────────────────────┐
│ Typed Intelligence Bus │
└─────────┬───────────────┘
│
▼
┌─────────────────────────┐
│ Cisco capability map │
│ 47 entries (YAML) │
└─────────┬───────────────┘
│
▼
┌────────────────────────────────────┐
│ OCSF 1.1.0 JSON │
│ + HTML attack-path graph │
│ + Upsell-validated Markdown report │
└────────────────┬───────────────────┘
│
▼
Customer + SE countersignedThe output: the upsell-validated report
The report is an 8-section customer-facing Markdown artifact. It is not a tool dump and it is not the OCSF JSON. It is the document an SE hands to a customer in a QBR and the document a CISO forwards to their CFO.
The eight sections are fixed:
1. Executive summary — total exploit paths, successes by severity, blocked exploits ("Cisco wins"), info findings, SKU upsell opportunities surfaced. 2. Successful exploit paths — grouped by capability_kind. Each finding carries severity, evidence pointer, crown-jewel summary, the Cisco capability that would have prevented it, and the upsell one-liner. 3. Blocked exploit paths — the "Cisco wins" column. Categories with active coverage and zero findings. 4. Missing controls — not-licensed capabilities with gap and scope estimate. 5. License / feature mapping — the SKU table. One row per SKU, sorted P0 → P2. 6. Evidence appendix — relative pointers to the OCSF JSON, HTML attack-path, and DOT graph. 7. Prioritized upsell plan — a checklist of P0 / P1 / P2 actions, ready to drop into the customer's next QBR. 8. Authorization footer — authz-doc path, engagement window, authorized tester, countersignature lines.
A real excerpt from a recently-recorded lab run:
### 2.2 Licensed but not enabled
#### SWG AV miss: EICAR test signature downloaded successfully
via https://malware.wicar.org/data/eicar.com
- Severity: **[CRITICAL]**
- What worked: GET returned a body matching the canonical EICAR test
signature (sha256=131f95c51cc...). Any production AV engine must
detect this string; the SWG did not.
- Cisco capability that would have prevented this:
**Cisco Secure Access SWG — File Inspection (EICAR / AMP)**
(`licensed-not-enabled`, tier `add-on`)
- Upsell pitch: File inspection ships with the SWG add-on but is
toggled off. Closes the malicious-download ingress path.The before/after comparator
The renewal-cadence motion needs a different artifact: a delta against where the customer was, not a snapshot of where they are.
swarmhack scorecard \
--before reports/mission-pre.json \
--after reports/mission-post.json \
--report sse-delta \
--output reports/upsell-delta.md \
--features-toggled "DLP profile enabled; posture checking ON"The comparator runs entirely offline (no network, no portal call) and produces a Markdown report keyed by a 3-way classification:
| Classification | Meaning | Renewal narrative |
| --- | --- | --- |
| CLOSED | Finding present in *before*, absent in *after* | "Cisco's [SKU] closed this since the last run" |
| UNCHANGED | Finding present in both | "Still open — and here is the SKU that closes it" |
| REGRESSED | Finding absent in *before*, present in *after* | "New gap surfaced; immediate action" |
Twelve monthly deltas with four CLOSED findings per month is a fundamentally different conversation than a renewal with no comparative evidence at all.
What we measured on a real lab run
Numbers from a single mid-2026 lab run on the SSE validation lab:
| Metric | Value |
| --- | --- |
| Wall-clock | ~200 seconds |
| SSE agents in parallel | 6 |
| SWG probes (URL categories + EICAR samples) | 32 |
| Findings | 11 (3 Critical, 6 High, 2 Info) |
| Crown jewels | 18 |
| Distinct Cisco SKUs surfaced | 5 (3 P0, 2 P2) |
The published §5 SKU table lists two P0 rows (SWG — File Inspection, SWG — URL Categories + User Overrides) and three P2 rows (RBI, Dedicated Egress Pool, GenAI Policy + Inline DLP for GenAI). The resulting upsell-validated Markdown is roughly four printed pages — small enough to read in five minutes, large enough to drive a real QBR.
The Cisco SE who runs the same lab again *with file inspection enabled* would see the three Critical EICAR findings move from §2 (successful exploits) to §3 (Cisco wins). That is the renewal conversation: not a marketing slide, but a delta the customer can audit.
The lab in the CI pipeline
The numbers above did not come from a customer environment. They came from a controlled Cisco-SSE-compatible lab that ships with the platform at lab/sse-lab/, brought up with a single docker compose up -d.
The lab is the engineering testbed, the regression harness, and the demo environment — three jobs in one Docker network:
- 13 containerized services mapped to the 8 SSE pillars
- Keycloak OIDC realm with HR, Finance, Engineering, Contractor identities (
alice,bob,contractor1,admin1) - NGINX ZTNA front gating three private apps + a deliberately leaky origin so
sse_ztnavalidates both paths - CASB surface — corp-drive, personal-drive, chat-ai, shadow-saas
- Flask DLP filter, Squid SWG, CoreDNS, mitmproxy TLS interception, OpenSearch sink
The harness tests/sse_lab_validation.rs drives every SSE agent against the lab — 14 #[tokio::test] cases, one per agent. Any drift in agent behavior, capability-map mapping, OCSF emission, or report rendering shows up as a failed lab test before the change ships.
The lab is the regression line under the SSE family. The same lab a Cisco SE can stand up locally — no authz-doc paperwork, no production blast risk, fully reproducible — is the safe demo environment before scoping a real engagement.
The agent works in the lab. The control works (or doesn't) in production. Decoupling those two questions is the single most important design property of the platform.
Want to see your own report?
A standard 2-week POV requires 1–3 days of operator time on the Prancer side plus an equivalent block of SE time on the partner side. The output is one upsell-validated report identifying 4–6 SKU expansion opportunities, each linked to named findings.
The methodology is vendor-neutral on detection and vendor-specific on recommendation. Netskope, Zscaler, Palo Alto Prisma Access, Forcepoint, and Symantec/Broadcom CloudSOC deployments are equally valid targets — the capability map is the swappable layer.
→ Email [email protected] or book a discovery call.
Catch up: Part 1 — The SSE Evidence Gap: Why Your Security Service Edge May Be Silently Failing