> For clean Markdown of this page, append .md to its URL. For the complete documentation index, see https://www.superagent.sh/llms.txt.


Schedule repository Red Team runs and send newly created findings from one repository to Cursor for reviewed remediation.

# Build an always-on pentester with Cursor

Build an always on security loop for a repository. Superagent tests the
repository on a schedule and sends newly created findings from that exact
Repository to Cursor. Cursor investigates each finding, reproduces qualifying
exploit paths, prepares tested fixes, and leaves every pull request for CI and
human review.

## Prerequisites

- A repository connected through the Superagent Security GitHub App
- A Cursor Automation connected to the repository
- A Superagent organization API key available to Cursor as
  `SUPERAGENT_API_KEY`
- A repository reviewer for every proposed change

## 1. Schedule repository Red Team runs

1. [Connect GitHub](https://www.superagent.sh/docs/connect/github) and give the Superagent Security
   app access to the repository.
2. Open **Repository** and select the repository Cursor will patch.
3. Enable **Red teaming** in the repository settings.
4. Choose a trigger: every release or prerelease, release tags, daily, weekly,
   or monthly.
5. Add a repository specific goal prompt when the campaign needs a narrower
   scope.
6. Select **New run** once to confirm the repository access and goal before
   relying on the trigger.

Superagent clones the repository into an isolated sandbox and runs each
campaign with the source as context. Prime independently verifies candidates
before creating findings. Findings include the evidence and reproduction
context Cursor needs to decide whether remediation is justified.

## 2. Connect Cursor to Superagent MCP

Add the Superagent server to Cursor's `mcp.json`:

```json
{
  "mcpServers": {
    "superagent": {
      "url": "https://www.superagent.sh/mcp",
      "headers": {
        "Authorization": "Bearer ${env:SUPERAGENT_API_KEY}"
      }
    }
  }
}
```

Set `SUPERAGENT_API_KEY` in the environment that launches Cursor. Do not put
the key in chat, source control, or the MCP URL. See
[Set up Cursor](https://www.superagent.sh/docs/connect/cursor) for the complete connection test.

## 3. Create the Cursor Automation

Create a Cursor Automation with:

- The selected repository as its working repository
- A webhook trigger
- Superagent MCP enabled
- Permission to create branches, run tests, and open pull requests
- No permission to merge or deploy without the normal review controls

Copy the webhook URL and the authentication value generated by Cursor. You will
store the authentication value as an encrypted Superagent webhook header.

## 4. Route findings from this Repository

Open **Webhooks** in Superagent and create a target:

1. Use the Cursor Automation webhook URL as the destination.
2. Add Cursor's authentication value as an `Authorization` custom header.
3. Subscribe to `finding.created`.
4. Open **Sources**, expand **Repositories**, and select the exact repository
   you configured above.
5. Save the target and send a test event.

The `finding.created` event starts the automation when a finding is created,
without waiting for automated triage. Triage fields can still be empty or
pending; Cursor should retrieve the latest finding through MCP and apply its
own remediation gate. Use the singular event name `finding.created`, not
`findings.created`.

Selecting the exact repository prevents findings from unrelated targets from
starting this automation. Select **All Repositories** only when the same
automation intentionally owns every current and future repository.

![Cursor Automation setup showing the webhook, instructions, and Superagent MCP tools](https://www.superagent.sh/images/changelog-september-2026-6.png)

## 5. Give Cursor a strict remediation gate

Use instructions like these in the Cursor Automation:

```agent-prompt
Triage the incoming security advisory for the `superagent-ai/app` repository.

The objective is to remediate only **critical security vulnerabilities that an untrusted third party can exploit through a realistic attack path**. Do not create pull requests for ordinary bugs, defense-in-depth improvements, theoretical risks, or vulnerabilities that require trusted internal, administrative, local, or repository access.

1. Investigate the advisory and verify:
   - Whether the reported behavior is reproducible.
   - Whether it crosses a meaningful security or tenant boundary.
   - What access and prerequisites an attacker needs.
   - Whether an untrusted third party can exploit it through a reachable production interface.
   - Whether successful exploitation could cause critical impact, such as remote code execution, authentication bypass, unauthorized privileged access, cross-tenant compromise, sensitive-data disclosure at scale, or exposure of secrets.
   - Whether the vulnerable code path is actually reachable. A vulnerable dependency or scanner result alone is not sufficient.

2. Classify the finding as one of the following:
   - **Critical and externally exploitable**
   - **Valid but below the remediation threshold**
   - **False positive**
   - **Intended behavior**
   - **Accepted risk**
   - **Won't fix**

3. Apply this strict remediation gate:

   Create or modify a pull request only when there is clear evidence that the finding is both:

   - A critical security vulnerability; and
   - Exploitable by an untrusted third party through a realistic, reachable attack path.

   If either condition is not met:
   - Do not modify the code.
   - Do not create or continue a pull request.
   - Update the finding in Superagent MCP with the appropriate status: **Accepted Risk**, **False Positive**, or **Won't Fix**.
   - Document the reasoning, including the missing exploit path, required trusted access, limited impact, or other reason it does not meet the remediation threshold.
   - Stop.

4. If the finding meets the remediation gate, search open pull requests to determine whether it is already being addressed.

5. If a relevant pull request exists:
   - Do not create a duplicate.
   - Review and continue the existing remediation when possible.

6. If no relevant pull request exists:
   - Create a branch named `security/<descriptive-name>`.
   - Implement the smallest complete fix.
   - Add or update tests that demonstrate the vulnerability and verify the remediation.
   - Open a pull request explaining the attack path, prerequisites, critical impact, root cause, and remediation. Avoid including dangerous proof-of-concept details unnecessarily.

7. For every remediation pull request:
   - Run a Bugbot review on the patch with a comment "@cursor review".
   - Address all valid security concerns, bugs, and regressions it identifies.
   - Re-run the relevant tests after review-driven changes.
   - Mark the pull request as ready for review.
   - Assign it to Ismail Pelaseyed (`homanp`).
   - Use labels (`critical`, `high`, `medium`, or `low`).

8. Once remediation is complete, update the finding in Superagent MCP to **Resolved** and include the pull request link.

A scanner-reported "bug," code-quality issue, best-practice violation, or hypothetical weakness must not result in a pull request unless it satisfies the critical, externally exploitable remediation gate.
```

The connected MCP server exposes the current structured report operation and
schema. Use that schema instead of inventing report fields in the automation
prompt.

## 6. Verify the complete loop

1. Confirm the webhook test starts exactly one Cursor Automation.
2. Start a manual repository Red Team run.
3. Review the report and confirm it creates a new finding.
4. Confirm the repository's `finding.created` event starts the Cursor Automation
   without requiring automated triage to finish.
5. Confirm Cursor retrieves the finding through MCP and applies the remediation
   gate.
6. Verify that a qualifying issue produces a tested pull request, while a weak
   or unreachable issue produces only a structured disposition.
7. Require CI and human review before merge.

## Next steps

- [Configure repositories](https://www.superagent.sh/docs/concepts/repositories)
- [Run repository Red Team](https://www.superagent.sh/docs/security-workers/red-team/repositories)
- [Set up Cursor](https://www.superagent.sh/docs/connect/cursor)

---
Source: https://www.superagent.sh/docs/use-cases/continuous-adversarial-testing-with-cursor
Index: https://www.superagent.sh/llms.txt