Audit history

KryptosProof — HackHayward 2026

Security built for web developers. Automated red team → blue team audits with evidence you can verify.

Inspiration

Web developers write the code that runs the internet — but most of them have no practical way to check if what they're shipping is secure. Penetration testing is expensive and slow. Generic scanners produce noisy reports developers can't act on. And the new wave of "AI security tools" that chat about vulnerabilities don't actually prove anything.

The question that drove us was simple: what does it take to actually close the loop?

Finding a bug is only half the job. The other half is:

Reproducing it with evidence
Writing a fix that addresses the root cause
Verifying that the fix actually works

Almost no tooling for individual developers or small teams does all three. That gap — between "we found something" and "we can prove it's fixed" — is where KryptosProof lives.

We were also motivated by the math of the problem. The web security surface area is enormous:

$$ \text{Attack surface} \propto \sum_{i=1}^{n} \left( \text{endpoints}_i \times \text{input vectors}_i \times \text{vuln types} \right) $$

For a typical web app with $n$ routes, each with multiple parameters and 8+ vulnerability categories, manual review becomes combinatorially intractable. Automation isn't a nice-to-have — it's the only way to keep pace with shipping velocity.

What it does

KryptosProof is a security platform built for web developers. You give it a URL — your staging environment, a local app, or any target you have permission to test — and it runs a full automated audit from start to finish.

The platform works in four phases:

1. Scan

AI-driven red team agents run real attack tools inside an isolated Docker sandbox:

Tool	Vulnerability Category
`sqlmap`	SQL Injection
`Nuclei`	XSS, Misconfiguration, CVEs
`FFUF`	Path Traversal, Hidden Endpoints
`OWASP ZAP`	Broken Auth, CSRF, SSRF
`PayloadsAllTheThings`	Custom payload generation

2. Confirm

Only vulnerabilities with reproducible proof move forward. Full stdout/stderr logs are captured. No false-positive noise.

3. Fix

A blue team AI agent reads the confirmed vulnerabilities and writes a defensive patch, then validates fix quality with semantic pattern-matching:

$$ \text{coverage_score} = \frac{\text{defensive patterns matched}}{\text{required patterns for vuln type}} \times 100 $$

A patch is accepted if $\text{coverage_score} \geq 50$. If it fails, the orchestrator retries with the failure context (up to $2\times$).

4. Report

You receive a structured SecurityAuditReport:

Overall status and per-vulnerability findings
Fix patches in diff format
Markdown + JSON output
report_sha256 — a SHA-256 fingerprint of the canonical report
Optional: report digest anchored on an EVM testnet for tamper-evident sharing

Everything is accessible through a clean Next.js dashboard with live phase logs — no command line required.

How we built it

Agent Architecture

KryptosProof is built on a multi-agent architecture using pydantic-ai, which lets us coordinate a hierarchy of specialized AI agents — each with clearly defined roles, structured output schemas, and automatic retry logic.

Orchestrator Agent (pydantic-ai)
    ├── Red Team Agent  →  Execution Pipeline (Docker sandbox)
    └── Blue Team Agent →  Testing Agent
                        →  SecurityAuditReport

The orchestrator drives the entire red → blue pipeline. It never executes code itself — it plans, delegates, and synthesises results from specialist agents.

Structured Outputs

Every inter-agent handoff is enforced by a Pydantic schema. For example, the red team execution result:

class ExecutionResult(BaseModel):
    script_output: str
    vulnerabilities: list[VulnerabilityReport]
    exit_code: int
    execution_time_ms: float

If the LLM returns something that doesn't validate, the agent retries automatically with the validation error as context — no silent failures.

Docker Sandbox

Attack scripts run inside an isolated Docker container on a dedicated kryptosproof_sandbox network. The sandbox shares the network with DVWA (our test target) but is fully isolated from the host. Scripts have a configurable timeout ($T_{\text{max}} = 30s$ by default).

Fix Verification

Because we can't patch the live DVWA target mid-run, fix verification uses semantic static analysis rather than live retesting:

$$ \text{patched} = \begin{cases} \text{True} & \text{if coverage_score} \geq 50 \ \text{False} & \text{otherwise (retry)} \end{cases} $$

Pattern examples by vulnerability type:

Vuln Type	Required Defensive Pattern
SQL Injection	`parameterized` or `cursor.execute` with bindings
XSS	`html.escape` or template auto-escaping
Command Injection	`shlex.quote` or `subprocess` with list args

Stack

Backend: Python, pydantic-ai, FastAPI
Frontend: Next.js, TypeScript
Execution: Docker (sandbox + DVWA target)
Observability: Logfire tracing
Integrity: SHA-256 report hash + optional EVM testnet attestation (web3)
Model: Anthropic Claude (claude-opus-4-6 via anthropic: provider prefix)

