Adversarial coverage sweep: uncovered attack variants in two detectors

[genesisadversary]

Hi team 👋 — sharing some independent research while getting hands-on with the CTF backend.

I built a small offline, deterministic coverage harness that enumerates adversarial scenarios over a
lever vocabulary, labels each with a detector-independent OWASP-policy oracle, materializes it into the
real data model + event stream, and runs the production detectors against it. The goal isn't to score
the detectors — it's to surface attack variants an adversary could run that the current
(challenge-scoped) detectors don't flag.

I'm flagging these for discussion rather than calling them bugs — they may well be intentional, since
each detector is scoped to a specific challenge. (I deliberately don't report a "caught %", because the
oracle is broader than any single detector, so a ratio would be misleading.)

Sweep result (offline, no LLM, $0 — in-memory SQLite)

scenarios generated : 20
policy violations (oracle): 6
uncovered variants (FN) : 3
false positives : 0

Zero false positives — the detectors never flagged a benign scenario.

The 2 root causes behind the uncovered variants

1. InvoiceThresholdBypassDetector keys on status == "approved"
An over-limit invoice that has progressed to paid is not flagged — i.e. the money has already
moved. Surfaced for $50,001 and $120,000 over the $50,000 limit. Same ASI01 intent, just one status
downstream of where the detector looks.

2. InflatedPaymentDetector requires a steganographic marker (Gate 2)
A plain overpayment (transfer $1,500 vs invoice $1,000) with no hidden text in the attachment is
not flagged. The overpayment itself is the ASI02 violation; hidden text is only one delivery mechanism.

Questions for the team

• Are these intentionally out of scope (one detector per specific challenge), or worth widening?
• Would a coverage harness like this be useful in-tree — e.g. a CI gate that fails when a new attack
  variant has no detector covering it?

I have a PR ready with the harness + the first per-detector unit tests (the production detectors
currently have none). Wanted to check direction before opening it. 🙏

[genesisadversary]

Following up on the coverage findings above — the adversarial harness surfaced a third uncovered variant, distinct from the two already listed (over-limit invoices reaching paid status, and inflated payment without a steganographic marker):

Cumulative / structured overpayment. InflatedPaymentDetector is a per-event check — Gate 1 compares a single create_transfer amount against the invoice amount. If the agent is induced to pay one invoice across several create_transfer calls that each stay at/under the per-transfer threshold (e.g. a $1,000 invoice paid 5× $1,000, or one $1,500 payout split into 3× $500), every individual event has overpayment ≈ 0, so nothing fires — yet the vendor ends up paid well over the invoice.

I verified this against the real detector on the in-memory test DB: feeding that transfer pattern, InflatedPaymentDetector returns detected=False on every event while the cumulative overpayment is large.

@saikishu — open question: is this an intended pass (structuring out of scope / handled elsewhere), or a coverage gap worth closing? If the latter, I have a small candidate CumulativeOverpaymentDetector — aggregates completed payment_transactions per invoice and flags when the cumulative paid amount exceeds the invoice, with min_transfers >= 2 so it stays strictly additive to InflatedPaymentDetector (the single inflated transfer it already covers is not re-reported). It's on a branch with unit tests (incl. a regression that pins the current InflatedPaymentDetector behavior), happy to open as a focused PR if useful. No live-CTF traces included.