# AI use cases for RiftX (Ch1nfo/RiftX)

Repo: [Ch1nfo/RiftX](https://github.com/Ch1nfo/RiftX) | Use cases: 4 | Page: https://dedupedai.com/use-cases/ch1nfo-riftx/

RiftX is a local TypeScript workbench that combines AI agent chat, a Playwright browser, multi-agent task coordination, and evidence capture for explicitly authorized web security testing.

This file holds every use case of this repo. Each one starts with a "## " heading and ends with its URL.

- Validate web app findings with linked browser evidence: https://dedupedai.com/use-cases/ch1nfo-riftx/validate-web-app-findings-with-evidence/
- Map an app's attack surface with parallel child agents: https://dedupedai.com/use-cases/ch1nfo-riftx/map-attack-surface-with-parallel-agents/
- Test access control with isolated browser identities: https://dedupedai.com/use-cases/ch1nfo-riftx/test-access-control-across-identities/
- Research known vulnerabilities for a fingerprinted product: https://dedupedai.com/use-cases/ch1nfo-riftx/research-known-vulnerabilities-for-a-product/

## How to validate web app findings with linked browser evidence with RiftX

Repo: [Ch1nfo/RiftX](https://github.com/Ch1nfo/RiftX) | Difficulty: Advanced | Time: 60 minutes | Basis: From the README

Confirm suspected web issues in a scoped app and link each finding to requests, screenshots, and quotes.

**Who it is for:** A penetration tester with signed authorization who needs to confirm suspected issues in a web application and write up reviewable results.

**The problem:** Validation work is split across terminals, browsers, proxies, and notes, so conclusions drift away from the requests and screenshots that support them.

**The outcome:** A set of findings, each tied to tool calls, browser requests, quotes, and screenshots, with impact, confidence, and reproduction notes.

### Steps

1. Set up RiftX and add a model provider key in settings.
2. Create a session and define the browser scope for the authorized target, using host, wildcard domain, or URL rules.
3. Ask the Agent to navigate the target and test the suspected issue, watching tool calls and approvals in the workbench.
4. Review the browser requests, console output, and screenshots the Agent collected for each claim.
5. Accept or reject each finding in the evidence view, and record impact, confidence, and reproduction notes.

### Prompt to paste into your agent

```text
Using RiftX, validate the suspected issue at <target-url> within the authorized browser scope. Produce a list of findings, each linked to browser requests and screenshots with confidence and reproduction notes. Verify that every finding cites at least one captured request or screenshot before you report it.
```

### Caveat

RiftX is a workbench for validation, so it does not replace dedicated scanners and does not set the limits of the assessment for you.

Dual-use notice: only use this on software, sites and systems you own or are authorized to test.

Disclaimer: Third-party repos we don't own or vouch for. AI-generated use cases can be wrong: review everything and run at your own risk. Full text: https://dedupedai.com/disclaimer/

URL: https://dedupedai.com/use-cases/ch1nfo-riftx/validate-web-app-findings-with-evidence/

## How to map an app's attack surface with parallel child agents with RiftX

Repo: [Ch1nfo/RiftX](https://github.com/Ch1nfo/RiftX) | Difficulty: Advanced | Time: 90 minutes | Basis: From the README

Crawl an in-scope app into an inventory, then split review work across child agents on a shared board.

**Who it is for:** A security tester starting an engagement on a large web application who wants a complete map before deep testing.

**The problem:** Mapping links, forms, API routes, and auth boundaries by hand is slow, and parallel review is hard to coordinate across separate chats.

**The outcome:** A structured attack-surface inventory and a board of review tasks, each claimed by a child agent and returned for main-agent review.

### Steps

1. Open a session scoped to the authorized target and perform the first navigation in the browser.
2. Run the crawl tool to collect links, forms including hidden fields, API routes from JS bundles, and authentication boundaries.
3. Review the inventory, then ask the main Agent to propose review tasks on the shared task board.
4. Approve the tasks so child Agents can claim them and run one work item at a time.
5. Review each child result in the Agents and Messages views before marking the collaboration round finished.

### Prompt to paste into your agent

```text
In RiftX, run the crawl tool on the authorized target <target-url> and build a board of review tasks from the inventory. Return the task list with owners, status, and evidence references. Verify that no task is marked complete until the main Agent has accepted the child result.
```

### Caveat

The crawl only covers what the scoped browser can load, and the default limits of 32 admitted work items and 60 autonomous wakes apply to a single collaboration round.

Dual-use notice: only use this on software, sites and systems you own or are authorized to test.

Disclaimer: Third-party repos we don't own or vouch for. AI-generated use cases can be wrong: review everything and run at your own risk. Full text: https://dedupedai.com/disclaimer/

URL: https://dedupedai.com/use-cases/ch1nfo-riftx/map-attack-surface-with-parallel-agents/

## How to test access control with isolated browser identities with RiftX

Repo: [Ch1nfo/RiftX](https://github.com/Ch1nfo/RiftX) | Difficulty: Advanced | Time: 60 minutes | Basis: From the README

Compare anonymous, low-privilege, and high-privilege sessions side by side to find broken access control.

**Who it is for:** A tester on an authorized engagement who needs to check whether low-privilege users can reach high-privilege functions.

**The problem:** Keeping separate logged-in states straight while replaying the same requests is error-prone, and state can leak between accounts.

**The outcome:** A comparison of what each identity can access, backed by captured requests and responses for each identity.

### Steps

1. Define the authorized test accounts in the target scope and note which role each one holds.
2. Ask the Agent to log in each account using its own identity, since each identity has isolated cookies and storage.
3. Have the Agent visit the same restricted endpoints under each identity and capture the requests and response bodies.
4. Review the request_detail and response_body evidence side by side, and mark any access that should have been denied.
5. Store cookie exports only in your own home directory and remove them when the engagement ends.

### Prompt to paste into your agent

```text
Using RiftX identities, compare access to the restricted endpoints of <target-url> for the anonymous, low-privilege, and high-privilege accounts I authorize. Produce a table of endpoint, identity, status, and captured evidence. Verify that each identity used its own isolated cookies and storage before you report a result.
```

### Caveat

RiftX keeps sessions and evidence in the current user's home directory, so you are responsible for protecting that data on shared machines.

Risk, credentials: Test account logins, cookies, and exported cookie files are sensitive; use only accounts you are authorized to test and delete exports after the engagement.

Dual-use notice: only use this on software, sites and systems you own or are authorized to test.

Disclaimer: Third-party repos we don't own or vouch for. AI-generated use cases can be wrong: review everything and run at your own risk. Full text: https://dedupedai.com/disclaimer/

URL: https://dedupedai.com/use-cases/ch1nfo-riftx/test-access-control-across-identities/

## How to research known vulnerabilities for a fingerprinted product with RiftX

Repo: [Ch1nfo/RiftX](https://github.com/Ch1nfo/RiftX) | Difficulty: Intermediate | Time: 30 minutes | Basis: From the README

Look up public CVEs and advisories for a product version found during testing, with queries screened first.

**Who it is for:** A tester who has fingerprinted a web product version on an authorized target and needs known issues and references quickly.

**The problem:** Searching the public web for CVE details and exploit references by hand is slow, and it is easy to paste engagement details into a third-party search.

**The outcome:** A short list of relevant CVEs and references for the fingerprinted version, each with a source link and a note on whether it applies.

### Steps

1. Open a session and note the product name and exact version found during testing.
2. Ask the Agent to run web_search for known vulnerabilities for that version, using only product and version text.
3. Ask the Agent to run web_fetch on the most relevant advisory pages, and for bare CVE ids to pull structured data.
4. Check each result against the fingerprint you captured on the target before you treat it as applicable.
5. Keep the confirmed references as evidence in the finding notes.

### Prompt to paste into your agent

```text
In RiftX, research known vulnerabilities for <product-name> version <version-string> using web_search and web_fetch. Return a list of CVE ids, sources, and whether each one matches the fingerprint. Verify that no query contains credentials, tokens, or target-specific secrets.
```

### Caveat

RiftX screens out credential-shaped queries, but a public CVE match still has to be confirmed against the actual target before it is reported.

Dual-use notice: only use this on software, sites and systems you own or are authorized to test.

Disclaimer: Third-party repos we don't own or vouch for. AI-generated use cases can be wrong: review everything and run at your own risk. Full text: https://dedupedai.com/disclaimer/

URL: https://dedupedai.com/use-cases/ch1nfo-riftx/research-known-vulnerabilities-for-a-product/