Challenges we ran into

1. Multi-agent reliability under time pressure

Getting AI agents to collaborate reliably was the hardest part. Each agent must produce structured, validated output for the next agent to consume — and LLMs don't always honour schemas on the first attempt. We built retry loops that pass the validation error back to the agent as context, which helped significantly, but tuning the balance between retrying and moving forward took real iteration under a 24-hour clock.

The key insight was treating inter-agent contracts like API contracts: typed, validated, and version-controlled in Pydantic schemas. Once we stopped treating LLM output as free-form text and started treating it as a typed data pipeline, reliability improved dramatically.

2. Docker sandbox networking

We needed the execution environment to be genuinely isolated — able to run arbitrary Python exploit scripts without risk to the host — while still able to reach the DVWA target container on a shared network. Getting Docker networking right (shared kryptosproof_sandbox network, correct bridge configuration, container DNS resolution) during the hackathon setup crunch required careful testing and a few frustrating restarts.

3. Real-time log streaming

Making phase output feel live while the audit pipeline ran asynchronously in the background required a polling and state-tracking layer in the FastAPI server. Each audit has a lifecycle managed in memory, with phase logs appended as they arrive. The frontend polls /api/audits/{id} and progressively renders logs — simple, but getting the timing and partial-result semantics right without race conditions took more care than expected.

4. Fix verification without live retesting

Because DVWA cannot be patched mid-run, we couldn't verify fixes by re-running the attack and checking whether the [VULN] markers disappear. We had to design a semantic verification layer that gives a meaningful quality signal purely from static analysis of the patch — which required building the per-vuln-type pattern library and the coverage scoring formula from scratch in 24 hours.

Accomplishments that we're proud of

Shipping a real end-to-end pipeline. This isn't a demo with mocked data. Real attack tools run in a real sandbox, real vulnerabilities get confirmed with logs as evidence, and a real patch gets written and validated before being handed to the user.

The fix verification loop. Rather than just generating a patch and hoping, we built a semantic coverage checker that scores fix quality before surfacing it:

$$ \text{coverage_score} = \frac{|{\text{patterns}{\text{found}}} \cap {\text{patterns}{\text{required}}}|}{|{\text{patterns}_{\text{required}}}|} \times 100 $$

That's a meaningful signal, not theater.

Getting real tools running in an AI-orchestrated pipeline. sqlmap, Nuclei, FFUF, and OWASP ZAP — all orchestrated by an LLM agent, all running in a Docker sandbox, all producing structured output that feeds the next stage. The integration between AI reasoning and deterministic tool execution is what separates KryptosProof from a chatbot.

On-chain attestation. We shipped the optional SHA-256 → EVM testnet attestation path, giving reports a tamper-evident property that makes them trustworthy to share across teams or with external auditors.

What we learned

Multi-agent systems need typed contracts

The biggest technical lesson: treat inter-agent communication like a typed API, not like a conversation. Once every handoff was a Pydantic model, we stopped chasing mysterious failures and started shipping features.

AI depth ≠ more API calls

Real AI depth means building systems where the model operates under constraints, with real tools, with observable reasoning. The combination of Logfire tracing and structured schemas gave us visibility into what the agents were actually deciding — essential for debugging.

The signal-to-noise ratio of the system can be expressed as:

$$ \text{SNR} = \frac{\text{confirmed vulns with reproduction}}{\text{total alerts generated}} $$

Most scanners have a low SNR. Our goal was to push it toward $1.0$ by only passing confirmed, reproducible findings downstream.

Framing is a product decision

The same technology lands very differently depending on how you describe it. "Automated penetration testing" sounds expensive and enterprise. "Security co-pilot for web developers" makes it immediately clear who it's for and what it does for them. We learned to lead with the user's problem, not the technology.

What's next for KryptosProof

CI/CD integration — a GitHub Action that triggers an audit on every pull request, flags new vulnerabilities introduced by the diff, and posts a summary inline. Security embedded in the workflow before code reaches production.

Expanded vulnerability coverage — beyond the current 8 categories, adding IDOR, JWT misconfiguration, open redirects, and API-specific attacks.

SaaS platform — persistent audit history, scheduled scans, trend dashboards, and team report sharing. The architecture is already API-first; the SaaS layer is a natural next step.

Hardened attestation — production key management for on-chain report anchoring, making the tamper-evident reports viable for compliance use cases (SOC 2, bug bounty programs, client-facing security summaries).

The long-term vision: every web developer has a security co-pilot that catches vulnerabilities before users do — not as an afterthought, but as a first-class part of the development workflow.

$$ \text{time to fix} \xrightarrow{\text{KryptosProof}} \text{time to ship} $$