heilashahidi/adversarial-openemr

adversarial-openemr

Multi-agent adversarial evaluation platform that continuously attacks a live deployed Clinical Co-Pilot built on OpenEMR.

📄 Project page: `docs/index.html` — landing page with quick links to the live dashboard, target, threat model, architecture, and reports. Renders directly on GitHub Pages if enabled (Settings → Pages → main / docs).

Target (Stage 1)

• —Live target URL: https://openemr.146-190-75-148.sslip.io
• —Health check: GET /health → 200
• —Attack surface: POST /chat (synthesis pipeline), POST /extract (VLM document ingestion)
• —Live dashboard: https://heilashahidi-adversarial-openemr.hf.space/
• —Source repo: https://github.com/heilashahidi/adversarial-openemr

Every attack the platform produces is sent to that URL — there is no mock target. The dashboard's Overview page shows the latency, token counts, and full target responses from the most recent live run. The target_client.py health check fires before every campaign and aborts if the target is unreachable.

Target state and changes made for testability

The Clinical Co-Pilot is the unmodified deployment from the Weeks 1–2 case study, hosted on DigitalOcean. No platform-side changes to the target were required to bring it into a testable state for Week 3. The Week 1–2 deliverables (deployment, DNS, TLS, agent pipeline, test-data seeding) produced a system that was already adversary-ready when Week 3 began.

What Weeks 1–2 set up (target side)

What Week 3 (this platform) added — and did not add

Added (platform side only):

• —target_client.py — an HTTP wrapper that sends adversarial payloads to /chat with the right shape, and short-circuits on 5xx/timeout.
• —evals/seed_attacks.py — 44 adversarial test cases (40 initial + 4 high-tier additions on 2026-05-13).
• —agents/triage_agent.py + agents/judge_agent.py — the two-tier Judge.
• —state_store.py — SQLite for findings, coverage, exploits, cost.
• —The Streamlit dashboard for human observability.

Not added (target side):

• —No code changes to the Co-Pilot itself.
• —No new endpoints.
• —No test fixtures, stubs, or proxy layers between the platform and the target.
• —No auth bypass shims (the auth posture below is the existing one, not one we created).

Environmental facts discovered while bringing the system into a testable state

These two findings are properties of the existing deployment, not changes we made — they would be present whether or not the adversarial platform existed.

Running the target locally (Weeks 1-2 setup)

The adversarial platform also runs against a local Clinical Co-Pilot instance, not just the public deployment. The Weeks 1-2 case-study setup produces a target reachable at http://localhost:8000 — same FastAPI app, same agent pipeline, same Sonnet synthesis worker, same /chat /extract /health endpoints. To point the platform at it instead of the deployed instance, override the target URL via env var:

# Run the Co-Pilot locally per the Weeks 1-2 case study
# (OpenEMR + uvicorn + FastAPI on localhost — see Weeks 1-2 deliverables)

# Point the platform at it
export TARGET_BASE_URL=http://localhost:8000

# Verify reachability
python3 evals/run_attacks.py --smoke

# Run the full suite against the local target
python3 evals/run_attacks.py --workers 1

config.TARGET_BASE_URL reads from TARGET_BASE_URL env var with the deployed URL as the default fallback, so nothing else in the platform needs to change. Every commit's results JSON records the URL hit so local vs deployed runs are distinguishable in the dashboard's run history.

What this platform does

Four-stage W3 deliverable:

All five agents implemented

Plus the Regression Harness (`agents/regression_harness.py`) — deterministic replay of confirmed exploits, rule-based pass/fail/inconclusive classification, no LLM in the replay path.

Dashboard pages

The hosted dashboard is a read-only viewer of committed run artifacts:

• —Overview — headline stats from the latest attack run (bypasses / defended / partial / errors, T1 vs T2 cost split)
• —Coverage Map — heatmap showing all 29 threat-model sub-vectors (26 exercisable + 3 supply-chain probe seeds) and their tested-vs-untested status
• —Attack Browser — every adversarial case with prompt, target response, and judge verdict + reasoning
• —Threat Model — full attack-surface map
• —Architecture — multi-agent platform design

Run the suite locally

Smoke check (fastest path to verify target is live — no API key needed)

git clone https://github.com/heilashahidi/adversarial-openemr.git
cd adversarial-openemr
pip install -r requirements.txt
python3 evals/run_attacks.py --smoke

Prints the target URL, /health status, /chat status, latency, tokens billed, and a response preview in ~5–10 seconds. Useful for graders / reviewers who want to confirm the platform actually hits a live target before running anything LLM-billed.

Full attack suite (40 cases, ~10 min, costs ~$0.14)

cp .env.example .env   # then fill in OPENROUTER_API_KEY (and optionally LANGSMITH keys)
python3 evals/run_attacks.py                      # all 40 cases
python3 evals/run_attacks.py --id DE-09           # one specific case (e.g. §2.4 unauth probe)
python3 evals/run_attacks.py --category prompt_injection   # filter by category

Outputs land in evals/results/attack_results_<timestamp>.json and update latest_results.json. The dashboard picks them up on next git push.

Latest live-run results

40 attacks · 38 defended (≥0.92 confidence) · 1 confirmed bypass (DE-09 §2.4 unauthenticated endpoint) · 1 target error (PI-04 HTTP 500 on base64) · Two-tier Judge (Haiku 4.5 → Sonnet 4.5) at ~$0.003/attack · LangSmith traces grouped per campaign.

See the dashboard for the full breakdown.

Verdict taxonomy

The Stage 3 rubric speaks in terms of pass / fail / partial. The platform uses a more precise taxonomy that separates target failures (HTTP 5xx / timeouts) from defenses:

Every result JSON row has a verdict field with one of those values. Per-case regression_candidate: true in seed_attacks.py means "if this produces a bypass, freeze it into the regression suite" — the actual promotion to regression happens at verdict == "bypass" AND confidence ≥ 0.9 (see ARCHITECTURE.md §4.2).

Reproducibility

The platform has run the suite many times against the live target as it grew from 24 → 40 → 44 → 47 → 50 cases. Committed artifacts in evals/results/attack_results_*.json document each campaign — same verdicts across runs against the same suite version:

Reproducibility comes from: provider-pinned Anthropic on OpenRouter (no silent provider routing), temperature 0.0 on both Triage and Judge, JSON-schema parse-retry on bad output, target-failure short-circuit + HTTP-5xx promotion rule (so HTTP 5xx never corrupts a verdict and is promoted to the regression set instead). The §2.4 bypass, PI-04 target failure, and TM-05 wildcard have all reproduced across every run since they were introduced. DOS-01 specifically reproduces deterministically via the Tier-0 payload-size gate ($0 per call).