Showcase / Made at Kane CLI Hack Day
Other
Bugsy
Bugsy checks whether one user can read or change another user's records, then tests the fix.
Bugsy checks whether one user can read or change another user's records, then tests the fix.
1 builder credited · submitted Oct 24, 6:31 PM PDT
Kane · proof view
- Ingest the ownership rule (kane-cli context ingest)
- Approve the extracted use cases (context review --approve)
- Design two-account tests with owner controls (design tests --use-case)
- Run against the vulnerable build. Leaks reproduced (S2 read, S5 pay)
- Codex patches from Kane's failure record and screenshot
- Rerun the same tests on the patched build: 5/5 pass
- Revert the patch and rerun. S5 goes red, then the patch is restored
- bugsy:scan @ bd410a3Suspected · failed
- bugsy:self-check (leak reintroduced on purpose)Suspected · failed
- bugsy:scan @ bb5c31cVerified · passed
Product
Other
Run command in repo
Harness
4 Kane parts
Kane CLI context ingestion · Kane CLI assurance test design · Kane CLI test execution
Evidence
3 runs
1 verified · 2 detected
Repo
bd410a3
github.com/aayushkhator1994/bugsy
01 / The creation
What it is, and why.
Bugsy checks whether one user can read or change another user's records, then tests the fix.
02 / The harness
How Kane checks it.
Bugsy feeds one ownership rule to Kane CLI as context, approves the extracted use cases, and has Kane design two-account _test.md tests: each denial (Alice → Bob's invoice) is paired with an owner control. Kane runs them in a real Chrome, one at a time, signing in as Bob, then Alice. The sealed evidence pack (status, failure record, screenshot) is what Codex patches from. Kane reruns the same tests on the patched build, then on a reverted build to prove the test goes red again. 5 scenarios; 2 leaks caught, fixed and re-verified.
- Kane CLI context ingestion
- Kane CLI assurance test design
- Kane CLI test execution
- Kane CLI execution evidence
- 01Ingest the ownership rule (kane-cli context ingest)
- 02Approve the extracted use cases (context review --approve)
- 03Design two-account tests with owner controls (design tests --use-case)
- 04Run against the vulnerable build. Leaks reproduced (S2 read, S5 pay)
03 / Evidence
What actually ran.
Verified means a passing run reported through a paired, verified channel. A failing run is a detection, not a confirmed bug. Everything else is as the team reported it.
- Suspected · failedOct 24, 2:44 PM PDT
bugsy:scan @ bd410a3
kanehack_cli · 2c29d5fa-9e9e-4616-b253-ca2615a9d20e · exit 1 · bd410a3
- Suspected · failedOct 24, 3:04 PM PDT
bugsy:self-check (leak reintroduced on purpose)
kanehack_cli · 6173e8eb-e879-4feb-ac28-2654b42991f9 · exit 1 · bb5c31c
- Verified · passedOct 24, 3:14 PM PDT
bugsy:scan @ bb5c31c
kanehack_cli · 5c6d42cf-98be-4d8e-ab22-f0ec47f85955 · exit 0 · bb5c31c
04 / Outcome
What changed.
0leaks
Cross-account leaks still open after the Codex patch
Baseline 2 leaks
Source: Kane runs 167 (vulnerable build) and 188 (patched build) (team reported)
5scenarios
Ownership scenarios passing (out of 5)
Baseline 3 scenarios
Source: Kane runs 167 (vulnerable build) and 188 (patched build) (team reported)
Known limitations
- Tested on one demo app with one ownership rule (invoices); other apps and rules are untested
- Not every test is purely Kane-designed: the S5 test needed manual edits and some tests used prepared fallbacks
- A failing run is a suspected leak, not a confirmed bug; the RCA classification hasn't been checked by a person
05 / Ship it forward
The code. The proof.
The story.
- Aayush Khatorkhatoraayush