Skip to content

Repository files navigation

Project VEDA

Project VEDA

Vulnerability · Exploitation · Detection · Architecture
An HITL-governed, multi-agent autonomous red-team framework for BFSI APIs.

▶ Live interactive demo  ·  Quickstart  ·  Architecture  ·  Governance  ·  Responsible use

license python governance status


▶ Watch it run: the live interactive walkthrough replays a full engagement — boot → cryptographic scope-gate → human approval → attack → scored report — reconstructed from real run data. (Locally: open index.html in a browser.)

What is VEDA?

VEDA stands for Vulnerability Exploitation Detection Architecture.

Project VEDA is a governed, multi-agent framework that autonomously red-teams a target API and scores what it finds — while staying inside hard safety rails. Its differentiator is not raw offense but assurance: every action passes a cryptographically-signed scope gate, high-risk phases block on human approval, and everything is written to a tamper-evident audit ledger. The agents are named after the Mobile Suit Gundam 00 meisters and the quantum supercomputer that coordinates them.

Headline result

Against a 10-row seeded-vulnerability ground-truth matrix on the bundled Singa Bank sandbox, VEDA's deterministic detection pipeline scored:

Precision Recall Specificity F1
100% 90% 100% 94.7%

The single miss is a documented, controlled false negative — a concurrency (time-of-check/ time-of-use) double-spend that a single-request detection model cannot observe. It is reported honestly rather than hidden; that transparency is the integrity anchor of the evaluation.

🛰 The agents

Agent Codename role Underlying tool
VEDA Core Orchestration, state & synthesis Hermes (Claude / Anthropic API)
EXIA Infrastructure & boundary reconnaissance CAI
DYNAMES Application / API security testing Strix
VIRTUE Cryptographic scope-gate (safety) HexStrike (additive, behind the gate)
PTOLEMAIOS Isolated Docker sandbox Docker (veda_only network)

🏛 Architecture

A layered pipeline — recon (EXIA) → application testing (DYNAMES) → synthesis (VEDA Core) — with VIRTUE wrapping every target-touching action in a scope check, and PTOLEMAIOS isolating the whole engagement. See diagrams/ for the layered architecture, multi-agent dataflow, and scope-verification-gate diagrams.

🔐 Governance

VEDA treats safety as first-class, not an afterthought:

  • Ed25519 cryptographic scope-gate — a signed manifest declares the in-scope targets, allowed technique intensity, and which actions require human approval. Six predicates must all pass (default-deny) before a single packet reaches the target.
  • Human-in-the-loop checkpoints — four blocking checkpoints (CP1–CP4). Active exploitation and action-on-objectives cannot proceed without an explicit typed APPROVE; the enforcement is external to the model, so an autonomous agent cannot skip or fake it.
  • Tamper-evident audit ledger — every recon action, gate decision, approval, and finding is appended to a SHA-256 hash-chained ledger. Any post-hoc edit breaks the chain.
  • Regulatory mapping — findings and controls are mapped to MITRE ATT&CK (Enterprise), the OWASP API Security Top 10, and Singapore's MAS TRM / ABS AASE guidance.

🚀 Quickstart

Requires Python 3.11+ and Docker. Runs entirely against the local, isolated sandbox.

# 1) Start the intentionally-vulnerable target (Singa Bank inside PTOLEMAIOS)
cd singa-bank-backend
cp .env.example .env            # review the seeded-vulnerability flags (off by default)
docker compose up -d            # target at http://localhost:8000/api/v1
cd ..

# 2) Install VEDA
pip install -r requirements.txt

# 3) Generate the Ed25519 scope-gate keypair and sign the scope manifest
python setup_scope.py           # writes keys/ (git-ignored — never commit these)

# 4) Run a governed engagement (HITL checkpoints will prompt you to APPROVE)
python run_veda.py

# 5) Score the run against the 10-row ground-truth matrix
python score_engagement.py

The real-tool integrations (EXIA→CAI, DYNAMES→Strix, VIRTUE→HexStrike, VEDA Core→Hermes) are additive adapters under veda/agents/; each requires its own upstream install and, where applicable, an API key. The hand-rolled deterministic pipeline runs with no external tools.

📁 Repository layout

veda/                 Framework: agents, scope-gate, HITL, ledger, reporter, scorer, ground truth
singa-bank-backend/   Intentionally-vulnerable BFSI target (FastAPI) — the lab
singa-bank-frontend/  Static UI for the target
ptolemaios/           Docker sandbox composition
diagrams/             Architecture & dataflow diagrams
docs/TARGET_SPEC.md   The 10 seeded vulnerabilities (ground truth)
index.html            The live interactive walkthrough (served by GitHub Pages)
assets/               Logo, banner, badge

💸 Costs — the AI agents are not free

The hand-rolled deterministic pipeline runs at zero AI cost — no LLM calls, no tokens. That is the 100% / 90% / 100% / 94.7% headline result, and it is fully reproducible for free.

The real-tool integrations are LLM-driven and cost real money. EXIA→CAI, DYNAMES→Strix, the agentic side of VIRTUE→HexStrike, and VEDA Core→Hermes all call large language models and consume tokens billed by whichever provider you use. If you run these, you accept and bear that cost. A concrete data point from this project: a single Strix engagement consumed 253 LLM calls and ~12 million tokens (≈ USD 12.63) and still hit a budget ceiling before finishing. Cost scales with the model, the target size, and how much the agent explores.

⚠️ Always set a hard budget. Treat a price ceiling and a max-turns / max-calls cap as mandatory safety controls (VEDA exposes these), so a runaway agent cannot drain your account.

Cheaper / free alternatives — and their trade-offs

You do not have to use a premium frontier API. CAI and Strix accept alternate model endpoints via their environment variables (e.g. STRIX_LLM, CAI_MODEL, LLM_API_KEY and base-URL overrides):

  • Ollama — local, free. Runs open models (Llama, Qwen, Mistral, …) on your own machine: zero per-token cost, fully private, works offline. Cons: needs a capable GPU / plenty of RAM; smaller open models reason less well, so detection quality and multi-step orchestration typically drop (expect more misses than the frontier result); slower on modest hardware; some agents assume strong function-calling that local models handle less reliably.
  • OpenRouter — hosted, pay-as-you-go (some free tiers). One API key routes to many providers and lets you pick cheaper models. Cons: still costs money unless you use rate-limited free-tier models; your prompts pass through a third-party router (a privacy consideration for security work); cheaper models again mean lower quality; availability and pricing vary by model.

Rule of thumb: frontier API = best detection, highest cost · Ollama = free & private, lowest capability · OpenRouter = a tunable middle ground. The deterministic baseline stays free regardless.

⚠️ Responsible use

Project VEDA is for authorised security testing and education only. The bundled Singa Bank app is intentionally vulnerable — do not deploy it on a public or production network. Only run VEDA against systems you own or are explicitly authorised to test. See SECURITY.md.

📜 License

Released under the MIT License. Built as the practical artifact of an MBA cybersecurity thesis. Upstream tools retain their own licenses (CAI — MIT; Strix — Apache-2.0; HexStrike — MIT).

About

HITL-governed, multi-agent autonomous red-team framework for BFSI APIs — Ed25519 scope-gate, human checkpoints, tamper-evident audit ledger.

Topics

Resources

Contributing

Security policy

Stars

1 star

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages