Build an always on security loop for a repository. Superagent tests the repository on a schedule, triages the findings, and sends findings from that exact Repository to Cursor. Cursor 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 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. When the repository exposes a service the sandbox can start, Prime can use Nuclei against that live surface and independently verify 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:

{
  "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 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.triage_completed.
4. Open Sources, expand Repositories, and select the exact repository you configured above.
5. Save the target and send a test event.

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.

5. Give Cursor a strict remediation gate

Use instructions like these in the Cursor Automation:

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 allow automated triage to complete.
4. Confirm a matching finding starts the Cursor Automation.
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
• Run repository Red Team
• Set up Cursor