AI made cyberattacks cheap and automatic. Small teams ship fast with AI and can’t afford a pentest. Security Twin gives them one, automatically. Here’s the whole flow.
The sample Kit Store has a route for reading a kit: GET /api/kits/:id. It looks up the requested ID but does not check who owns that kit. Alice can change the number in the URL and receive Bob’s kit.
This walkthrough uses an insecure direct object reference (IDOR) as one concrete example: the app accepts a record number without checking that the signed-in user is allowed to see it. In a real service, this could expose or let someone change another person’s data. OWASP includes IDOR under Broken Access Control (A01:2025). The broader flow is about finding a weakness, tracing it to code, fixing it, and checking the repair.
One user changes a record number and sees another person’s data. Security Twin makes a safe copy, reproduces that mistake, adds an ownership check, then tests access as both users. The fix works only if it blocks the stranger and still lets the owner in.
The route reads an ID from req.params.id and calls getKit(id). The vulnerable version returns the kit when it exists, without checking kit.ownerId against currentUser(req). The patch adds that ownership check at the route. A cross-user request should return 404; the owner’s request should still return 200.
ClickHouse detects one source requesting many different kit IDs. Semgrep then checks the source for the unsafe lookup pattern.
Imagine a row of lockers. The app checked that a locker number was real, but not that it belonged to the person asking. Someone could change the number and open another person’s locker. Security Twin rehearses this safely, adds the missing name check, and tries again with both people to make sure the repair is right.
An LLM-backed attacker sends requests through a shield proxy to the isolated copy of the app.
ClickHouse searches request records for a source accessing many different kit IDs.
The pipeline maps the finding to a source file and checks the unsafe pattern with Semgrep.
It checks how many callers a change would affect, then chooses a local guard or asks for review.
It confirms the other user is denied while the record owner keeps access.
A Semgrep rule can run in CI to catch the same unsafe pattern in a later change.
Choose a moment in the workflow to inspect. The screenshots stay at a readable width, so the page can explain what each screen proves without stacking a wall of images.
Measurements come from recorded runs and can vary with environment and data volume.
The test target. Kit Store has user-owned records and a deliberately unsafe lookup, giving the run a concrete cross-account access bug to reproduce.
The operator view. Start or replay a run here, then follow the stages and their output in one place.
One visible sequence. The stages move from an isolated clone and baseline through attack, detection, patch, proof, and reporting.
Reproduce the boundary failure. The attacker exercises the cloned app through the shield, which records the request and its run context.
Turn traffic into a signal. ClickHouse groups request events and flags one source touching many distinct kit IDs. This screenshot is a separate earlier run from the 23 ms summary above.
Keep the fix bounded. Before editing, the system inspects callers and weighs a local ownership guard against changing a shared function contract.
Prove both sides. The run verifies that another user gets denied while the record owner still succeeds, then reports completion.
The orchestrator controls the run. Attack traffic goes through the shield to the twin, while telemetry flows to ClickHouse. Source analysis and patching use the isolated workspace; the dashboard receives events over server-sent events.
The pipeline runs stages in order and passes earlier results forward. Here is the chain behind the dashboard’s thirteen cards.
The pipeline copies the app into a separate folder for this run and scans it for a starting point. Your original files stay untouched.
The AI attacker tries to read a kit owned by another user. A shield records the requests, and a traffic stage adds normal activity for comparison.
ClickHouse finds a source requesting many different kit IDs. The pipeline traces that activity to a file, then Semgrep checks for the unsafe lookup.
The system saves what it learned and checks how many parts of the app use the lookup. It picks a small fix, or asks a developer to review a wider change.
The same request is tried again. The other user should be denied, while the owner should still get the kit. In this run, the Semgrep score went from one finding to zero.
The rule can run in CI and block a future change that brings back the unsafe pattern. With optional services configured, the pipeline can also open a draft PR and send alerts.
clone.ts creates the per-run work copy at ctx.work_dir. scan.ts records the starting Semgrep result.
The attacker can send requests only through the shield URL. traffic.ts adds run-tagged requests; shield middleware batches request context to ClickHouse.
detect.ts queries distinct kit IDs per IP. map.ts finds the related source file, and confirm.ts checks it against the stored Semgrep rule.
remember.ts stores the finding. fix.ts checks callers before choosing between an in-handler owner check and a user-scoped function signature.
prove.ts calls the live patched twin to confirm cross-user 404 and owner 200, then records the result.
sync.ts can create a branch and draft PR. When configured, alert.ts and brief.ts send a voice alert and audio summary.
The simple patch is an ownership check in the route. A different option is to replace a general lookup with a function that always requires the current user. That can make authorization harder to forget, but it changes the function contract and affects every caller.
| Choice | Change | When it fits | Trade-off |
|---|---|---|---|
| In-handler guard | Return not found if the kit is missing or belongs to someone else. | Default; does not change getKit(id) callers. | Every new route still needs to apply the owner check. |
| User-scoped lookup | Use getKitForUser(id, userId). | When caller scope is clear and the signature change is safe. | All call sites must provide the user identity. |
The fix view shows the chosen patch alongside its blast-radius reasoning. If the risk is unclear, the orchestrator can pause for a human decision rather than silently broadening the change.
These files separate run orchestration, request handling, detection, and memory so the full path can be inspected and changed one responsibility at a time.
| File / folder | Role | What it does |
|---|---|---|
orchestrator/src/server.ts | Control API | Starts runs, streams events, accepts fix decisions, exposes memory and audio endpoints. |
orchestrator/src/pipeline.ts | Runner | Runs the stage list in order and buffers events in an in-process run registry. |
orchestrator/src/stages/ | Workflow | One module for each of the 13 steps, sharing run context and earlier stage results. |
shield/src/index.ts, ch-sink.ts | Request boundary | Proxies traffic, tracks session/run context, serves decoys, and batches request events. |
attacker/src/agent.ts | Attack agent | Constrains HTTP requests to the shield and runs the configured LLM tool loop. |
demo-app/src/index.ts, kits.ts | Target twin | Express sample app and kit data, including the deliberately vulnerable route scenario. |
orchestrator/src/ch-requests.ts, ch-store.ts | Detection store | Initializes ClickHouse schemas used for request logs and detection queries. |
orchestrator/src/memory.ts | Security memory | Stores findings, embeddings, attacker confessions, and completed run history in MongoDB. |
dashboard/src/components/, dashboard/src/app/ | Operator UI | Renders pipeline progress, attack events, detection evidence, fix, and proof. |
rules/memory/, .github/workflows/twin-gate.yml | CI regression gate | Runs the learned Semgrep rule as a pull-request check. |
A useful security story needs more than a green status. Here is what the saved run records, which providers the project supports, and what Semgrep did (and did not) execute in that run.
The saved trace shows Alice reading kit-3, owned by Bob, and kit-5, owned by Carol. That turned an authorization warning into visible evidence of another user’s data being returned.
The confirmed run table labels this attack stage DEMO. Treat it as recorded/replayed evidence, not a fresh live LLM call.
The attacker supports OpenAI by default, AkashML through LLM_PROVIDER=akash, and OpenAI-compatible endpoints such as Nebius. The host check still routes requests through the shield. The saved exploit trace above names AkashML; these are provider options, not a three-way benchmark.
In the same recorded run, the traffic stage sent 16,070 requests and ClickHouse logged 595. The detection query found 37 kit hits across 12 distinct IDs in 106 ms.
Run: run-1791572905224. These numbers describe that run only.
Stage 6 maps the finding to a source file. When the Semgrep CLI is available, confirm.ts runs semgrep --config rules/memory/idor.yaml --json --quiet <file> and confirms the issue if the targeted rule matches.
The saved run reports “SEC-001 rule confirmed” in 24 ms but labels the stage DEMO; Semgrep was unavailable, so the fallback result was used. This record does not prove that the CLI ran live.
| Mode | What runs | Best for |
|---|---|---|
| Dashboard replay | Reads bundled recorded events; no backend required. | Trying the UI or showing the run flow. |
| Live pipeline | Clones a target and runs available stages and integrations. | Authorized experiments with configured services and keys. |