Security Probe & Exploit Testing for Enterprise Cyber Risk. Built on the ZAK framework. Engineered by Sakshi Magre.
A blunt observation about VAPT
Penetration testing, as most enterprises practice it today, is a calendar event.
You scope it for a quarter. You wait for the engagement window. A team of skilled humans spends two to four weeks on the actual testing, plus another two writing the report. Compliance mapping happens in spreadsheets after that. By the time the deliverable lands, half the findings are stale and your attack surface has changed — new endpoints, new dependencies, new identities, new exposures.
Meanwhile, the people on the other side of this — the actual adversaries — aren’t running on your calendar. They run continuously. They’ve started running with AI assistance: automated reconnaissance, on-demand exploit generation, machine-speed enumeration. They don’t pause between engagements. They don’t bill by the hour. They don’t go on holiday.
The asymmetry isn’t a tooling problem. It isn’t a budget problem either. It’s an execution-velocity problem. And no amount of additional headcount fixes the math, because every analyst added produces more findings that need more analysts to triage. The curve diverges.
This is the gap SPECTER was built to close.
What SPECTER is
SPECTER — Security Probe & Exploit Testing for Enterprise Cyber Risk — is an agentic VAPT pipeline that runs a full enterprise-grade engagement in under three minutes per target, on a single command. It’s our first production deployment of an autonomous offensive-security agent on the ZAK (Zeron Agent Development Kit) framework.
The numbers, briefly:
- 8 phases, end-to-end, orchestrated as an intelligence chain.
- 17+ check modules, split between generic baseline checks and tech-aware checks that activate only when the target’s stack matches.
- 3 compliance frameworks (PCI-DSS v4.0, SOC2, ISO 27001:2022) auto-mapped to every finding.
- 3 output formats in a single run: an executive-ready PDF report, a SARIF 2.1.0 file for CI/CD integration, and a Jira-ready JSON payload for ticket auto-creation.
- Bounded autonomy with human-in-the-loop classification on every payload that could escalate.
What this means in practice: the same workflow that used to define a quarter now defines an afternoon. VAPT shifts from a calendar event to a baseline operational signal — as regular as vulnerability scanning, as deep as a manual engagement, as fast as your environment actually changes.
How the 8-phase pipeline works
SPECTER doesn’t run scans the way a traditional scanner does — which is to say, brute-forcing every check against every endpoint and hoping the noise is filtered out somewhere downstream. The agent is intelligence-driven. Early discoveries sharpen later decisions.
Phase 1 — Technology Profiling. Fingerprint the target’s stack via HTTP headers, body patterns, and cookie analysis. Identifies React, Angular, GraphQL, AWS, PHP, Java, Node.js, WordPress, and a dozen other technologies. The result is a profile that downstream phases use to activate the right tests and skip the irrelevant ones.
Phase 2 — WAF Detection. Probes for six major WAF families (Cloudflare, Akamai, AWS WAF, Imperva, F5 BigIP, ModSecurity). If detected, SPECTER switches to stealth throttling — three requests per second — so subsequent scans don’t trip rate limits or get the source blocked mid-engagement.
Phase 3 — Intelligence Crawling. Discovers real form actions, parameters, and endpoint structures. The DAST engine downstream runs against actually-discovered inputs, not guessed paths. This is the difference between a real engagement and a script throwing payloads at a wordlist.
Phase 4 — Surgical DAST. The 17 check modules execute here. Generic checks (SQLi, XSS, XXE, CORS, path traversal, header injection, DOM XSS sinks, vulnerable JS dependencies, etc.) run on every target. Tech-aware checks (Angular CSTI, prototype pollution, GraphQL introspection, Java deserialization, WordPress enumeration) activate only when the profiler matched the relevant stack. No wasted requests, no false positives from irrelevant tests.
Phase 5 — HITL Approval Gate. Every finding is classified GREEN, YELLOW, or RED. GREEN findings (low risk) are auto-approved and recorded. YELLOW findings (medium risk) trigger a Slack notification and wait for explicit human approval before escalation. RED findings (destructive exploits) are documented but never fired — they’re in the agent’s permanent denied_actions list. This is what we mean by bounded autonomy. Speed is non-negotiable. Governance is non-negotiable. SPECTER refuses the trade.
Phase 6 — Enterprise Report Generation. Three artefacts in one pass: a multi-page PDF (cover, executive summary, per-finding cards with evidence, compliance tables, legal disclaimer), a SARIF 2.1.0 JSON for GitHub Advanced Security / Azure DevOps integration, and a Jira-ready JSON payload with severity-mapped priorities and pre-filled fields for direct REST API import.
Phase 7 — Compliance Mapping. Every approved finding is automatically mapped to PCI-DSS v4.0, SOC2, and ISO 27001:2022 controls — a 22-entry compliance database keyed by CVE-ID with category fallback. Specific control references (e.g., PCI-DSS Req 6.2.4, SOC2 CC6.1, ISO A.14.2.5) and remediation notes attach to each finding. The result: audit-ready evidence as a byproduct of the same scan, with zero analyst hours required.
Phase 8 — Delta Engine. Compares the current run against the previous baseline. Surfaces new findings, confirms remediations, and persists posture trend data per tenant. This is what makes continuous VAPT meaningful — without delta tracking, every scan is a snapshot and nothing accumulates into a story you can tell a board.
The architecture that makes it safe
A reasonable question, especially from security leaders evaluating autonomous offensive tooling: how do we know it won’t do something destructive?
SPECTER runs on the ZAK framework, and ZAK’s separation-of-concerns design is what makes this answerable. Tool functions implement security logic with no framework dependency. The agent file wraps them with @zak_tool decorators that assign each tool a unique action_id. The agent’s YAML manifest declares exactly which action_id values are allowed and which are denied. ToolExecutor.call() enforces capability checks, evaluates policy, and emits structured audit events before and after every invocation.
The practical effect:
- The agent cannot self-modify its scope. Its capabilities and boundaries are declarative YAML, not hardcoded behavior. To change what SPECTER can do, you change the manifest — and that change is reviewable, version-controllable, and auditable.
- Every tool invocation is logged with full input/output context. No actions are invisible to the audit trail.
- Destructive payloads are permanently denied at the framework level.
denied_actions: [fire_red_payloads]isn’t a configuration option that can be flipped at runtime. It’s a hard boundary. - Multi-tenant by design. Every client engagement runs under its own
tenant_idwith isolated storage, delta baselines, and audit logs.
This is the part most “AI security agents” gloss over, and it’s why we built SPECTER on ZAK rather than on a general-purpose agent framework. Offensive security agents demand a different governance model than general-purpose ones. We wanted that model to be enforced in the framework, not in good intentions.
Who SPECTER is for
Three audiences will recognize themselves in this:
CISOs and security leaders at mid-market and enterprise companies who are watching their VAPT cycle stretch further than the threat clock allows. If your last engagement report is older than your last cloud deployment, SPECTER is the conversation worth having.
VAPT consultants and MSSPs whose human red teamers spend too much time on triage and not enough on the work only humans can do. SPECTER doesn’t replace your operators — it absorbs the work AI can do twice as fast so your operators move up the stack to threat hunting, incident command, and adversary research.
AI engineers and agent builders curious about what production agentic security tooling actually looks like — the framework, the policy enforcement, the bounded-autonomy primitives. SPECTER is the first published example. ZAK is the substrate. Both are open work we’re building in the open.
A note on who built this
SPECTER was engineered by Sakshi Magre on our team — an ethical hacker who took the agent from a sketch to a production-grade pipeline in a build cycle most companies would budget twice as long for. She named the agent. She picked the tagline. We just got out of her way.
“They won’t see it coming — but you will.”
That’s the thesis of the whole thing. Adversaries are invisible to defenders. SPECTER makes the defender’s stack visible to themselves first.
See it
If you’re scoping continuous VAPT for your organization — or you’re a consultant whose engagement velocity has stopped scaling — we’d welcome the conversation.
For the technical brief (architecture diagrams, sample report, ZAK integration notes), email info@zeron.one or DM us on LinkedIn.
SPECTER is part of the ZAK agentic line at Zeron. Learn more about the Zeron Agent Development Kit at zeron.one.
