Usage & Examples

All examples below work in any supported tool — Cursor, Claude Code, Codex, GitHub Copilot, Antigravity, or Devin. The prompt syntax may differ slightly (some tools use @agent-name, others use natural language), but the intent is the same. In Devin the agents are addressed as namespaced subagents — see Devin (Desktop & CLI).

Scenario 1: Scan a branch before merging

You added endpoints and want to know what they expose before the PR is merged.

Use the bright-application-testing agent to scan this app

The agent reads your routes and controllers, works out realistic request bodies, excludes endpoints whose effects can't be undone, registers the rest, picks relevant tests for each endpoint, and scans. You get findings grouped by severity with method, URL, evidence, and the endpoint each belongs to.

Scenario 2: Scan a deployed environment

Your app runs on staging — you don't want anything started locally.

Scan https://staging.acme.example with bright-application-testing.
It's already running — don't start anything.

Given a URL, the agent health-checks it and skips startup entirely. A publicly reachable target is scanned directly; anything private goes through a Repeater that runs on your machine.

Scenario 3: Get past the login page

Most of an API's surface sits behind auth. An unauthenticated scan never sees it.

Scan this API with bright-application-testing.
Test credentials are in fixtures/users.json.

The agent finds your login flow, builds an auth object, and verifies it works before saving it. It sets re-auth on 401/403 so sessions expiring mid-scan don't quietly turn the rest of the run into noise.

Scenario 4: Fix findings and prove they're gone

Use bright-remediation-loop on this repo.
Redeploy with `make deploy-dev`.

The agent scans, traces each finding from the request to the vulnerable sink, applies the smallest fix, redeploys, then re-runs the same scan and compares. Findings that disappear are reported as fixed; ones that survive stay open for the next round. You get the list of files changed alongside evidence that each change worked.

⚠️

Tell the agent how to redeploy. Without that it can scan and write fixes but can't verify them — it will stop and ask rather than reporting unverified edits as remediated.

Scenario 5: Non-standard startup

If your app doesn't start with docker compose, tell the agent how it runs:

Bring it up with `helm install acme ./chart --values dev.yaml`, then scan it.

The agent follows your instructions instead of guessing from the repository structure.

Scenario 6: Naming the project

With an org-wide token (not project-scoped), name the Bright project explicitly:

Use bright-application-testing to scan this app, Bright project "acme-api"

With a project-scoped token, drop that part — there's only one project and the agent uses it automatically.

What you get back

From bright-application-testing

• Detected tech stack and startup command (or the supplied target URL)
• Authenticated vs. unauthenticated target surface
• Bright project and Repeater identifiers used
• Scan groups, test tags, and completion state
• Findings grouped by severity and endpoint — with method, URL, evidence, and next steps
• Blockers that prevented deeper coverage (if any)

From bright-remediation-loop

Everything above, plus:

• Rounds completed (up to 5)
• Fixes applied and files changed
• Findings that disappeared after validation (with proof)
• Findings that remained open after the final round
• Blockers that prevented safe remediation

Tips

• Start with bright-application-testing to understand your exposure, then switch to bright-remediation-loop when you're ready to fix.
• Provide credentials explicitly when the app needs auth — the agent is good at detecting login flows, but pointing it at a credentials file or env var saves time.
• Private targets need a Repeater — the agent creates and tears one down automatically. Make sure BRIGHT_HOSTNAME is reachable from your machine (outbound HTTPS).
• Exclude nothing manually — the agent already excludes endpoints with irreversible side effects (destructive actions, notifications, payment triggers). If it's too aggressive, tell it what's safe.

More examples

The full set of usage patterns — including Cloud Agents, permission-less runs, and clone-based setups — lives in the per-tool READMEs:

• Cursor advanced usage
• Claude Code advanced usage