# Billing & Tiers
Source: https://docs.corridor.dev/administration/billing
Manage your Corridor subscription, pricing tiers, and payment methods.
Corridor offers different plans (tiers) to accommodate individual developers up to large enterprises. Each tier comes with a set of features and usage limits.
## Pricing tiers
| Tier | Price | Projects | PR Reviews | Key Features |
| -------------- | -------------- | --------- | ------------- | ----------------------------------------- |
| **Pro** | \$20/month | 5 | 100/month | PR reviews, MCP guardrails, IDE extension |
| **Team** | \$40/dev/month | 20 | 100/dev/month | Custom guardrails, team visibility |
| **Enterprise** | Contact Sales | Unlimited | Unlimited | Chats, zero retention, SSO |
### Free trial
Corridor provides a free trial period for new users, allowing you to test core features at no cost:
* Real-time security reviews of pull requests
* Secure code generation through Corridor's MCP
* Auto-generated guardrails
* Up to 5 projects and 100 pull request reviews per month
After the trial, you can decide to subscribe to a paid plan.
### Pro (Individual Developer)
For individual developers:
* Real-time security reviews of GitHub pull requests
* Secure code generation via Corridor's MCP server in your IDE
* Auto-generated security guardrails
* Up to 5 projects
* 100 PR reviews per month
* No team collaboration features on this tier
### Team
For teams that need more control:
* Everything in Pro
* Deploy Corridor across your team—invite multiple users to a shared workspace
* Custom guardrails and context documents—tailor security rules to your organization
* Full visibility into AI coding activity across your team
* Up to 20 projects
* 100 PR reviews per developer per month
* Admin/member roles, team dashboard, shared findings
### Enterprise
For organizations with advanced requirements:
* Everything in Team
* **Chat with your codebase**: Interactive AI security assistant for investigating findings and discovering vulnerabilities
* **Enterprise security**: Zero data retention mode (Corridor doesn't store code), single-tenant deployment options for on-prem or private cloud
* **Unlimited scale**: Unlimited projects, repositories, and PR reviews
* SSO integration
* Dedicated support and help with onboarding (including custom guardrail development assistance)
Contact [sales@corridor.dev](mailto:sales@corridor.dev) for Enterprise pricing.
## Billing model
Corridor uses seat-based billing on Team and Enterprise plans:
```
Monthly cost = Number of developers × Seat price
```
### How developers are counted
Your developer count is based on unique developers interacting with Corridor in a given month:
* IDE extension users
* Corridor dashboard users
* Submitters of pull requests reviewed by Corridor
## Annual billing
Save 20% with annual billing:
* Pro: \$16/month (billed annually)
* Team: \$32/dev/month (billed annually)
Contact sales for annual Enterprise agreements.
## Viewing your subscription
1. Go to **Team Settings → Billing**
2. View your current tier and developer count
3. See upcoming billing date and amount
## Changing your plan
### Upgrading
1. Go to **Team Settings → Billing**
2. Click **Change Plan**
3. Select the new tier
4. Confirm the upgrade
Upgrades take effect immediately. You're charged a prorated amount for the remainder of the billing period.
### Downgrading
1. Go to **Team Settings → Billing**
2. Click **Change Plan**
3. Select the new tier
4. Confirm the downgrade
Downgrades take effect at the end of your current billing period.
Downgrading may disable features. Ensure you're within the new tier's limits (projects, team members) before downgrading.
## Managing payment
### Adding a payment method
1. Go to **Team Settings → Billing**
2. Click **Payment Methods**
3. Click **Add Payment Method**
4. Enter your card details
5. Click **Save**
### Invoices
1. Go to **Team Settings → Billing**
2. Click **Invoices**
3. View or download past invoices
## Vercel Marketplace
Corridor is available on the [Vercel Marketplace](https://vercel.com/integrations/corridor) for easy installation and unified billing.
### Installing from Vercel
1. Visit the Vercel Integrations page and search for "Corridor"
2. Click **Install** and select your Vercel team
3. Accept terms and select your plan
4. Connect your GitHub account and select repositories
### Vercel billing
When installed through Vercel:
* All charges appear on your Vercel invoice
* No separate payment methods needed
* Vercel credits may apply to Corridor charges
## Cancellation
### Canceling your subscription
1. Go to **Team Settings → Billing**
2. Click **Cancel Subscription**
3. Select a cancellation reason
4. Confirm cancellation
### What happens on cancellation
* Access continues until end of billing period
* Data is retained for 30 days after expiration
* You can reactivate anytime within 30 days
* After 30 days, data is permanently deleted
Export any data you need before your subscription ends.
## Tier feature summary
| Feature | Pro | Team | Enterprise |
| ---------------------------- | -------------- | ------------- | ------------- |
| **Team members** | 1 | Up to 20 | Custom |
| **Projects** | 5 | 20 | Unlimited |
| **PR reviews** | 100/month | 100/dev/month | Unlimited |
| **Guardrails** | Auto-generated | Custom + Auto | Custom + Auto |
| **Custom context** | - | ✓ | ✓ |
| **MCP compliance** | ✓ | ✓ | ✓ |
| **Team visibility** | - | ✓ | ✓ |
| **Chats** | - | - | ✓ |
| **SSO** | - | - | ✓ |
| **Zero data retention** | - | - | ✓ |
| **Single-tenant deployment** | - | - | ✓ |
## FAQ
### When am I charged?
You're charged at the beginning of each billing period (monthly or annually).
### What payment methods do you accept?
We accept all major credit cards via Stripe. Enterprise customers can pay by invoice.
### Can I get a refund?
We offer refunds within 7 days of initial purchase. Contact [support@corridor.dev](mailto:support@corridor.dev).
### Is there a free trial?
Yes, all plans include a free trial period. Start with any tier risk-free.
## Need help?
* **Billing questions**: [billing@corridor.dev](mailto:billing@corridor.dev)
* **Enterprise sales**: [sales@corridor.dev](mailto:sales@corridor.dev)
* **General support**: [support@corridor.dev](mailto:support@corridor.dev)
## Next steps
Track security metrics
Configure security guardrails
# MDM Support Guide
Source: https://docs.corridor.dev/administration/mdm-support
Provision Corridor across your organization using Mobile Device Management tools.
MDM rollout is available on **Enterprise** plans only.
If your enterprise uses an MDM (Mobile Device Management) tool, you can provision Corridor across all employees automatically. With MDM, developers don't need to separately install the Corridor extension or sign up—everything is handled for them.
## Supported platforms
| MDM | OS Support |
| ------------ | -------------- |
| Kandji / Iru | macOS |
| Intune | macOS, Windows |
| JAMF | macOS |
### Supported IDEs/coding agents
* VS Code
* Devin Desktop
* Cursor
* Claude Code (via Corridor CLI)
* Codex (via Corridor CLI)
* Factory Droid (via Corridor CLI)
## Prerequisites
* **Enterprise tier subscription** to Corridor. You can verify this at [app.corridor.dev/teams](https://app.corridor.dev/teams)
* **Team Owner role** in Corridor. You can verify this at [app.corridor.dev/teams](https://app.corridor.dev/teams)—you should see "Owner" next to your email
## Verifying a domain
In order to use the MDM scripts, you must verify an email domain for your team. Corridor will only provision users with the email domain you have verified.
Go to [app.corridor.dev/teams](https://app.corridor.dev/teams).
Go to the **Domain Verification** section and enter your organization's domain name (e.g., `acme.com`).
Copy the DNS TXT record provided and add it to your DNS provider.
## Creating a universal team token
In order to use the MDM scripts, you must create a universal team token to identify your team and verify your team admin access.
Go to [app.corridor.dev/teams](https://app.corridor.dev/teams).
Under **Universal Team Tokens**, click **Generate New Tokens**. Add a token name and select an expiration date.
Copy the universal team token—you'll use it in the MDM scripts below.
## JAMF (macOS only)
For JAMF, you must create a configuration profile to push the `User email` and `Device serial` fields to each managed computer.
### Creating a configuration profile
#### Prerequisites
To set up a JAMF configuration profile, you must have:
* A push certificate in JAMF Pro. [See instructions here](https://learn.jamf.com/r/en-US/jamf-pro-documentation-current/Push_Certificates#concept-6218).
* The `Enable certificate-based authentication` and `Enable push notifications` settings configured in Jamf Pro. For more information, see [Security Settings](https://learn.jamf.com/en-US/bundle/jamf-pro-documentation-current/page/Security_Settings.html#ID-000185c4).
To create the configuration profile:
In JAMF, go to **Computers** -> **Configuration Profiles**. Click **New**.
Set a name like 'Push plist for Corridor' with level 'Computer Level' and Distribution Method 'Install automatically'.
Set 'Scope' to 'All computers', or just all the computers you want to have access to Corridor.
Go back to 'Options', and search for 'Application & Custom Settings'. Click the arrow underneath, and click 'Upload'.
Click 'Add'. Set the preference domain to `dev.corridor.mdm` and set the file contents to
```xml theme={null}
UserEmail
$EMAIL
SerialNumber
$SERIALNUMBER
```
Or download [dev.corridor.mdm.plist](https://github.com/CorridorSecurity/CorridorSecurity/blob/main/mdm/dev.corridor.mdm.plist)
and upload those contents.
Save your configuration and check that it was pushed to your devices.
### Add the Corridor script
In JAMF, go to **Settings** and search for **Scripts**. It should be under **Computer management**.
Download the Corridor JAMF script:
```bash theme={null}
curl https://raw.githubusercontent.com/CorridorSecurity/CorridorSecurity/refs/heads/main/mdm/jamf-macos.sh -o jamf-macos.sh
```
Replace the `CORRIDOR_TEAM_TOKEN` value at the top of the file with the universal team token you generated.
Name the script something along the lines of `Corridor Installation Script`, and upload the script with the shell/bash language option.
Save the script.
### Create a policy
In JAMF, go to **Computers** and then **Policies**. It should be under **Content management**. Click 'New'.
Set the policy name to be 'Corridor Installation Policy'. Select 'Recurring Check-in' as the trigger (unless otherwise desired), with the execution frequency as 'Once per computer'.
Click 'Automatically re-run policy on failure'. Set the scope as desired (All computers or specific computers).
In options, click **Scripts** and choose 'Configure Scripts'. Add the `Corridor Installation Script` you created in the previous step, and save the policy.
Now, just wait for the scripts to run on the computers the policy is pushed out to. Once users restart their IDEs, they should be automatically signed in to Corridor and the extension installed.
## Kandji / Iru (macOS only)
For Kandji (including Iru, Kandji's new UI), you must deploy a custom profile that writes Kandji's global variables to each device before running the Corridor script.
Iru does not include classic Kandji's **Global Variables** feature, so global variables are never written to devices unless you deploy them with a Custom Profile. The steps below use Kandji's official Global Variables profile and work in both classic Kandji and Iru.
### Create a custom profile
Download the official [Global Variables.mobileconfig](https://github.com/kandji-inc/support/blob/main/Global%20Variables/Global%20Variables.mobileconfig) provided by Kandji. When the profile is pushed to a device, Kandji substitutes its built-in global variables (including `$EMAIL` and `$SERIAL_NUMBER`) and writes them to `/Library/Managed Preferences/io.kandji.globalvariables.plist` — the file the Corridor Kandji script reads at runtime.
In Kandji or Iru, go to **Library** and add a **Custom Profile**.
Upload the `Global Variables.mobileconfig` file to the Custom Profile and save it.
Assign the Custom Profile to the Blueprint(s) where you want to deploy Corridor — the same Blueprint(s) you assign the Corridor script to in the next section.
If you author your own profile instead of using Kandji's, the keys **must** be named exactly `EMAIL` and `SERIAL_NUMBER` — these are the names the Corridor Kandji script reads at runtime. If your variables use different keys, you will have to change the `DEVICE_SERIAL` and `USER_EMAIL` variables in the script (the `PlistBuddy` print statements) to match.
### Add the Corridor script
In Kandji or Iru, go to **Library** and add a **Custom Script**. Assign it to the same Blueprint(s) as the Custom Profile above. Select **Execution Frequency: Run once per device**.
Download the Corridor Kandji script:
```bash theme={null}
curl https://raw.githubusercontent.com/CorridorSecurity/CorridorSecurity/refs/heads/main/mdm/kandji-macos.sh -o kandji-macos.sh
```
Replace the `CORRIDOR_TEAM_TOKEN` value at the top of the file with the universal team token you generated.
Upload the file with the correct `CORRIDOR_TEAM_TOKEN` to Kandji and click **Save**.
## Intune
Intune scripts support both macOS and Windows. You must first generate a Microsoft Graph token with the right permissions—this token is used to retrieve the device email.
### Generate a Microsoft Graph token
Go to [Microsoft Graph Explorer](https://developer.microsoft.com/en-us/graph/graph-explorer) and sign in.
Click **Modify Permissions** and consent to `User.Read` permissions. This requires Admin consent.
Refresh the page, then click **Access token** and copy the Microsoft Graph API access token.
### Windows
On [intune.microsoft.com](https://intune.microsoft.com), go to **Devices → Scripts and remediations** under Manage Devices.
Click **Platform scripts → Add → Windows 10 and Later**. Set a name and description.
Download the Corridor Intune Windows script:
```bash theme={null}
curl https://raw.githubusercontent.com/CorridorSecurity/CorridorSecurity/refs/heads/main/mdm/intune-windows.ps1 -o intune-windows.ps1
```
In the script, replace the `CORRIDOR_TEAM_TOKEN` value with your universal token, and replace the `GRAPH_API_TOKEN` value with the Microsoft Graph API access token.
Select **Yes** for "Run this script using the logged on credentials", **No** for "Enforce script signature check", and **No** for "Run script in 64 bit Powershell Host".
Assign the script to the selected group of devices and click **Save**. Sync all devices with bulk device actions to force the script to run.
### macOS
On [intune.microsoft.com](https://intune.microsoft.com), go to **Devices → Scripts and remediations** under Manage Devices.
Click **Platform scripts → Add → macOS**. Add a name and description.
Download the Corridor Intune macOS script:
```bash theme={null}
curl https://raw.githubusercontent.com/CorridorSecurity/CorridorSecurity/refs/heads/main/mdm/intune-macos.sh -o intune-macos.sh
```
In the script, replace the `CORRIDOR_TEAM_TOKEN` value with your universal token, and replace the `GRAPH_API_TOKEN` value with the Microsoft Graph API access token.
Select **Yes** for "Run script as signed-in user" and **1 time** for "Max number of times to retry if script fails".
Assign the correct groups to the script and click **Save**. Sync all devices with bulk device actions to force the script to run.
# SSO & Okta
Source: https://docs.corridor.dev/administration/sso-okta
Set up single sign-on with Okta for your Corridor enterprise account.
SSO is available on **Enterprise** plans.
Corridor supports SSO with Okta for customers on an enterprise plan.
## Setup
To set up Corridor SSO with Okta for your organization, follow these steps:
Go to the Okta Admin dashboard and navigate to the **Applications** page.
Click **Create App Integration**, and select **OIDC - OpenID Connect** and **Web Application**.
Name your integration, and set **Sign-in redirect URIs** to:
```
https://auth.corridor.dev/login/callback
```
Select **Allow everyone in your organization to access** (or the appropriate level of access for your organization). Select **Enable immediate access with Federation Broker Mode**, then click **Save**.
Copy the **Client ID** and **Client Secret** to your clipboard.
Send the Corridor team your **Client ID**, **Client Secret**, and **Okta domain** (`*.okta.com`) at [support@corridor.dev](mailto:support@corridor.dev) to complete the setup process.
## Additional resources
You can also view [Okta's documentation](https://help.okta.com/en-us/content/topics/apps/apps_app_integration_wizard_oidc.htm) for a full set of instructions on how to set up SSO.
# IP Whitelisting
Source: https://docs.corridor.dev/administration/whitelist
Corridor static IP addresses for firewall and network allowlist configuration.
If your organization restricts inbound network traffic — for example, to a self-hosted instance or an internal service that Corridor needs to reach — you may need to allowlist the IP addresses used by the Corridor API.
## Corridor static IP
Add the following IP addresses to your firewall allowlist:
```text theme={null}
3.232.214.155
34.228.204.158
35.168.92.167
```
These are the static IP addresses used by the Corridor production environment for all outbound connections.
## When to allowlist
You need to add these IPs if:
* You have an **IP-restricted API** or webhook endpoint that Corridor calls back to
* Your network security policy requires explicit allowlisting of third-party services
## Questions?
If you need additional IP addresses or have questions about network configuration, contact [support@corridor.dev](mailto:support@corridor.dev).
# API Reference
Source: https://docs.corridor.dev/api/reference
Programmatic access to Corridor findings, guardrails, PR reviews, team settings, and dashboard data.
Corridor exposes a REST API that you can use to integrate with CI/CD pipelines, custom dashboards, or other tools. All endpoints are available via API tokens.
## Authentication
Include your API token in the `Authorization` header:
```bash theme={null}
curl -H "Authorization: Bearer cor_your_token_here" \
https://app.corridor.dev/api/teams
```
You can generate API tokens from **Profile > API Tokens** in the Corridor dashboard. Tokens use the `cor_` prefix and have the same access as the user who created them.
API tokens cannot perform admin operations. Those require a standard user session.
## Base URL
```
https://app.corridor.dev/api
```
All paths below are relative to this base URL.
***
## Findings
Retrieve and manage security findings across your projects.
### Search findings
```
GET /findings/search
```
| Parameter | Type | Required | Description |
| --------------- | ------ | -------- | ------------------------------------------------------------- |
| `teamId` | string | Yes | Team ID to search within |
| `search` | string | No | Search term (matches title, file path, or CWE) |
| `state` | string | No | Filter by state: `open`, `closed`, or `potential` |
| `createdAfter` | string | No | Include findings created at or after this ISO-8601 timestamp |
| `createdBefore` | string | No | Include findings created at or before this ISO-8601 timestamp |
| `limit` | number | No | Max results (default 10, max 50) |
```bash theme={null}
curl -H "Authorization: Bearer cor_..." \
"https://app.corridor.dev/api/findings/search?teamId=TEAM_ID&state=open&createdAfter=2025-01-01T00:00:00Z&createdBefore=2025-01-31T23:59:59Z&limit=20"
```
**Response:**
```json theme={null}
[
{
"id": "finding-uuid",
"title": "SQL Injection in userController.ts",
"affectedFile": "src/controllers/userController.ts",
"cwe": "CWE-89",
"severity": "critical",
"state": "open",
"createdAt": "2025-01-15T10:30:00Z",
"projectId": "project-uuid",
"projectName": "my-app"
}
]
```
### Get finding
```
GET /findings/:id
```
Returns the full finding with related project, rule, scan, and PR review data.
```bash theme={null}
curl -H "Authorization: Bearer cor_..." \
https://app.corridor.dev/api/findings/FINDING_ID
```
### Update finding
```
PUT /findings/:id
```
| Field | Type | Description |
| ---------------------- | ------ | -------------------------------------------------------------------- |
| `state` | string | `open` or `closed` |
| `closedReason` | string | Reason for closing |
| `closedReasonCategory` | string | `false_positive`, `risk_accepted`, `vulnerability_fixed`, or `other` |
| `severity` | string | `critical`, `high`, `medium`, or `low` |
| `title` | string | Updated title |
| `description` | string | Updated description |
| `cwe` | string | CWE identifier |
| `affectedFile` | string | File path |
All fields are optional. Include only the fields you want to update.
```bash theme={null}
curl -X PUT -H "Authorization: Bearer cor_..." \
-H "Content-Type: application/json" \
-d '{"state": "closed", "closedReasonCategory": "false_positive", "closedReason": "Not exploitable in this context"}' \
https://app.corridor.dev/api/findings/FINDING_ID
```
### Delete finding
```
DELETE /findings/:id
```
***
## Guardrails
Guardrails are security rules that Corridor enforces during code reviews and real-time analysis. They are managed per-project as "reports."
### List guardrails for a project
```
GET /projects/:id/reports
```
Returns all guardrails (reports) and rulesets attached to a project.
```bash theme={null}
curl -H "Authorization: Bearer cor_..." \
https://app.corridor.dev/api/projects/PROJECT_ID/reports
```
**Response:**
```json theme={null}
{
"reports": [
{
"id": "report-uuid",
"name": "SQL Injection Prevention",
"guardrail": "Never use string concatenation for SQL queries...",
"type": "guardrail",
"createdAt": "2025-01-10T08:00:00Z"
}
],
"ruleset": []
}
```
### Create a guardrail
```
POST /projects/:id/reports
```
| Field | Type | Required | Description |
| ----------- | ------ | -------- | ---------------------------------- |
| `name` | string | Yes | Guardrail name |
| `guardrail` | string | Yes | The guardrail rule text |
| `type` | string | No | `guardrail` (default) or `context` |
```bash theme={null}
curl -X POST -H "Authorization: Bearer cor_..." \
-H "Content-Type: application/json" \
-d '{"name": "No hardcoded secrets", "guardrail": "Never commit API keys, passwords, or secrets directly in source code. Use environment variables or a secrets manager."}' \
https://app.corridor.dev/api/projects/PROJECT_ID/reports
```
### Generate a guardrail with AI
```
POST /projects/:id/guardrails/generate
```
| Field | Type | Required | Description |
| ------------- | ------ | -------- | ----------------------------------------------------------------- |
| `description` | string | Yes | Plain-language description of the guardrail (max 1000 characters) |
Returns a `taskId` you can use to track generation progress.
```bash theme={null}
curl -X POST -H "Authorization: Bearer cor_..." \
-H "Content-Type: application/json" \
-d '{"description": "Prevent use of eval() and similar dynamic code execution functions"}' \
https://app.corridor.dev/api/projects/PROJECT_ID/guardrails/generate
```
### Update a guardrail
```
PUT /projects/:id/reports/:reportId
```
| Field | Type | Description |
| ----------- | ------ | ------------------------ |
| `name` | string | Updated name |
| `guardrail` | string | Updated rule text |
| `type` | string | `guardrail` or `context` |
### Delete a guardrail
```
DELETE /projects/:id/reports/:reportId
```
### List guardrail packs
```
GET /projects/:id/packs
```
Returns the security packs (curated guardrail collections) attached to a project.
***
## PR Reviews
Access pull request review results and AI analysis.
### List PR reviews
```
GET /teams/:id/pr-reviews
```
| Parameter | Type | Description |
| ----------- | ------ | --------------------- |
| `limit` | number | Max results |
| `offset` | number | Pagination offset |
| `type` | string | Filter by review type |
| `sortBy` | string | Sort field |
| `sortOrder` | string | `ASC` or `DESC` |
```bash theme={null}
curl -H "Authorization: Bearer cor_..." \
"https://app.corridor.dev/api/teams/TEAM_ID/pr-reviews?limit=10&sortOrder=DESC"
```
**Response:**
```json theme={null}
{
"data": [
{
"id": "pr-review-uuid",
"title": "SQL Injection in userController.ts",
"severity": "high",
"state": "open",
"affectedFile": "src/controllers/userController.ts",
"createdAt": "2025-01-15T10:30:00Z",
"cwe": "CWE-89",
"prReview": { "id": "...", "github_pr_id": 123 },
"project": { "id": "...", "name": "my-app" }
}
],
"pagination": {
"page": 1,
"limit": 10,
"total": 42,
"totalPages": 5,
"hasNext": true,
"hasPrev": false
}
}
```
### Get PR review
```
GET /teams/:id/pr-reviews/:prReviewId
```
Returns the full PR review including comments, findings, and metadata.
### Get PR review by PR number
```
GET /teams/:id/pr-reviews/by-pr
```
Look up PR reviews by pull request number and repository name.
| Parameter | Type | Required | Description |
| ------------- | ------- | -------- | ------------------------------------------------------------------------------------ |
| `prNumber` | integer | Yes | The pull request / merge request number |
| `repoName` | string | Yes | Repository name (matched against project name or the repo portion of the GitHub URL) |
| `fullHistory` | boolean | No | When `true`, returns all complete reviews for the PR. Default: only the most recent. |
**Default (most recent review):**
```bash theme={null}
curl -H "Authorization: Bearer cor_..." \
"https://app.corridor.dev/api/teams/TEAM_ID/pr-reviews/by-pr?prNumber=42&repoName=my-app"
```
```json theme={null}
{
"id": "pr-review-uuid",
"body": "Review summary...",
"github_pr_id": 42,
"publish_status": "SUCCEEDED",
"event": "COMMENT",
"findings": [
{
"id": "finding-uuid",
"title": "SQL Injection in db.ts",
"severity": "critical",
"state": "open"
}
],
"labels": [],
"task": {
"id": "task-uuid",
"project": { "id": "project-uuid", "name": "my-app" }
},
"createdAt": "2025-01-15T10:30:00Z"
}
```
**Full history (`fullHistory=true`):**
```bash theme={null}
curl -H "Authorization: Bearer cor_..." \
"https://app.corridor.dev/api/teams/TEAM_ID/pr-reviews/by-pr?prNumber=42&repoName=my-app&fullHistory=true"
```
```json theme={null}
{
"reviews": [
{ "id": "review-2", "body": "...", "createdAt": "2025-01-16T08:00:00Z" },
{ "id": "review-1", "body": "...", "createdAt": "2025-01-15T10:30:00Z" }
],
"total": 2
}
```
Only reviews with `publish_status = SUCCEEDED` or `SKIPPED` are returned. Results are ordered newest first.
**Response codes**
The response body includes a `status` field on every non-success outcome so callers can branch without parsing error strings.
| HTTP | `status` | When |
| ----- | --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `200` | *(absent)* | A complete review exists. Body is the review (or `{ reviews, total }` with `fullHistory=true`). |
| `200` | `in_progress` | A scan is in flight for this PR but no review has been written yet. Body is `{ "status": "in_progress" }`. Poll this endpoint again to fetch the review once it lands. |
| `404` | `repo_not_found` | No project under this team matches `repoName`. |
| `404` | `pr_review_not_found` | The repo exists but no complete review and no in-progress scan was found for this PR. |
### List PR review findings
```
GET /teams/:id/pr-review-findings
```
| Parameter | Type | Description |
| ------------ | ------ | ---------------------------- |
| `prReviewId` | string | Filter by specific PR review |
| `limit` | number | Max results |
| `offset` | number | Pagination offset |
***
## Team Settings
Manage team configuration, members, and preferences.
### List teams
```
GET /teams
```
Returns all teams the authenticated user belongs to.
### Get team
```
GET /teams/:id
```
### Get team permissions
```
GET /teams/:id/permissions
```
Returns the current user's role and permissions for the team.
### Invite a user
```
POST /teams/:id/invite
```
| Field | Type | Required | Description |
| ------- | ------ | -------- | ----------------------------------------- |
| `email` | string | Yes | Email address to invite |
| `role` | string | No | `admin`, `member`, or `ideUser` (default) |
### Remove a user
```
DELETE /teams/:teamId/users/:userId
```
***
## Dashboard & Analytics
Access dashboard metrics and AI usage data.
### Get dashboard data
```
GET /teams/:id/dashboard-data
```
Returns aggregated security metrics including findings by severity, trends over time, and top projects.
```bash theme={null}
curl -H "Authorization: Bearer cor_..." \
https://app.corridor.dev/api/teams/TEAM_ID/dashboard-data
```
### List LLM requests
```
GET /teams/:id/list-requests
```
Returns a summary of AI/LLM requests made across the team, useful for tracking AI usage and compliance.
### Get guardrail invocations
```
GET /teams/:id/guardrail-invocations-staging
```
| Parameter | Type | Required | Description |
| ----------- | ------ | -------- | ------------------------------------------ |
| `reportId` | string | Yes | Guardrail report ID to get invocations for |
| `period` | string | No | Time period (default `7d`) |
| `projectId` | string | No | Filter by project |
| `limit` | number | No | Max results (default 15) |
| `offset` | number | No | Pagination offset |
Returns data on which guardrails were triggered during real-time code analysis (hook events and security checks).
### Get stop hook invocations
```
GET /teams/:id/stop-hook-invocations
```
Returns instances where Corridor's hooks blocked an action (e.g., prevented an insecure code pattern from being applied).
### Log extension data
```
POST /log
```
The primary endpoint used by IDE extensions to send code analysis data to Corridor. Accepts a request body with a `type` field that determines processing:
| Type | Description |
| ------------------------ | -------------------------------------------- |
| `hook-event` | Real-time hook events from IDE extensions |
| `async-security-check` | Asynchronous security analysis of code edits |
| `fetch-security-results` | Retrieve cached security analysis results |
| `mcp-detection` | Report detected MCP servers |
| `compliance-data` | Submit compliance telemetry |
This endpoint is primarily used by the Corridor IDE extension. You typically don't need to call it directly unless you're building a custom integration.
***
## Projects
### List projects
```
GET /projects
```
| Parameter | Type | Required | Description |
| --------- | ------ | -------- | ---------------------------- |
| `teamId` | string | Yes | Team ID to list projects for |
Returns all projects for the specified team.
### Get project
```
GET /projects/:id
```
### Get project findings
```
GET /projects/:id/findings
```
Returns all findings for a specific project.
***
## Error handling
All endpoints return standard HTTP status codes:
| Status | Meaning |
| ------ | --------------------------------------- |
| `200` | Success |
| `400` | Bad request — check your parameters |
| `401` | Unauthorized — invalid or missing token |
| `403` | Forbidden — insufficient permissions |
| `404` | Not found |
| `500` | Server error |
Error responses include a JSON body:
```json theme={null}
{
"error": "Description of what went wrong"
}
```
## Rate limits
API tokens are subject to rate limiting. If you receive a `429` response, wait before retrying.
## Next steps
Use Corridor tools directly from your AI assistant
Learn more about findings management
Configure security guardrails
Automated pull request reviews
# Changelog
Source: https://docs.corridor.dev/changelog
Product updates, improvements, and new features from the Corridor team.
Updates ship continuously. This page tracks the changes we think are worth calling out — new features, notable improvements, and behavior changes that may affect your workflow.
🤖 Corridor released two integrations for AI coding tools:
* **Codex support**: Corridor now integrates with Codex CLI for real-time security guardrails. See [Corridor's Codex integration](/ide-setup/codex) to get started.
* **Cursor Plugin**: The Corridor Cursor Plugin adds real-time security reviews to Cursor agents, guiding the coding agent as it plans.
🙂 We've also made two improvements to PR reviews:
* **PR Feedback page**: Admins now have a Developer Feedback page that captures every developer reply to a Corridor PR comment, alongside the action Corridor took in response.
* **Comment emoji reactions**: Corridor now emoji reacts to developer responses on PR review comments.
### ✅ Auto-close on merge
When a PR is merged, Corridor now reviews the diff and automatically closes any open findings that the change remediates. This works for findings raised on the PR itself and for older findings that an unrelated PR happens to fix — so your findings list stays clean without manual triage. Closed findings show a "Fixed by PR #N" badge linking back to the merge.
### 🏷️ Custom tags for findings
Organize findings beyond severity and state. Use tags for things like:
* Marking findings a human has reviewed (the built-in Validated tag)
* Routing by team, service, or sprint
* Filtering the findings list, including a team-wide default filter so the page opens pre-scoped
Team admins create tags in **Team Settings → Finding Tag**. Any team member can apply existing tags from the (\*\*\*) menu on a finding, the REST API, or via the Corridor MCP.
Full docs: [Findings](/features/findings). As always, hit us up at [support@corridor.dev](mailto:support@corridor.dev) with questions or feedback.
🎉 We are expanding coverage to secure code where you work.
Here's what's new:
* **Standalone Corridor CLI**: use Corridor without an extension. This enables the Claude Code standalone plugin (via CLI).
* **Corridor MCP Server**: review findings, create guardrails for your agents, and more directly from your IDE.
* **Factory Hooks support (via CLI)**: ensure Factory-generated code aligns with your security policies and enforce MCP compliance.
* **Devin Desktop Hooks support**: apply the same guardrails to code from Devin Desktop.
If there are additional integrations you would like to see, let us know.
🎉 Today, we're announcing our partnership with Cursor through our integration with Cursor Hooks, enabling real-time security reviews and policy enforcement without interrupting your development flow.
What's new:
* **MCP Compliance enforcement** (enabled by default) — set policies and enforce which MCP servers can be run in the new Compliance tab.
* **Stop Hooks** (opt-in) — instant security checks that guide your coding agent to fix security bugs.
# Cursor
Source: https://docs.corridor.dev/cloud-agents/cursor
Set up Corridor with Cursor Cloud Agents to scan code for security vulnerabilities before every commit.
Corridor integrates with [Cursor Cloud Agents](https://cursor.com/agents) to catch security vulnerabilities before code is committed. When configured, every cloud agent session installs the Corridor CLI and a git pre-commit hook that scans staged changes and blocks commits containing security findings.
Cursor is the first supported cloud agent. Support for additional cloud agent providers is coming soon.
## Prerequisites
* A Corridor account with a team created
* **Owner** role on your Corridor team
* A Cursor account with Cloud Agents enabled
## Setup
In the [Corridor dashboard](https://app.corridor.dev), navigate to **Governance > Cloud Agents** and click the **Configuration** tab.
Select **Cursor** from the agent options.
Go to [cursor.com/dashboard/cloud-agents](https://cursor.com/dashboard/cloud-agents) and select the environment you want to configure.
Back in the Corridor Configuration tab, enter a name for your key (for example, "Cursor cloud agents") and click **Generate key**.
A modal will display the full API key. Copy it immediately. The key is only shown once.
In your Cursor environment settings, scroll to the **Secrets** section and add a new **Team Secret** (not a personal secret) so every team member's cloud agents can access it:
* **Name:** `CORRIDOR_API_KEY`
* **Value:** the API key you copied in the previous step
Back in Corridor, copy the setup script shown in step 3 of the Configuration timeline. In your Cursor environment settings, paste it into the **Update Script** field and save.
The script runs at the start of every cloud agent session. It installs the Corridor CLI and a git pre-commit hook that runs `corridor scan --staged` before each commit.
Each cloud agent installs the Corridor CLI when its session starts, so the agent environment needs outbound network access. If your environment restricts network access (for example, Cursor's **Network Access Settings**), add these domains to the allowlist:
* `app.corridor.dev`
* `github.com`
* `release-assets.githubusercontent.com`
## Advanced: custom environments
The [setup script](#setup) is the fastest path and wires everything up for you. If you manage your own agent environment — for example, building the Corridor CLI into a Docker image — you can add the same three pieces to your existing configuration manually instead:
Add your team API key as an environment secret named `CORRIDOR_API_KEY`.
Install the latest Corridor CLI in your image build or setup script:
```bash theme={null}
curl -fsSL https://app.corridor.dev/cli/install.sh | CI=true sh
```
Or download the latest release binary from the [Corridor CLI releases](https://github.com/CorridorSecurity/corridor-cli/releases/latest) page and put `corridor` on your `PATH`.
Add a git pre-commit hook that runs `corridor scan --staged`. Install it into your repository's standard hook location — `.git/hooks/pre-commit`, or `.husky/pre-commit` if your repo uses [Husky](https://typicode.github.io/husky/) — and the agent environment will run it on every commit.
## How it works
Once configured, every Cursor Cloud Agent session will:
1. Install the Corridor CLI
2. Install a git pre-commit hook in the repository
3. Scan staged changes before each commit
4. Block commits that contain security findings
Findings caught by the pre-commit scan appear in the **Usage** tab of the Cloud Agents page, where you can review severity, affected files, and resolution status.
## Managing API keys
You can view and revoke API keys in the **Configuration** tab under **Team-Owned API Keys**. Each key shows its name, creation date, and last used date.
To rotate a key:
1. Generate a new key in Corridor
2. Update the `CORRIDOR_API_KEY` secret in your Cursor environment
3. Revoke the old key
## Next steps
Configure the security rules that cloud agents enforce.
Learn how to review and resolve security findings.
# Blocking PRs
Source: https://docs.corridor.dev/features/blocking-prs
Turn Corridor's PR security review into a required status check so pull requests with unresolved findings can't be merged until they're addressed.
Blocking PRs is currently in **beta** and is available on GitHub (GitLab support is on the roadmap). To request access for your team, contact [support@corridor.dev](mailto:support@corridor.dev).
Blocking PRs lets Corridor act as a required status check on your pull requests. Code with unresolved security findings can't be merged until it's addressed, bringing security enforcement directly into your existing workflow.
## Prerequisites
* [Pull Request Reviews](/features/pr-reviews) enabled for your team
* GitHub [connected](/onboarding/connecting-github) to Corridor
* Permission to edit branch protection or rulesets on the repository you want to protect
## How it works
When a pull request is opened or updated, Corridor reviews the changes and posts any security findings as inline comments. A single **Corridor Review** check reflects the result:
* **Passing** — no open findings at your configured blocking severities.
* **Failing** — one or more findings need attention. If the check is required in branch protection, the merge is blocked until they're resolved.
You control what blocks: choose which severities gate a merge (for example, **Critical** and **High**), while lower-severity findings are surfaced for visibility without blocking. To keep noise low, Corridor filters out likely false positives before they ever reach a PR, so the findings you see are the ones worth your attention.
## Clearing the check
Developers can clear the check in whatever way fits the situation, all from the PR:
* **Fix the code** — push a fix and Corridor automatically re-verifies the finding and clears the check once it's resolved. No manual step required.
* **Mark a false positive** — reply `false positive` on the finding's inline comment to dismiss it, with the decision recorded.
* **Accept the risk (unblock)** — reply `unblock` to override a specific finding when your team decides to proceed.
* **Adjust from the dashboard** — security teams can change a finding's severity or resolve it centrally, and the check updates automatically.
See [Replying to Corridor's comments](/features/pr-reviews#replying-to-corridors-comments) for more on the reply workflow.
## Setting it up
There are two steps: choose your blocking rules in Corridor, then require the check in GitHub. Both are required — Corridor reports the pass/fail signal, and branch protection is what turns that signal into enforcement.
### 1. Choose your blocking rules in Corridor
On the **PR Reviews** page, open **Settings** and:
1. Ensure **Enable Pull Request Reviews** is on.
2. Under **Block PRs with Security Findings**, check the severities that should block a merge (for example, **Critical** and **High**). Leaving every severity unchecked disables blocking.
3. Ensure **Leave Comments on Pull Requests** is on.
Findings at severities you leave unchecked are still surfaced on the PR for visibility without blocking the merge. Blocking severities are a **team-wide** setting—they apply to every project on the team and can't be overridden per project.
![PR Review Settings with Block PRs with Security Findings showing Critical and High severities checked]()
### 2. Require the check in GitHub
This is the step that enforces the block — on its own, the Corridor Review check reports pass/fail but does not prevent merges.
1. Go to repository **Settings → Branches → Add branch protection rule** (or edit an existing rule).
2. Set the **Branch name pattern** to your protected branch (for example, `main`).
3. Enable **Require status checks to pass before merging**.
4. In the search box that appears, find and select **Corridor Review**.
5. Save changes.
1. Go to **Settings → Rules → Rulesets → New branch ruleset** and target your branch(es).
2. Under **Require status checks to pass**, click **Add checks**, search **Corridor Review**, and add it.
3. Set the ruleset to **Active** and save.
GitHub only lists a status check once it has run at least once (recently). If **Corridor Review** doesn't appear in the search, open or update a PR so the check runs, then it'll be selectable.
Without step 2, the Corridor Review check still runs and reports pass/fail on every PR, but GitHub won't prevent merges — branch protection is what turns the signal into enforcement.
## Next steps
How Corridor reviews pull requests and how to reply to findings
Track and manage security findings
# Chats
Source: https://docs.corridor.dev/features/chats
Investigate your codebase and get deeper analysis on your findings.
Chat features are available on **Enterprise** plans.
Corridor's Chat feature lets you interact with an AI assistant that is contextually aware of your codebase and security issues. It's like having a security expert on call—you can ask questions about your code's security, request explanations, or get remediation guidance in a conversational way.
## Use cases
* **Investigate findings**: "What's the impact if this SQL injection is exploited?" or "Are there similar patterns elsewhere in my codebase?"
* **Discover vulnerabilities**: "Do we have any insecure uses of MD5 in our codebase?" or "Where are we handling user input without validation?"
* **Get remediation guidance**: "How do I implement parameterized queries here?" or "What's the secure way to handle this file upload?"
* **Interactive code review**: "Review the security of the loginHandler function"
## How it works
Chats have access to your codebase structure and content, active findings, your team's guardrail configurations, and security best practices. Because the chat has your codebase context, answers are specific—not generic security advice, but "In file X, on line Y you do Z—that could be risky because..."
## Starting a chat
* **From a finding**: Open a finding in the dashboard and click **Investigate**. The chat opens with context about the finding pre-loaded
* **From the project view**: Navigate to your project and click **Chat** in the sidebar to ask any security-related question
## Next steps
View and manage security findings
Real-time security during code generation
# Corridor MCP
Source: https://docs.corridor.dev/features/corridor-mcp
Corridor's MCP server tools enable AI coding assistants to interact with your security data.
Corridor's MCP server provides tools that enable AI coding assistants to directly interact with your security data. When you use Claude Code, Cursor, or other MCP-compatible tools, the AI assistant can access and manage your Corridor findings and guardrails.
## Available tools
| Tool | Description |
| -------------------- | --------------------------------------------------------------------------------------------------------- |
| `analyzePlan` | Analyze a planned code implementation and get relevant security context from your project's guardrails |
| `getFindings` | Retrieve security findings with filters for state (open/closed/potential), severity, and limit |
| `getFinding` | Get detailed info about a specific finding including description, affected code, and remediation guidance |
| `updateFindingState` | Mark findings as closed (false positive, risk accepted, fixed) or reopen them |
| `getGuardrails` | Get security guardrails and context documents for a project |
| `createGuardrail` | Create new security guardrails programmatically |
| `listProjects` | List all Corridor projects you have access to |
### analyzePlan
The `analyzePlan` tool is the core tool that AI coding assistants call before generating code. It takes a description of what you plan to implement and returns relevant security context from your project's guardrails and context documents. This helps prevent vulnerabilities by giving the AI assistant project-specific security guidance at the point of code generation.
**Parameters:**
| Parameter | Type | Required | Description |
| ---------------------- | ------- | -------- | -------------------------------------------------------------------------------- |
| `plan` | string | Yes | Description of what you plan to implement or the user request you are working on |
| `cwd` | string | No | Absolute path to the current working directory of the workspace |
| `branch` | string | No | Current git branch name |
| `commit_hash` | string | No | Current git commit hash |
| `has_unstaged_changes` | boolean | No | Whether there are uncommitted changes in the working directory |
**Example:**
```
You: "Add a login form that accepts email and password"
Claude: [Uses analyzePlan with plan='Add a login form that accepts email and password']
Corridor returns security guidance like:
• Ensure all user input is validated and sanitized server-side before processing
• Use parameterized queries for any database lookups to prevent SQL injection
• Implement rate limiting on the login endpoint to prevent brute-force attacks
```
The AI assistant uses this security context to write safer code from the start, following your team's specific guardrails.
## Example conversation
```
You: "What are the open critical security issues in this project?"
Claude: [Uses getFindings with state='open', severity='critical']
"I found 3 critical security findings:
1. SQL Injection in auth.ts:42
2. XSS vulnerability in render.tsx:87
..."
```
Your AI assistant can also:
* "Add a new API endpoint" → calls `analyzePlan` for security context before writing code
* "Show me details about finding X" → calls `getFinding`
* "Mark this finding as a false positive" → calls `updateFindingState`
* "What guardrails should I follow?" → calls `getGuardrails`
* "Create a guardrail for SQL injection prevention" → calls `createGuardrail`
## Requirements
* Corridor extension installed and authenticated
* MCP enabled for your team (team setting)
* IDE Extension Support entitlement on your plan
* User must be a member of a team that owns the project
## Security notes
* Tools validate team membership before granting access
* Uniform 404 responses prevent information leakage
* Admin operations reject API tokens (require user auth)
## Next steps
Track and remediate security issues
Configure security guardrails
# Dashboard
Source: https://docs.corridor.dev/features/dashboard
Track security metrics, PR review effectiveness, and remediation progress.
The Dashboard is your home base to monitor and manage security across your projects. Corridor provides analytics to help you understand your security posture, measure the effectiveness of automated reviews, and track remediation progress.
## Key dashboard sections
### Pull request reviews
A summary of recent PRs and their security status. For each pull request, see an outcome like "2 issues found" or "No issues." Click on a PR to see the detailed findings.
### Guardrails summary
Shows which guardrail packs are active and how often guardrails are triggering. Team admins can quickly see if a particular guardrail is firing frequently, indicating recurring attempts at a certain insecure practice.
### Compliance and usage
If you're on a Team/Enterprise plan, you'll see data on AI usage and compliance—how many AI-generated code suggestions have been monitored, any policy violations caught, and logs of who used which AI tool and when.
### Projects overview
A list of your projects with a quick status. Each project shows open findings count by severity and last PR scan results.
## Filtering controls
Every analytics view includes:
* **Project scope**: View metrics across all projects or focus on a specific repository
* **Timeframe**: Last 7 days, 30 days, 90 days, or a custom date range
## Remediation metrics
Track how effectively your team addresses security issues:
* **Open Findings**: Unresolved issues requiring attention
* **Mean Time to Remediate (MTTR)**: Average time from discovery to fix
* **Remediation Rate**: Findings closed per week/month
## Next steps
Learn about automated reviews
Track and manage security findings
# Findings
Source: https://docs.corridor.dev/features/findings
Track, prioritize, and remediate security vulnerabilities discovered in your code.
Findings are security issues discovered by Corridor in your code. They are created from PR reviews, guardrail violations, and code scans. Each finding represents a specific security issue at a specific location in your code.
## Finding properties
| Property | Description |
| --------------- | ----------------------------------------------------------------------------------- |
| **Title** | Brief description of the vulnerability (e.g., "SQL Injection in userController.js") |
| **Description** | Detailed explanation with security impact |
| **Severity** | Critical, High, Medium, Low, or Informational |
| **State** | Open, Closed, or Potential |
| **Location** | File path, line number, and code snippet |
| **Remediation** | Specific guidance on how to fix the issue |
## Finding states
| State | Description |
| ------------- | ------------------------------------------- |
| **Potential** | Needs verification—may be false positive |
| **Open** | Confirmed issue requiring remediation |
| **Closed** | Issue has been resolved |
| **Won't Fix** | Accepted risk with documented justification |
## Managing findings
When a new finding arrives, review the description and code context, verify it's a real issue, and either move it to **Open** or mark as **Won't Fix** with justification.
To fix a finding:
* **Manual fix**: Navigate to the file/line mentioned and fix the code based on Corridor's recommendation
* **AI-assisted fix**: Use your AI assistant to help fix it—copy Corridor's finding description and ask your AI to fix the issue
* **Auto fix** (if available): On certain findings, Corridor can open a new branch/PR with the suggested code changes for you to review and merge
After a fix is applied, Corridor will rescan and mark the finding as **Closed** if the issue is gone.
## Auto-close on merge
When a PR is merged, Corridor automatically checks whether any open findings were addressed by the changes. It analyzes the diff against each finding's affected code and description to determine whether the vulnerability was remediated. If so, the finding is moved to **Closed** with the reason "Vulnerability fixed."
Corridor errs on the side of caution: a finding is only auto-closed when the analysis is confident the vulnerability was actually fixed, so you won't see real issues disappear due to unrelated changes.
Closed findings will show a **Fixed by PR #N** badge in the detail view, linking directly to the merged PR.
Previous findings from before the release of this feature will close as new PRs touch files related to those findings.
If you believe a finding should have been auto-closed but wasn't, you can always close it manually from the finding detail view.
## False positives
If you determine a finding is not actually a problem, mark it as **Won't Fix** with a reason. This feedback helps improve detection accuracy over time.
You can also provide feedback on a finding directly from the PR by replying to the Corridor comment with your reasoning — Corridor will evaluate the reply and close the finding as a false positive. See [Replying to Corridor's comments](/features/pr-reviews#replying-to-corridors-comments). You can view all developer feedback and the actions Corridor has taken in response at [app.corridor.dev/pr-reviews/feedback](https://app.corridor.dev/pr-reviews/feedback).
## Custom tags
Tags let you organize findings beyond severity and state. They are team-scoped, so every project on your team shares the same tag vocabulary.
Common reasons to use tags:
* **Validation workflow**: Mark findings a human has reviewed and confirmed as real (the built-in **Validated** tag is seeded on new teams for this purpose)
* **Triage and ownership**: Group findings by team, service, sprint, or owner so the right people see the right issues
* **Filtering**: Narrow the findings list to a specific tag, or surface only untagged findings that still need triage
* **Default views**: Set a team-wide default tag filter so the findings page opens pre-filtered to what matters most—for example, defaulting to **Validated** so the list shows only confirmed issues
### Creating tags
Only **team admins** can create, rename, remove, or set the default for tags. Any team member can apply existing tags to findings.
Team admins manage tags from **Team Settings → Finding Tag**:
Go to **Teams** in the dashboard and scroll to the **Finding Tag** section.
Type a tag name and click **Add**. Tag names must be unique within the team.
Use the **Default tag filter** dropdown to choose which tag the findings page should pre-filter to when any team member opens it.
To remove a tag, click the **×** next to it in the same section. Removing a tag also removes it from any finding it was applied to.
### Applying tags to findings
Tags can be applied in three ways:
* **Dashboard**: Open the kebab (⋯) menu on any finding and toggle a tag on or off. The **Validated** tag also has a dedicated one-click **Validate** button on open findings
* **API**: `PUT /findings/:id` with a `tags: string[]` body, where each entry is a tag name configured on the team
* **MCP / AI assistant**: With the [Corridor MCP](/features/corridor-mcp) integration set up, ask your AI assistant to apply tags as part of `updateFindingState`—e.g. "tag this finding as validated and assign it to the platform team"
## Managing findings via AI assistant
If you have the Corridor MCP integration set up, your AI assistant can interact with findings directly:
* **Retrieve findings**: Ask your AI "What are the open critical security issues?" to get findings filtered by state and severity
* **Get finding details**: Ask "Show me details about finding X" to get the full description, affected code, and remediation guidance
* **Update finding state**: Tell your AI "Mark this finding as a false positive" to close the finding with the appropriate reason
See [Corridor MCP](/features/corridor-mcp) for the full list of available tools and requirements.
## Chats for deeper analysis
**Chat features** are available on **Enterprise** plans.
Use the chat feature to dig deeper into findings—ask questions about the vulnerability and its impact, get more detailed remediation guidance, and explore related code patterns. See [Chats](/features/chats) for more details.
## Next steps
How findings are discovered in pull requests
Investigate findings with AI assistance
# Guardrails
Source: https://docs.corridor.dev/features/guardrails
Real-time security analysis during AI code generation prevents vulnerabilities before they're written.
Guardrails are at the core of Corridor's approach—they are security rules and best practices that Corridor enforces in your code. Guardrails give AI coding agents the context they need to write secure code from the start, proactively ensuring that vulnerable patterns are never introduced. Guardrails also run as checks on code diffs in pull requests—if code in a PR violates a guardrail, Corridor catches it and flags it for review.
## Why guardrails matter
Traditional security tools run after code is committed—by then, the vulnerability exists and requires remediation. Corridor's guardrails shift security left by integrating directly into the AI code generation process:
* **Prevention over detection**: Security context guides the AI to avoid vulnerable patterns
* **Zero developer friction**: No separate security review step—it happens during coding
* **Reduced remediation costs**: Fixing a vulnerability before it's written costs nothing
## How guardrails work
Guardrails operate through MCP and Hooks, which allow Corridor to participate in AI interactions:
1. **Developer prompts AI**: "Write a function to query the database"
2. **Corridor analyzes context**: Project type, existing code patterns, security policies
3. **Security context provided**: Guardrails inform the AI about relevant risks (e.g., SQL injection, parameterized queries)
4. **AI generates secure code**: The response incorporates security best practices
5. **Activity logged**: The interaction is recorded for audit and analytics
Guardrails function at two levels:
* **During code generation**: Guardrails provide additional context to AI models (via MCP) so the AI avoids insecure suggestions. This happens invisibly as you code
* **During code review**: Guardrails run as checks on code diffs in pull requests. If code in a PR violates a guardrail, Corridor catches it and flags it for review
## Configuring guardrails
By default, Corridor applies the **Corridor Default Security Pack**: a comprehensive pack of essential security guardrails covering common vulnerability classes including injection attacks, authentication issues, and access control flaws.
Corridor also provides pre-loaded security packs tailored to specific languages, app types, and standards. Teams can create custom packs on the **Guardrails** page comprised of guardrails unique to their needs.
See [Configuring Guardrails](/onboarding/configuring-guardrails) for detailed instructions on setting up default packs, custom guardrails, and custom context.
## Managing guardrails via AI assistant
If you have the Corridor MCP integration set up, your AI assistant can interact with guardrails directly:
* **View guardrails**: Ask your AI "What guardrails should I follow?" and it will call Corridor's `getGuardrails` tool to retrieve security guardrails and context documents for the project
* **Create guardrails**: Tell your AI "Create a guardrail for SQL injection prevention" and it will call `createGuardrail` to create a new guardrail programmatically
See [Corridor MCP](/features/corridor-mcp) for the full list of available tools and requirements.
## Next steps
Set up and customize guardrails for your projects
Automated security reviews on pull requests
Track and remediate security issues
# MCP Compliance
Source: https://docs.corridor.dev/features/mcp-compliance
Control which AI tools and MCP servers your team can use for secure AI-assisted development.
Corridor's MCP Compliance features ensure that AI coding assistants are used in a controlled, auditable way. This addresses questions like: "Are developers only using approved AI tools? Can we prove we're enforcing policies during AI-assisted development?"
MCP compliance is currently supported with **Cursor**, **Claude Code**, **Devin Desktop**, **Factory Droid**, and **OpenAI Codex** via Hooks.
## Why control MCP servers?
MCP servers can access local files, make network requests, execute code, and read environment variables. Without controls, developers might use MCP servers that leak sensitive code to unauthorized services or introduce security vulnerabilities.
## How it works
MCP compliance is enforced via **Hooks**—deterministic scripts that run before MCP calls are made. When an AI agent attempts to use an MCP server, Corridor's hook intercepts the call, checks it against your team's policies, and allows or blocks it accordingly. This happens transparently without adding latency to permitted requests.
* **See what's being used**: Every MCP server invocation is logged via hooks
* **Enforce policies**: Hooks block unauthorized servers before they can execute
* **Audit trail**: Full history of AI tool usage for compliance
### Compliance modes
Configure MCP compliance at the team level:
| Mode | Description |
| ------------- | ---------------------------------------------------------- |
| **Disabled** | No restrictions—all MCP servers allowed |
| **Allowlist** | Only specified servers are permitted (most secure) |
| **Blocklist** | All servers except specified ones are permitted (flexible) |
### Configuring policies
1. Navigate to the **Compliance** tab in the Corridor dashboard
2. Select a compliance mode (**Allowlist** or **Blocklist**)
3. Add servers to your allow or block list
4. Click **Save**
### Server entry format
Each entry is matched against the canonical name of the MCP server your IDE is about to invoke. Matching is case-insensitive, and dots, spaces, and underscores are equivalent — so `claude.ai Asana`, `Claude.ai Asana`, and `claude_ai_asana` all refer to the same server.
The easiest way to write an entry is to copy the **display name** as it appears in your IDE's MCP panel:
| Server type | Example entry |
| ---------------------------------- | ----------------- |
| A connector hosted by an AI vendor | `claude.ai Asana` |
| A standalone remote MCP server | `linear` |
When adding entries:
* **Capitalization doesn't matter** — `claude.ai Asana`, `Claude.ai Asana`, and `claude.ai asana` are all treated as the same server.
* **Use dots, spaces, or underscores** to separate words in a multi-word name — pick whichever matches what you see in the IDE. `claude.ai Asana` and `claude_ai_asana` work identically.
If a server is unexpectedly blocked, the error in your IDE will include the tool name Corridor saw, in the form `mcp__server_name__tool_name`. The portion between `mcp__` and the next `__` is the canonical server identifier — entering that name (or its display equivalent with dots and spaces) in your allowlist will match it.
### How policies are enforced
When a developer uses an AI assistant in Cursor, Claude Code, Devin Desktop, Factory Droid, or OpenAI Codex:
1. **MCP call intercepted**: The AI attempts to call an MCP server and Corridor's hook triggers
2. **Policy checked**: The hook evaluates the server against your team's compliance policy
3. **Action taken**: The request is allowed through or blocked with a compliance error
4. **Logged**: All invocations are recorded for audit
When a user belongs to multiple teams, the most restrictive policy applies—allowlist intersection and blocklist union.
## Next steps
Configure security guardrails
Explore Corridor's MCP tools
# PR Reviews
Source: https://docs.corridor.dev/features/pr-reviews
Automated security reviews on every GitHub pull request with actionable findings and low false positive rates.
Corridor's Pull Request (PR) review feature acts as an automated security reviewer for your code changes. Whenever you open or update a PR, Corridor analyzes the diff for potential security issues and provides feedback directly in the PR.
## Developer workflow
Treat Corridor's comments like those from a human reviewer specialized in security:
1. **Understand the issue**: Read the explanation and remediation guidance
2. **Push a fix**: Push additional commits to address the problem. Corridor will re-check the PR on the new commit
3. **Reply to discuss or provide feedback**: Reply directly in the PR thread to ask follow-up questions, flag a finding as a false positive, or request an unblock. See [Replying to Corridor's comments](#replying-to-corridors-comments) below
4. **Handle false positives**: If you believe a finding is a false positive, reply with the reasoning, or mark it as **Won't Fix** in the dashboard. This feedback helps Corridor learn and helps the security team adjust guardrails
Once all issues are resolved, Corridor's status check will turn green and you can merge knowing the security review is clear.
### Replying to Corridor's comments
You can reply to any Corridor review comment in the PR thread to keep the conversation in GitHub. Corridor reads the thread and responds in-line. Common things to say:
* **"This is a false positive because..."** — Corridor evaluates your reasoning and closes the finding as a false positive. Corridor also performs AI enrichment on reported false positives and aggregates them into a feedback report at [app.corridor.dev/pr-reviews/feedback](https://app.corridor.dev/pr-reviews/feedback).
* **"Please unblock this PR"** — Corridor reviews the request and, if warranted, removes the blocking status on the finding.
* **A follow-up question** — Corridor answers in context using the same code understanding it used for the original review.
Corridor signals where it is in the workflow by adding emoji reactions to your reply:
| Reaction | Meaning |
| -------- | ---------------------------------------------------------------- |
| 👀 | Your reply was received and Corridor is processing it |
| 👍 | Processing finished — look for Corridor's response in the thread |
If you don't see a 👀 within a minute or two, Corridor most likely decided no response was warranted (for example, the reply was a thank-you or directed at another participant). You can always re-reply with a more specific question to re-trigger processing.
## Configuration
PR review settings can be configured at two scopes:
* **Team-wide defaults** apply to every project on the team. Configure them on the **PR Reviews** page → **Configure** (top right corner).
* **Per-project overrides** apply to a single project and take precedence over the team default. Configure them on the project page → **Settings**. See [Project Settings](/onboarding/adding-projects#project-settings).
By default, a project inherits every setting from the team. When you override a setting on a project, only that setting is detached from the team default—other settings continue to inherit. Use **Reset to Team Defaults** on the project settings page to clear overrides and resume inheritance.
See [Connecting GitHub](/onboarding/connecting-github) for initial setup.
### Available settings
The table below applies to both team-wide defaults and per-project overrides, except where noted.
| Setting | Description |
| --------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Enable Pull Request Reviews** | Automatically review pull requests for security vulnerabilities |
| **Block PRs with Security Findings** | Prevent merging pull requests that contain security vulnerabilities (blocks can still be overridden in GitHub). Currently in **beta**—contact [support@corridor.dev](mailto:support@corridor.dev) to request access. Team-wide setting. See [Blocking PRs](/features/blocking-prs) |
| **Review Verbosity Mode** | Control how inclusive the PR reviewer is when flagging potential security issues. Standard review mode provides a balanced approach between catching vulnerabilities and minimizing false positives |
| **Leave Comments on Pull Requests** | Post review comments directly on GitHub PRs |
| **Disable Comments for Specific Repos** | PRs from selected repositories will still be reviewed but comments won't be posted. Team-wide setting—to disable commenting for a single project, turn off **Leave Comments on Pull Requests** in that project's settings instead |
### Advanced settings
| Setting | Description |
| ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
| **Enable Draft PR Reviews** | Review pull requests that are marked as draft |
| **GitHub Label Filter** | Optionally restrict review comments to PRs with a specific label |
| **Comment When No Issues Found** | Leave a comment even when no vulnerabilities are detected |
| **Minimum Severity to Comment On** | Only post PR comments for findings at or above the selected severity level (Medium, High, or Critical). Defaults to all issues |
| **Enable Threat Modeling** | Include threat model analysis with risk level and security considerations on all PRs |
## How it works
When a pull request is opened or updated:
1. **Webhook trigger**: GitHub sends a webhook to Corridor
2. **Diff analysis**: Corridor analyzes only the changed code, understanding context from the broader codebase
3. **Security review**: The changes are evaluated against security best practices, known vulnerability patterns, and your guardrails
4. **Review posted**: Findings appear directly on the PR with inline comments
5. **Corridor Review check**: GitHub shows a **Corridor Review** check on your pull request. It moves from **Queued** to **In progress** while Corridor reviews your changes, and to **Success** when the review is finished. The check does not block merging on its own. Click **Details** to open this review in the Corridor dashboard.
Corridor's reviews are context-aware—not just pattern matching. The review understands your codebase structure, existing security patterns, and the purpose of the changes. Each finding includes specific remediation steps, not generic advice.
## Developer Feedback
The **Developer Feedback** page is available to **team admins** only.
When a developer replies to a Corridor PR comment—accepting a finding, pushing back on a false positive, or asking to unblock—that exchange is captured on the **Developer Feedback** page (**PR Reviews** → **Developer Feedback** in the sidebar). Admins use this page to review every reply for the selected team alongside the action Corridor took in response, so you can see how Corridor is learning from your developers.
Each row shows the date, PR number, finding, the developer's comment, a sentiment classification, and an **Action taken** summary. Click a row to open the full thread or jump to the finding.
### Sentiments
Corridor classifies each developer reply into one of four sentiments, which you can filter by:
| Sentiment | Meaning |
| ------------------- | ------------------------------------------------------------------------------------------- |
| **True Positive** | The developer confirmed the finding is a real issue |
| **False Positive** | The developer pushed back on the finding |
| **Unblock Request** | The developer accepted the risk and asked to unblock the PR |
| **Other** | A reply that did not change the finding's state (clarifying question, acknowledgment, etc.) |
### Action taken
The **Action taken** column reflects what happened after the reply was classified:
| Action | When you see it |
| ---------------------------------------------------- | -------------------------------------------------------------------------------------------- |
| **Marked as false positive · AI agreed** | A second-pass review confirmed the developer's false-positive claim |
| **Marked as false positive · AI flagged for review** | The second-pass review disputed the false-positive claim—worth a look from the security team |
| **Marked as false positive · analysis pending** | The follow-up analysis is still running |
| **Confirmed as a real issue** | The finding was kept open for remediation |
| **PR unblocked · risk accepted** | The PR was unblocked despite the finding |
| **Replied — no state change** | A non-actionable reply was recorded but the finding's state was not changed |
See [Findings](/features/findings) for managing the underlying findings.
## Review limits
| Tier | PR Reviews |
| ---------- | ------------- |
| Pro | 100/month |
| Team | 100/dev/month |
| Enterprise | Unlimited |
Developer count is based on unique developers interacting with Corridor—IDE users, dashboard users, and PR authors—in the given month.
## Next steps
Track and manage security findings
Configure real-time security guardrails
# Pre-Commit Scanning
Source: https://docs.corridor.dev/features/pre-commit-scanning
Scan code for security vulnerabilities before every commit so issues are caught before they reach a pull request.
Pre-commit scanning lets Corridor catch security vulnerabilities at the earliest possible moment: before code is committed. A git pre-commit hook runs `corridor scan --staged` on every commit, analyzes the staged changes for security issues, and blocks the commit if any findings are detected. The coding agent or developer can then fix the issue and retry.
This means fewer vulnerabilities make it into pull requests, reducing remediation costs and keeping your codebase cleaner.
## How it works
When a coding agent runs `git commit`, the pre-commit hook kicks in:
1. **Corridor scans the diff.** Corridor's analysis engine evaluates the changes against your team's guardrails and known vulnerability patterns.
2. **Results are returned.** If the scan finds security issues, the commit is blocked and findings are printed in the terminal. If no issues are found, the commit proceeds normally.
3. **Findings are recorded.** Any findings are saved to the Cloud Agents Usage tab in the Corridor dashboard, where your team can review severity, affected files, and resolution status.
Subsequent commits with the same staged content skip the full scan if all prior findings have been resolved, so developers are not slowed down once issues are fixed.
## Setting it up
Pre-commit scanning is configured through the **Cloud Agents** page in the Corridor dashboard. The setup installs the Corridor CLI and the git pre-commit hook in your cloud agent environment so every session is protected automatically.
For step-by-step setup instructions, see the [Cursor Cloud Agents](/cloud-agents/cursor) guide.
Pre-commit scanning is currently available for Cursor Cloud Agents. Support for additional cloud agents (Codex, Devin, Claude Code) is coming soon.
## What it looks like
### In the dashboard
Findings from pre-commit scans appear on the **Cloud Agents** page under the **Usage** tab. This view shows all in-development findings from the last 30 days, including:
* **Summary cards** with total findings, fixed count, and false positive count
* **Severity breakdown** showing how many findings fall into each severity level
* **Findings table** with columns for the finding title, severity, state, user, project, branch, associated PR, affected file, and creation date
Click any finding to open its detail view, where you can see the full description, affected code, and remediation guidance.
![Cloud Agents Usage tab showing in-development findings with severity breakdown, state, and affected files]()
## Pausing the scan
Team owners can temporarily stop the pre-commit scan from blocking commits without removing the hook from the agent environment.
To pause:
1. Go to **Governance > Cloud Agents** in the Corridor dashboard.
2. Open the **Configuration** tab.
3. Toggle **Stop Pre-Commit Scan** to on.
While paused, the hook remains installed but commits are no longer blocked. Toggle it off to resume scanning.
![Cloud Agents Configuration tab showing the Stop Pre-Commit Scan toggle and Team-Owned API Keys section]()
## Bypassing the hook
Individual developers can skip the pre-commit scan for a single commit by passing the `--no-verify` flag:
```bash theme={null}
git commit --no-verify -m "your commit message"
```
This bypasses all git hooks, including the Corridor scan. Use this sparingly and only when you have a good reason to skip the check.
## Next steps
Set up Corridor with your Cursor Cloud Agents.
Configure the security rules that scans enforce.
Learn how to review and resolve security findings.
Automated security reviews on pull requests.
# Core Concepts
Source: https://docs.corridor.dev/getting-started/concepts
Understand how Corridor works and the key concepts used throughout the platform.
This page explains how Corridor helps secure AI-assisted development and the fundamental concepts you'll encounter when using the platform.
## Core concepts
### Projects
A **project** represents a codebase that Corridor monitors. Projects are typically linked to a GitHub repository and track:
* **Guardrail invocations**: Real-time security analysis during AI code generation
* **PR reviews**: Automated security analysis of pull requests
* **Findings**: Security issues discovered in your code
### Teams
A **team** is a group of users who share projects, security policies, and billing. Every project belongs to exactly one team.
#### Team roles
| Role | Permissions |
| ----------------- | ------------------------------------------------------------------------------------------------------------------- |
| **Owner** | Full access—manage members, billing, integrations, and all team settings |
| **Admin** | Manage projects, guardrails, and findings, use IDE extension, respond to findings. Cannot manage members or billing |
| **Standard User** | Use IDE extension and MCP guardrail checks only—no dashboard access |
### Guardrails
**Guardrails** are security rules that analyze AI interactions in real-time. Corridor integrates directly into your AI coding workflow via MCP and Hooks. When developers use agents such as Claude Code, Cursor, or VS Code with AI assistants, Corridor evaluates code generation requests and provides security context back to the AI. Unlike traditional static analysis that runs after code is written, guardrails operate during the AI generation process itself—security context is provided before code is generated, allowing the AI to avoid vulnerable patterns and prevent vulnerabilities rather than detect them after the fact.
### Findings
A **finding** is a security issue discovered by Corridor. Findings can come from PR reviews, guardrail violations, or code scans. Enterprises can use the Corridor chat feature to scan existing code. Each finding includes severity, state, code location, and actionable remediation steps. Track findings through resolution and monitor your security posture over time.
### PR reviews
Every pull request is automatically reviewed for security issues. When enabled, Corridor receives a webhook when a PR is opened or updated, analyzes the code changes for security vulnerabilities, and posts a review with specific findings and remediation guidance directly on GitHub. You can also configure Corridor to block PRs with critical issues from merging.
### MCP Compliance
**MCP (Model Context Protocol)** is the standard that allows AI assistants to use external tools. Corridor lets teams control which MCP servers are allowed through compliance policies.
MCP servers can access files, make network requests, and execute code. Without oversight:
* Sensitive data could leak to unauthorized services
* Unapproved tools could introduce security risks
* Shadow AI usage becomes invisible to security teams
## Tier comparison
| Feature | Pro | Team | Enterprise |
| ----------------------- | --------- | ----------------- | ----------------- |
| **Team members** | 1 | Up to 20 | Custom |
| **Projects** | 5 | 20 | Unlimited |
| **PR reviews** | 100/month | 100/dev/month | Unlimited |
| **Guardrails** | Standard | Standard + Custom | Standard + Custom |
| **MCP compliance** | ✓ | ✓ | ✓ |
| **Team visibility** | - | ✓ | ✓ |
| **Chats** | - | - | ✓ |
| **SSO** | - | - | ✓ |
| **Zero data retention** | - | - | ✓ |
## Next steps
Set up Corridor for your team
Learn about real-time security analysis
# Quickstart
Source: https://docs.corridor.dev/getting-started/quickstart
Get up and running with Corridor in under 5 minutes.
Get up and running with Corridor in a few quick steps. This assumes you have a Corridor account (sign up at [app.corridor.dev](https://app.corridor.dev)) and access to the code repository you want to secure.
## Prerequisites
* A Corridor account ([sign up](https://app.corridor.dev))
* A supported IDE or AI coding tool (VS Code, Cursor, Claude Code, Devin Desktop, Factory, Devin, Codex, or any MCP-compatible tool)
* A GitHub repository to connect
## Step 1: Connect GitHub
In the Corridor web app, you'll be prompted to connect your GitHub account or organization. Authorize the Corridor GitHub App with the necessary permissions.
Go to [app.corridor.dev](https://app.corridor.dev) and sign in with your GitHub account.
Click **Connect GitHub** and authorize the Corridor GitHub App. You can grant access to **All repositories** or select specific repos—be sure to include any repos you want Corridor to monitor.
Corridor needs read access to code and permission to write PR comments to perform reviews.
## Step 2: Add a project (repository)
Once GitHub is connected, add a repository as a Project in Corridor.
In the Corridor dashboard, go to **Projects** and click **New Project**.
Select the repo from the list to bring it under Corridor's protection. You must add a project before Corridor can analyze its code—simply connecting GitHub isn't enough.
After adding, Corridor will scan the codebase and automatically generate initial security guardrails tailored to that project.
## Step 3: Install the IDE extension
To get real-time guardrails while coding, install Corridor's integration for your development environment:
1. Open VS Code
2. Go to the Extensions panel (`Cmd+Shift+X` or `Ctrl+Shift+X`)
3. Search for "Corridor"
4. Click **Install**
5. Reload your editor when prompted
After installation, you'll see the Corridor icon in your sidebar.
**GitHub Copilot users:** If your organization manages Copilot through GitHub Enterprise, an admin must enable external MCP servers in the [Copilot policy settings](/ide-setup/vscode#enable-mcp-for-github-copilot) before Corridor's tools will appear.
See [VS Code setup](/ide-setup/vscode) for detailed instructions.
Cursor has two Corridor integrations. You can use either or both at the same time.
**Option 1: Cursor Plugin** — available in the Cursor Marketplace. Includes the `/corridor` skill to review code in the background as Cursor Agents work. Use this for a frictionless, Cursor-native experience with the least setup.
1. In Cursor, open the **Agents** tab and navigate to the **Marketplace**
2. Find Corridor and click **Get**
3. Click **New Agent** and configure it as **Local**
4. Invoke the skill in any chat with `/corridor`
**Option 2: Corridor extension** — a VS Code-style extension that registers Corridor as an MCP server and runs deterministic hooks. Use this for access to all Corridor features, such as MCP-based tool access, MCP compliance enforcement, or hooks that can block code with critical findings.
1. Open the Extensions panel in Cursor (`Cmd+Shift+X` or `Ctrl+Shift+X`)
2. Search for "Corridor" and click **Install**
3. Reload Cursor and sign in from the Corridor sidebar
See [Cursor setup](/ide-setup/cursor) for detailed instructions on both options.
Integrate Corridor with Claude Code via the CLI.
1. Install the Corridor CLI:
```bash theme={null}
# macOS / Linux
curl -fsSL https://app.corridor.dev/cli/install.sh | bash
```
```powershell theme={null}
# Windows (PowerShell)
irm https://app.corridor.dev/cli/install.ps1 | iex
```
2. The installer will automatically set up the Corridor plugin, MCP server, and hooks
See [Claude Code setup](/ide-setup/claude-code) for detailed instructions.
Integrate Corridor with Factory's AI Droid agents via MCP and hooks.
1. Install the Corridor CLI:
```bash theme={null}
# macOS / Linux
curl -fsSL https://app.corridor.dev/cli/install.sh | bash
```
```powershell theme={null}
# Windows (PowerShell)
irm https://app.corridor.dev/cli/install.ps1 | iex
```
2. The installer will automatically set up the Corridor plugin, MCP server, hooks, and agent rules
See [Factory setup](/ide-setup/factory) for detailed instructions.
Integrate Corridor with the Codex CLI via MCP and hooks.
1. Install the Corridor CLI:
```bash theme={null}
# macOS / Linux
curl -fsSL https://app.corridor.dev/cli/install.sh | bash
```
```powershell theme={null}
# Windows (PowerShell)
irm https://app.corridor.dev/cli/install.ps1 | iex
```
2. The installer detects the `codex` binary and automatically sets up the Corridor plugin, MCP server, hooks (macOS), and agent rules
See [Codex setup](/ide-setup/codex) for detailed instructions.
Integrate Corridor with Devin via MCP.
1. Generate a Corridor API token at [app.corridor.dev/settings](https://app.corridor.dev/settings)
2. In Devin, go to **Organization settings → MCP Marketplace** and add Corridor
3. Add your token in the **Authorization Header** field
4. Add new knowledge pinned to all repositories with a prompt instructing Devin to always call Corridor when generating code
See [Devin setup](/ide-setup/devin) for detailed instructions.
1. Open the Extensions panel in Devin Desktop (`Cmd+Shift+X` or `Ctrl+Shift+X`)
2. Search for "Corridor" and click **Install**
3. Reload your editor when prompted
4. Click the Corridor icon in the sidebar and sign in to your Corridor account
See [Devin Desktop setup](/ide-setup/devin-desktop) for detailed instructions.
Integrate Corridor with any MCP-compatible tool.
1. Generate a Corridor API token in your [Corridor settings](https://app.corridor.dev/settings)
2. Configure your MCP client with the following:
```json theme={null}
{
"mcpServers": {
"corridor": {
"transport": "http",
"url": "https://app.corridor.dev/api/mcp",
"headers": {
"Authorization": "Bearer {generated_token}"
}
}
}
}
```
Replace `{generated_token}` with your Corridor API token.
See [Custom MCP setup](/ide-setup/custom-mcp-servers) for detailed instructions.
## Step 4: (Optional) Invite team members
If you're on a Team or Enterprise plan, you can invite colleagues to join your Corridor workspace so they can benefit from the same guardrails and visibility.
In the Corridor web app, go to the **Teams** page.
Click **Invite Member**, enter their email, select a role, and click **Send Invite**.
See [Inviting Teammates](/onboarding/adding-team-members) for details. Skip this if you're an individual user.
## You're all set
That's it—Corridor is now set up! From this point on:
* **In the IDE**: Your AI assistant (e.g. Cursor or Claude Code) will consult Corridor's guardrails as you generate code, stopping insecure suggestions
* **For Pull Requests**: Corridor will automatically review new PRs on your connected project. You'll see comments or checks on the PR if any vulnerabilities are found
* **Dashboard**: You can monitor findings and adjust settings via the [Corridor Dashboard](https://app.corridor.dev)
You've successfully onboarded Corridor to your project—secure coding can now happen in real-time without breaking your flow.
## Next steps
Learn how real-time security analysis works
Configure automated pull request reviews
# Claude Code
Source: https://docs.corridor.dev/ide-setup/claude-code
Integrate Corridor with Claude Code for real-time security guardrails via MCP and hooks.
Corridor integrates with Claude Code via MCP and hooks, ensuring that code generated by Claude Code is checked against your security guardrails.
## Prerequisites
* [Claude Code](https://claude.ai/code) installed (`claude` command)
* A Corridor account with a team created
## Setup
Set up Corridor with Claude Code by installing the Corridor CLI.
Install the Corridor CLI with a single command.
macOS / Linux:
```bash theme={null}
curl -fsSL https://app.corridor.dev/cli/install.sh | bash
```
Windows (PowerShell):
```powershell theme={null}
irm https://app.corridor.dev/cli/install.ps1 | iex
```
The CLI auto-updates on startup, so you'll always have the latest version.
The installer will run `corridor install` automatically to set up the Corridor plugin, MCP server, and hooks.
Restart Claude Code if it's currently running. You can verify the plugin is connected by running `/mcp` in Claude Code.
Once configured, Claude Code will invoke Corridor's security checks as it writes code, catching vulnerabilities and enforcing your security policies automatically.
## Hooks
Hooks are deterministic scripts that run at specific points in the code generation process, enabling real-time security reviews and policy enforcement. Hooks are automatically set up by the Corridor CLI.
### MCP compliance
Corridor tracks which MCP servers are active and enforces your team's policies. To configure, navigate to the **Compliance** tab in the Corridor dashboard and choose **Allowlist Mode** or **Blocklist Mode**.
### Stop hooks (experimental)
When Claude Code generates code, Corridor can automatically evaluate the diff, identify potential security issues, and guide Claude to remediate problems iteratively—all in the background.
By default, hooks run in monitoring mode and won't block code generation. To enable blocking behavior:
1. Open `~/.corridor/config.env` in a text editor
2. Set `CORRIDOR_BLOCKING_STOP_HOOKS=true`
3. Hooks will now prevent code with critical security issues from being applied
### Troubleshooting hooks
If hooks are not running:
* Run `corridor install --force` to reinstall hooks
* Check that `~/.corridor/config.env` exists and contains a valid `CORRIDOR_ACCESS_TOKEN`
* Verify the plugin is registered in `~/.claude/settings.json` (in the `enabledPlugins` field)
## Uninstalling
To remove the Corridor CLI and all its configuration, run the uninstall script:
```bash theme={null}
curl -fsSL https://app.corridor.dev/cli/uninstall.sh | bash
```
The script removes the Corridor plugin, MCP server, hooks, and the `corridor` binary from `~/.corridor`, and cleans up the PATH entry it added to your shell profile (plus any legacy `~/.local/bin/corridor` symlink from older installs).
## Next steps
Learn how guardrails protect your code
Explore Corridor's MCP tools
# Codex
Source: https://docs.corridor.dev/ide-setup/codex
Integrate Corridor with Codex CLI for real-time security guardrails via MCP and hooks.
Corridor integrates with [Codex](https://github.com/openai/codex) via MCP and hooks, ensuring that code generated by the Codex CLI is checked against your security guardrails.
## Prerequisites
* Codex CLI installed (`codex` command available in `PATH`)
* A Corridor account with a team created
## Setup
Install the Corridor CLI with a single command:
macOS / Linux:
```bash theme={null}
curl -fsSL https://app.corridor.dev/cli/install.sh | bash
```
Windows (PowerShell):
```powershell theme={null}
irm https://app.corridor.dev/cli/install.ps1 | iex
```
The CLI auto-updates on startup, so you'll always have the latest version.
The installer runs `corridor install` automatically, detects the `codex` binary in `PATH`, and sets up the Corridor MCP server, hooks, and agent rules for Codex.
The installer simultaneously installs and updates Corridor for all supported CLI tools (including Claude Code and Factory). Run this one time to install Corridor across all of these agents. You will need to re-run the installer again if you download a new agent.
Restart Codex if it's currently running. You can verify the MCP server is connected by running `/mcp` inside Codex, or by inspecting `~/.codex/config.toml` for a `[mcp_servers.corridor]` entry.
Once configured, Codex will invoke Corridor's security checks as it writes code, catching vulnerabilities and enforcing your security policies automatically.
## Hooks
Hooks are deterministic scripts that run at specific points in the code generation process, enabling real-time security reviews and policy enforcement.
Corridor supports Codex hooks on **macOS**. MCP has full support on all platforms, so security policies are enforced at the plan level across coding agents.
### MCP compliance
Corridor tracks which MCP servers are active and enforces your team's policies. To configure, navigate to the **Compliance** tab in the Corridor dashboard and choose **Allowlist Mode** or **Blocklist Mode**.
### Troubleshooting hooks
If hooks are not running:
* Run `corridor install --force` to refresh the MCP entry in `~/.codex/config.toml` and the managed hooks payload.
* On macOS, confirm the managed hooks key is present:
```bash theme={null}
defaults read com.openai.codex requirements_toml_base64
```
### Codex auto-approval reviewer
When Codex runs in full-auto mode, its built-in approval reviewer evaluates every MCP tool call. By default it can flag a previously-unseen MCP server as "untrusted external MCP service" and deny `corridor.*` calls — the symptom is a message like *"Automatic approval review denied (risk: high, authorization: low)"* in the Codex output.
On macOS, `corridor install` writes a `guardian_policy_config` block alongside the managed hooks in `com.openai.codex requirements_toml_base64`. That block tells the reviewer the `corridor` MCP is trusted internal tooling, so `corridor.*` calls are auto-approved. If you previously installed Corridor before this was added, run `corridor install --force` to refresh the policy.
If you already have a `guardian_policy_config` in that same key, the installer **appends** its trust guidance as a clearly delimited section (between `===== BEGIN Corridor-managed trust policy ... =====` and `===== END Corridor-managed trust policy =====`) rather than replacing your policy. Reinstall refreshes only that section; uninstall removes only that section.
Codex reads managed requirements from several layers, and a higher-precedence layer wins. If your `guardian_policy_config` is enforced through cloud-managed configuration, an MDM profile, or `/etc/codex/requirements.toml`, the per-user macOS key Corridor writes may not take effect. In that case, add the Corridor-trust guidance to your managed policy directly. If you also configure an `mcp_servers` allowlist, it must include `corridor`, otherwise Codex disables the server entirely.
## Uninstalling
To remove the Corridor CLI and all its configuration, run the uninstall script:
```bash theme={null}
curl -fsSL https://app.corridor.dev/cli/uninstall.sh | bash
```
## Next steps
Learn how guardrails protect your code
Explore Corridor's MCP tools
# Cursor
Source: https://docs.corridor.dev/ide-setup/cursor
Install Corridor in Cursor via the Cursor Marketplace Plugin, the Corridor extension, or both.
Corridor has two integrations for Cursor. They serve different workflows and can be used independently or side-by-side.
* **[Cursor Plugin](#option-1-corridor-cursor-plugin)** — a Cursor Marketplace Agent that uses the `/corridor` skill to review code in the background as Cursor Agents work. Use this if you want a frictionless, Cursor-native experience with the least setup.
* **[Corridor extension](#option-2-corridor-extension)** — a VS Code-style extension that registers Corridor as an MCP server and runs deterministic hooks. Use this if you want MCP-based tool access, MCP compliance enforcement, or stop hooks that can block code with critical findings.
## Prerequisites
* [Cursor](https://www.cursor.com) installed
* A Corridor account with a team created
***
## Option 1: Corridor Cursor Plugin
The Corridor Cursor Plugin layers real-time security reviews directly into Cursor. As Cursor plans and generates code, Corridor reviews the plan and proactively guides the coding agent to prevent vulnerabilities before code is written.
### Installation
Inside Cursor, open the **Agents** tab and navigate to the **Marketplace**.
Find Corridor in the Marketplace and click **Get**.
Click **New Agent** and make sure the agent is configured as **Local**. Once configured, Corridor begins operating alongside your Cursor workflows automatically.
### Using the Corridor skill
Start using Corridor by invoking the skill with `/corridor` in any Cursor chat. The skill reviews your code for vulnerabilities and enforces security best practices in your coding agent.
The `/corridor` skill is a lightweight subset of Corridor's full capabilities. To unlock team-level guardrails, finding history, and the full Corridor knowledge base, authenticate with the Corridor API as described below.
### Authenticate with the Corridor API (optional)
Generate an API key from **Profile > API Tokens** in the [Corridor dashboard](https://app.corridor.dev). See the [API reference](/api/reference#authentication) for details on token scope.
Add the following line to your `~/.zshrc` (or `~/.bashrc`):
```bash theme={null}
export CORRIDOR_API_KEY=your_api_key_here
```
Restart Cursor so the new environment variable is picked up by the Local Agent.
Treat your `CORRIDOR_API_KEY` like any other secret. Don't commit it to source control, and don't paste it into shared chat threads or AI prompts.
***
## Option 2: Corridor extension
The Corridor extension installs through Cursor's Extensions panel and provides MCP server registration plus deterministic hooks (file edits, stops, MCP compliance enforcement).
### Installation
In Cursor, open the Extensions panel by pressing `Cmd+Shift+X` (macOS) or `Ctrl+Shift+X` (Windows/Linux).
Type "Corridor" in the search box.
Click **Install** on the Corridor extension.
Reload Cursor when prompted, or restart it manually.
After installation, you'll see the Corridor icon in your sidebar.
### Authentication
Click the Corridor icon in the activity bar.
Click **Sign in to Corridor** and complete the browser authentication flow.
After authentication, your team name appears in the Corridor panel. Cursor will now consult Corridor's guardrails as you generate code, and a Cursor rule is written to `.cursor/rules/corridor-mcp-server-usage.mdc` to direct your AI assistant to Corridor's MCP tools.
### Hooks
Hooks are deterministic scripts that run at specific points in the code generation process, enabling real-time security reviews and policy enforcement without interrupting your development flow. Hooks are automatically enabled in the latest version of the Corridor extension.
#### MCP compliance
Corridor tracks which MCP servers are active in your workspace and enforces your team's policies. Unlike MCP relays, this approach integrates directly without adding latency or complexity.
To configure MCP compliance settings, navigate to the **Compliance** tab in the Corridor dashboard and choose **Allowlist Mode** (allow only specific MCP servers) or **Blocklist Mode** (block specific MCP servers).
#### Stop hooks (experimental)
When an AI agent generates code, Corridor can automatically evaluate the diff at the moment of creation, identify potential security issues, and guide the agent to remediate problems iteratively — all in the background without disrupting your flow.
By default, hooks run in monitoring mode and won't block code generation. To enable blocking behavior:
1. Open the Command Palette with `Cmd+Shift+P` (macOS) or `Ctrl+Shift+P` (Windows/Linux)
2. Search for **Corridor: Enable Stop Hooks** and select it
3. Hooks will now prevent code with critical security issues from being applied
### Troubleshooting
If hooks are not running:
* Verify you're using the latest version of the Corridor extension
* Check that the extension is properly authenticated
* Ensure that you've enabled hooks in the extension
If Corridor's MCP tools are not appearing in Cursor:
* Reload Cursor (`Cmd+Shift+P` → **Developer: Reload Window**)
* Open the Corridor panel and confirm you're signed in — the MCP server is only registered after successful authentication
* Confirm Cursor's MCP support is enabled in **Cursor Settings → MCP**
## Next steps
Install the Corridor extension in VS Code with MCP and hooks support.
Learn how Corridor's guardrails review and harden AI-generated code.
# Custom MCP
Source: https://docs.corridor.dev/ide-setup/custom-mcp-servers
Set up Corridor as an MCP server for any AI coding tool that supports the Model Context Protocol.
Corridor can integrate with any MCP-compatible tool. Corridor's MCP server is standards-compliant, so any tool that can call an MCP endpoint can leverage Corridor's security guardrails.
## Prerequisites
* An AI coding tool that supports MCP servers
* A Corridor account with a team created
## Setup
Generate a Corridor API token in your [Corridor settings](https://app.corridor.dev/settings).
Configure your MCP client with the following:
```json theme={null}
{
"mcpServers": {
"corridor": {
"transport": "http",
"url": "https://app.corridor.dev/api/mcp",
"headers": {
"Authorization": "Bearer {generated_token}"
}
}
}
}
```
Replace `{generated_token}` with your Corridor API token. Prefer the `Authorization` header over putting the token in the URL query string. The exact configuration format may vary depending on your tool—refer to your tool's documentation for how to add an HTTP MCP server.
Once configured, your AI tool will consult Corridor's guardrails during code generation, providing security feedback automatically.
## Next steps
Learn how guardrails protect your code
Explore Corridor's MCP tools
# Devin
Source: https://docs.corridor.dev/ide-setup/devin
Integrate Corridor with Cognition's Devin AI coding assistant for real-time security guardrails.
Corridor integrates with Devin via MCP, providing security guardrails to Devin's AI agent as it writes and refactors code.
## Prerequisites
* A Devin account with access to Organization settings
* A Corridor account with a team created
## Setup
Generate a Corridor API token at [app.corridor.dev/settings](https://app.corridor.dev/settings).
In Devin, go to **Organization settings → MCP Marketplace** and add Corridor. Add your token in the **Authorization Header** field.
Add new knowledge pinned to all repositories with a prompt instructing Devin to always call Corridor when generating code. This ensures Devin's agent consults Corridor's guardrails on every task.
Once configured, Corridor becomes Devin's security conscience—providing proactive security context so Devin avoids insecure suggestions from the start.
## Next steps
Learn how guardrails protect your code
Explore Corridor's MCP tools
# Devin Desktop
Source: https://docs.corridor.dev/ide-setup/devin-desktop
Integrate Corridor with Devin Desktop for real-time security guardrails via MCP and hooks.
Corridor integrates with Devin Desktop through the Corridor extension, providing real-time security guardrails as you code with AI assistants via MCP and hooks.
## Prerequisites
* Devin Desktop installed
* A Corridor account with a team created
## Installation
In Devin Desktop, open the Extensions panel by pressing `Cmd+Shift+X` (macOS) or `Ctrl+Shift+X` (Windows/Linux).
Type "Corridor" in the search box.
Click **Install** on the Corridor extension.
Reload your editor when prompted, or restart it manually.
After installation, you'll see the Corridor icon in your sidebar.
## Authentication
Click the Corridor icon in the activity bar.
Click **Sign in to Corridor** and complete the browser authentication flow.
After authentication, your team name appears in the Corridor panel. Your AI assistant will now consult Corridor's guardrails as you generate code.
## Hooks
Hooks are deterministic scripts that run at specific points in the code generation process, enabling real-time security reviews and policy enforcement without interrupting your development flow. Hooks are automatically enabled in the latest version of the Corridor extension.
### MCP compliance
Corridor tracks which MCP servers are active in your workspace and enforces your team's policies. Unlike MCP relays, this approach integrates directly without adding latency or complexity.
To configure MCP compliance settings, navigate to the **Compliance** tab in the Corridor dashboard and choose **Allowlist Mode** (allow only specific MCP servers) or **Blocklist Mode** (block specific MCP servers).
### Troubleshooting hooks
If hooks are not running:
* Verify you're using the latest version of the Corridor extension
* Check that the extension is properly authenticated
* Ensure that you've enabled hooks in the extension
## Next steps
Learn how guardrails protect your code
Explore Corridor's MCP tools
# Factory
Source: https://docs.corridor.dev/ide-setup/factory
Integrate Corridor with Factory's AI Droid agents for secure automated development.
Corridor integrates with Factory's AI Droid agents via MCP and hooks, ensuring that code generated by Factory agents is checked against your security guardrails.
## Prerequisites
* A Factory account
* A Corridor account with a team created
## Setup
Install the Corridor CLI with a single command:
macOS / Linux:
```bash theme={null}
curl -fsSL https://app.corridor.dev/cli/install.sh | bash
```
Windows (PowerShell):
```powershell theme={null}
irm https://app.corridor.dev/cli/install.ps1 | iex
```
The CLI auto-updates on startup, so you'll always have the latest version.
The installer will run `corridor install` automatically to set up the Corridor plugin, MCP server, and hooks.
Restart Factory Droid if it's currently running. The Corridor plugin will be automatically configured with the necessary agent rules and MCP server settings.
Once configured, the Factory Droid agent will invoke Corridor's security checks as it writes code, catching vulnerabilities and enforcing your security policies automatically.
## Hooks
Hooks are deterministic scripts that run at specific points in the code generation process, enabling real-time security reviews and policy enforcement. Hooks are automatically set up by the Corridor CLI.
### MCP compliance
Corridor tracks which MCP servers Factory Droid invokes and enforces your team's policies. To configure, navigate to the **Compliance** tab in the Corridor dashboard and choose **Allowlist Mode** or **Blocklist Mode**. See [MCP Compliance](/features/mcp-compliance) for details.
### Troubleshooting hooks
If hooks are not running:
* Run `corridor install --force` to reinstall hooks
* Verify the plugin is registered in `~/.factory/settings.json`
## Uninstalling
To remove the Corridor CLI and all its configuration, run the uninstall script:
```bash theme={null}
curl -fsSL https://app.corridor.dev/cli/uninstall.sh | bash
```
The script removes the Corridor plugin, MCP server, hooks, and the `corridor` binary from `~/.corridor`, and cleans up the PATH entry it added to your shell profile (plus any legacy `~/.local/bin/corridor` symlink from older installs).
## Next steps
Learn how guardrails protect your code
Explore Corridor's MCP tools
# VS Code
Source: https://docs.corridor.dev/ide-setup/vscode
Install the Corridor extension for real-time security guardrails in VS Code.
Corridor integrates with VS Code through the Corridor extension, providing real-time security guardrails as you code with AI assistants.
Using Cursor? See [Cursor setup](/ide-setup/cursor) for the two ways to install Corridor in Cursor.
## Prerequisites
* VS Code installed
* A Corridor account with a team created
* **GitHub Copilot users:** GitHub Copilot with [agent mode](https://code.visualstudio.com/docs/copilot/chat/chat-agent-mode) enabled. If your organization manages Copilot through **GitHub Enterprise**, an admin must enable external MCP servers in the Copilot policy settings (see [Enable MCP for GitHub Copilot](#enable-mcp-for-github-copilot) below).
## Installation
In VS Code, open the Extensions panel by pressing `Cmd+Shift+X` (macOS) or `Ctrl+Shift+X` (Windows/Linux).
Type "Corridor" in the search box.
Click **Install** on the Corridor extension.
Reload VS Code when prompted, or restart it manually.
After installation, you'll see the Corridor icon in your sidebar.
## Authentication
Click the Corridor icon in the activity bar.
Click **Sign in to Corridor** and complete the browser authentication flow.
After authentication, your team name appears in the Corridor panel. Your AI assistant will now consult Corridor's guardrails as you generate code.
## Enable MCP for GitHub Copilot
Corridor's MCP server is automatically registered with VS Code when you install and authenticate the Corridor extension. However, GitHub Copilot must have MCP support enabled to use it.
### Personal accounts
MCP support in GitHub Copilot requires **agent mode**. Verify it's enabled:
1. Open VS Code Settings (`Cmd+,` on macOS or `Ctrl+,` on Windows/Linux)
2. Search for `chat.agent.enabled`
3. Ensure the setting is checked
### GitHub Enterprise / Organization accounts
If your organization manages GitHub Copilot through **GitHub Enterprise**, an organization or enterprise admin must explicitly allow external MCP servers. Without this, Copilot will silently ignore MCP tools — including Corridor.
Go to your organization on GitHub and navigate to **Settings → Copilot → Policies** (or for enterprise accounts, **Enterprise settings → Policies → Copilot**).
Under **Copilot in the IDE**, find the **Agent mode** policy and set it to **Enabled** (or **No policy** to let individual members choose).
Under **Copilot in the IDE**, find the **MCP servers** policy. Set it to **Enabled** to allow members to use external MCP servers like Corridor, or select **No policy** to let individual members choose.
If external MCP servers are **disabled** in your organization's Copilot policy, the Corridor MCP server will not appear in GitHub Copilot's tool list — even though the extension is installed and authenticated. This is the most common setup issue for enterprise users.
After changing organization policies, team members may need to reload VS Code for the new settings to take effect.
## Hooks
Hooks are deterministic scripts that run at specific points in the code generation process, enabling real-time security reviews and policy enforcement without interrupting your development flow. Hooks are automatically enabled in the latest version of the Corridor extension.
### MCP compliance
Corridor tracks which MCP servers are active in your workspace and enforces your team's policies. Unlike MCP relays, this approach integrates directly without adding latency or complexity.
To configure MCP compliance settings, navigate to the **Compliance** tab in the Corridor dashboard and choose **Allowlist Mode** (allow only specific MCP servers) or **Blocklist Mode** (block specific MCP servers).
### Stop hooks (experimental)
When an AI agent generates code, Corridor can automatically evaluate the diff at the moment of creation, identify potential security issues, and guide the agent to remediate problems iteratively—all in the background without disrupting your flow.
By default, hooks run in monitoring mode and won't block code generation. To enable blocking behavior:
1. Open the Command Palette with `Cmd+Shift+P` (macOS) or `Ctrl+Shift+P` (Windows/Linux)
2. Search for **Corridor: Enable Stop Hooks** and select it
3. Hooks will now prevent code with critical security issues from being applied
### Troubleshooting hooks
If hooks are not running:
* Verify you're using the latest version of the Corridor extension
* Check that the extension is properly authenticated
* Ensure that you've enabled hooks in the extension
### Troubleshooting GitHub Copilot MCP
If Corridor's MCP tools are not appearing in GitHub Copilot:
* **Check agent mode**: Ensure agent mode is enabled in VS Code settings (`chat.agent.enabled`). Corridor's MCP tools only work in agent mode.
* **Check organization policies**: If you're on a GitHub Enterprise or Organization-managed Copilot plan, verify that your admin has enabled both **Agent mode** and **MCP servers** in the [Copilot policy settings](https://docs.github.com/en/copilot/managing-copilot/managing-github-copilot-in-your-organization/managing-policies-for-copilot-in-your-organization). See [Enable MCP for GitHub Copilot](#enable-mcp-for-github-copilot) above.
* **Reload VS Code**: After enabling policies or installing the extension, reload VS Code (`Cmd+Shift+P` → **Developer: Reload Window**).
* **Verify extension authentication**: Open the Corridor panel and ensure you're signed in. The MCP server is only registered after successful authentication.
## Next steps
Set up Corridor in Cursor via the Marketplace Plugin or the extension.
Set up Corridor with Claude Code CLI.
Learn how guardrails protect your code.
# Welcome
Source: https://docs.corridor.dev/index
Secure AI Coding at the Source. Corridor accelerates AI coding by preventing security flaws before they're even written.
# Welcome to Corridor
Corridor is an AI-powered code security platform that integrates directly into the development workflow. It works with AI coding tools to prevent vulnerabilities before they're written and automatically reviews code for security issues. By providing real-time security guardrails to coding assistants (like Cursor, Claude Code, and GitHub Copilot), Corridor enables teams to ship code faster without sacrificing security.
## Quickstart
First, [sign in](https://app.corridor.dev) and connect a GitHub repository. Then set up your coding tool:
**CLI agents** (Claude Code, Codex, Factory) — copy and run:
macOS / Linux:
```bash theme={null}
curl -fsSL https://app.corridor.dev/cli/install.sh | bash
```
Windows (PowerShell):
```powershell theme={null}
irm https://app.corridor.dev/cli/install.ps1 | iex
```
**Editors** — click to install the Corridor extension:
Install the Corridor extension in VS Code
Install the Corridor extension in Cursor
Install the Corridor extension in Devin Desktop
See the [full quickstart](/getting-started/quickstart) for connecting GitHub, adding projects, and inviting your team.
Get up and running with Corridor in under 5 minutes
Install the Corridor extension for VS Code and Cursor
Real-time security analysis during AI code generation
Automated security reviews on every pull request
## Why Corridor?
Modern software development moves at high speed – especially with AI coding assistance – but traditional application security hasn't kept up. Security reviews often drag on, scanners produce many false positives, and critical issues slip through into production. A reactive approach that catches bugs late doesn't scale to the pace of AI-accelerated development.
Corridor addresses this gap by embedding security into the development process. It acts as an AI security architect that empowers developers to write secure code from the start, rather than fixing bugs after the fact. This means security teams can move at the speed of code, focusing on prevention instead of endless reactive fixes.
## What we do
Corridor provides a layered solution to make code secure by design:
* **Real-time guardrails**: Give AI coding agents the context and rules they need to write secure code from the beginning, preventing vulnerabilities at the source
* **Automated PR reviews**: Scan every pull request for security issues and leave detailed findings and remediation guidance directly in your workflow
* **Security findings in code**: Analyze your existing codebase to surface security findings—vulnerabilities, weak configurations, and more—with severity ratings and recommended fixes
* **Continuous observability**: Monitor all AI-generated code and security policy compliance, providing visibility into how code is being written and flagging any policy violations
## Get started
Learn about Corridor's core concepts
Set up Corridor for your team
Integrate with Claude Code CLI
# GitHub
Source: https://docs.corridor.dev/integrations/github
Connect GitHub repositories for automated PR reviews and security status checks.
# GitHub Integration
Corridor integrates with GitHub to provide automated PR reviews on every pull request. Connect your repositories to get security analysis before code merges.
## What you get
* **Automated PR reviews**: Every pull request analyzed for security vulnerabilities
* **Inline comments**: Findings posted directly on the affected code lines
* **Corridor Review check**: A non-blocking GitHub check that mirrors scan progress on the PR head commit
* **Blocking PRs**: Optionally require Corridor as a status check so merges are blocked until findings are resolved
* **Finding tracking**: Issues persist and track through remediation
## Connecting GitHub
### Install the GitHub App
In the Corridor dashboard, go to your project and click **Settings → GitHub**.
Click **Install GitHub App** and select your GitHub organization.
Choose which repositories to grant Corridor access to.
Toggle on **Automated PR Reviews** for the connected repository.
### Required permissions
The Corridor GitHub App requests:
| Permission | Access | Purpose |
| ------------- | ---------- | ----------------------------- |
| Code | Read | Analyze code in pull requests |
| Metadata | Read | Repository information |
| Pull requests | Read/Write | Post review comments |
| Checks | Read/Write | Update status checks |
Corridor only reads code during PR review. We analyze the diff, not your entire codebase, and don't store source code beyond what's needed for review.
## How PR reviews work
When a pull request is opened or updated:
1. GitHub sends a webhook to Corridor
2. Corridor fetches and analyzes the changed files
3. Security review is generated with findings
4. Review is posted to the PR
5. The **Corridor Review** check on the pull request moves from Queued to In progress to Success as the review runs, with a **Details** link back to Corridor
6. Status check is updated
```
PR opened → Webhook → Analysis → Review posted → Status check
↓
Findings created
```
### Review timing
Reviews typically complete within 1-2 minutes. Large PRs or high-volume periods may take longer.
## Corridor Review check
Corridor publishes a **Corridor Review** check on every reviewed pull request. The check does not block merging on its own—it surfaces review progress and a link back to Corridor.
| State | Meaning |
| --------------- | --------------------------------- |
| **Queued** | The review is waiting to start |
| **In progress** | Corridor is analyzing the changes |
| **Success** | The review is finished |
Click **Details** to open this review in Corridor, where you can see findings, status, and history.
## Blocking merges on findings
Corridor can act as a required status check so pull requests with unresolved findings can't be merged. There are two parts: choose which finding severities block a merge in Corridor (**PR Reviews → Settings → Block PRs with Security Findings**), then require the **Corridor Review** check in your GitHub branch protection or rulesets.
| Corridor Review result | Meaning |
| ---------------------- | -------------------------------------------------------------------------------------------------------- |
| **Success** | No open findings at your blocking severities |
| **Failure** | One or more findings need attention—the merge is blocked when the check is required in branch protection |
See [Blocking PRs](/features/blocking-prs) for the full setup, including branch protection and rulesets, and how developers clear the check (fix, false positive, or unblock).
## Review settings
Configure PR review behavior:
| Setting | Description |
| ------------------ | ------------------------------------------- |
| **Review all PRs** | Review every pull request |
| **Skip draft PRs** | Don't review until PR is ready for review |
| **Branch filter** | Only review PRs targeting specific branches |
## OAuth authentication
Users can sign in to Corridor with their GitHub account:
1. Click **Sign in with GitHub**
2. Authorize Corridor to access your GitHub identity
3. Your Corridor account links to your GitHub profile
This is separate from the GitHub App, which grants repository access.
## Troubleshooting
### Reviews not appearing
1. Verify the GitHub App is installed on the repository
2. Check that PR reviews are enabled in project settings
3. Look at webhook deliveries in GitHub for errors:
* Go to your GitHub organization settings
* Click **Developer settings → GitHub Apps**
* Find Corridor and click **Configure**
* Check **Recent deliveries** for failures
### Status checks stuck pending
1. Check webhook delivery succeeded
2. Verify your team has available PR review credits
3. Large PRs take longer—wait a few minutes
4. Check the Corridor dashboard for processing status
### Permission errors
1. Re-install the GitHub App with correct repository access
2. Ensure the repository is selected in GitHub App configuration
3. Verify your GitHub user has write access to the repo
### Webhook delivery failures
1. Go to GitHub App settings
2. Check **Recent deliveries**
3. Look for HTTP errors (4xx, 5xx)
4. If persistent, contact [support@corridor.dev](mailto:support@corridor.dev)
## Next steps
Learn more about automated reviews
Manage your projects
# GitLab
Source: https://docs.corridor.dev/integrations/gitlab
Connect GitLab repositories for automated merge request reviews and security scanning.
# GitLab Integration
Corridor integrates with GitLab to import your repositories, scan code for security vulnerabilities, and generate guardrails tailored to each project. When merge requests are opened or updated, Corridor automatically reviews the changes and posts findings directly on the MR.
## What you get
* **Automated MR reviews**: Every merge request analyzed for security vulnerabilities
* **Inline comments**: Findings posted directly on the affected code lines
* **Finding tracking**: Issues persist and track through remediation
* **Guardrail generation**: Security guardrails tailored to your project's stack
## Prerequisites
* A Corridor account with admin access to your team
* A GitLab account with access to the group containing your repositories
## Connecting GitLab.com
In the Corridor dashboard, go to **Teams** and click **Connect GitLab**.
You'll be redirected to GitLab to authorize Corridor. Review the permissions and click **Authorize**.
After authorization, select the GitLab group containing the repositories you want to monitor.
Only one group can be connected per team. If you need to change groups later, you'll need to disconnect and reconnect.
## Connecting a Self-Hosted GitLab Instance
Self-hosted GitLab instances require you to create an OAuth application on your GitLab instance so that Corridor can authenticate with it.
Before setting up the integration, contact the Corridor team at [support@corridor.dev](mailto:support@corridor.dev) to have your GitLab instance domain whitelisted. The connection will not work until this step is complete.
Email [support@corridor.dev](mailto:support@corridor.dev) with your self-hosted GitLab instance URL (e.g., `https://gitlab.yourcompany.com`). The Corridor team will whitelist your domain so the integration can communicate with your instance.
Go to your GitLab instance's **Admin Area → Applications** (`https://gitlab.yourcompany.com/admin/applications/new`) or **User Settings → Applications** (`https://gitlab.yourcompany.com/-/user_settings/applications`) and create a new application with:
* **Name**: `Corridor Security`
* **Redirect URI**: `https://app.corridor.dev/api/auth/gitlab/callback`
* **Confidential**: Checked
* **Scopes**: `api`
Leave **Trusted** unchecked. After saving, copy the **Application ID** and **Secret**.
In the Corridor dashboard, go to **Teams** and click **Connect GitLab (Self-Hosted)**. Enter your GitLab instance URL, the Application ID, and the Secret from the previous step.
You'll be redirected to your GitLab instance to authorize Corridor. Review the permissions and click **Authorize**.
After authorization, select the GitLab group containing the repositories you want to monitor.
## Permissions
Corridor requests the `api` scope from GitLab. This scope is used for both read operations and to set up automated security reviews on your merge requests. Here's what that access covers:
| Resource | Usage |
| ------------------------- | --------------------------------------------------------------------------- |
| **Groups** | List available groups during setup |
| **Projects** | List repositories in your group for import |
| **Repository code** | Clone and scan code for security analysis |
| **Webhooks** | Register per-project webhooks to trigger security reviews on merge requests |
| **Merge requests** | Read MR diffs for security review and post review comments with findings |
| **Project access tokens** | Create a bot token per project ("Corridor Security") to post MR comments |
GitLab does not offer granular OAuth scopes for these individual operations, so `api` is the minimum scope required. OAuth tokens are encrypted at rest and automatically refreshed when they expire. Corridor does not store your source code beyond what is needed for analysis.
## Importing repositories
Navigate to **Projects** and click **New Project**.
Select the **GitLab Repository** tab.
Choose a repository from the list, or paste a GitLab repository URL directly.
Corridor will register a webhook on the project, scan the repository, and generate security guardrails.
## Troubleshooting
### Reviews not appearing
1. Verify GitLab is connected in your team settings
2. Check that the project was imported from GitLab (not added manually)
3. Verify the webhook is registered on the GitLab project:
* Go to your GitLab project → **Settings → Webhooks**
* Look for a Corridor webhook
* Check **Recent events** for delivery failures
### Permission errors
1. Reconnect GitLab from **Teams** settings
2. Ensure your GitLab user has at least Maintainer access to the project
3. Verify the project belongs to the connected GitLab group
### Webhook delivery failures
1. Go to the GitLab project → **Settings → Webhooks**
2. Find the Corridor webhook and click **Edit**
3. Check **Recent events** for HTTP errors (4xx, 5xx)
4. If persistent, contact [support@corridor.dev](mailto:support@corridor.dev)
## Next steps
Learn more about automated reviews
Configure security guardrails for your project
# Adding Projects
Source: https://docs.corridor.dev/onboarding/adding-projects
Import repositories as Corridor projects for security monitoring.
Once GitHub is connected, the next step is to import a repository as a Corridor Project. A Project in Corridor represents a repository that you want to secure.
## Create a project
In the Corridor dashboard, navigate to the **Projects** section. Click **New Project**.
You'll see a list of repositories that Corridor has access to (based on the GitHub authorization you completed). Choose the repo you want to bring under Corridor's monitoring.
Corridor will ask for confirmation to import the repository. Confirm the selection.
After adding, Corridor scans the repository and generates guardrails for that project. You can add additional guardrails by selecting the project → **Guardrails** → **Add Guardrail**. See [Configuring Guardrails](/onboarding/configuring-guardrails) for more info.
If you skip this step, Corridor won't actively monitor code. Connecting GitHub alone is not enough—you must add specific repos as projects for Corridor to know where to operate.
## Project settings
Each project has its own **Settings** tab. Select a project from the Projects page, then click **Settings** to manage the options below.
### PR review settings
Every project inherits its PR review configuration from the team defaults set on the **PR Reviews** page. On a project's **Settings** tab, you can override any individual setting for that project:
* **Enable Pull Request Reviews**
* **Review Verbosity Mode** (Strict, Balanced, Relaxed)
* **Leave Comments on Pull Requests**
* **Enable Draft PR Reviews**
* **GitHub Label Filter**
* **Comment When No Issues Found**
* **Minimum Severity to Comment On**
* **Enable Threat Modeling**
See [PR Reviews → Configuration](/features/pr-reviews#configuration) for what each setting does.
**How overrides work:**
* By default, every setting inherits from the team. Changing a setting at the team level also updates any project that hasn't overridden that specific setting.
* The first time you override a setting on a project, Corridor shows a confirmation dialog listing the settings that will no longer inherit from the team.
* Overrides are per-setting. Overriding verbosity on a project does not detach the other settings from the team default.
* Click **Reset to Team Defaults** to clear all overrides for the project and resume inheriting from the team.
Per-project settings are useful when repos have different noise tolerances or review needs—for example, keeping strict commenting on a customer-facing service while only reviewing (without commenting) on an internal tool.
### Edit project name
Click **Edit Project Name** in the **Actions** section to rename the project. The Git URL and underlying repository are not affected.
### Delete a project
Click **Delete Project** in the **Actions** section. Deleting a project removes it from Corridor and stops PR reviews, guardrails, and findings for that repository. The underlying GitHub repository is not affected.
## Next steps
Invite your team to Corridor
Track security metrics
# Inviting Teammates
Source: https://docs.corridor.dev/onboarding/adding-team-members
Invite team members and manage roles in Corridor.
If you're using Corridor with a team (Team or Enterprise plan), you can invite colleagues so they can add the IDE extension and view Corridor's security insights.
## Invite a member
In the Corridor web app, go to the **Teams** page.
1. Click **Invite Member**
2. Enter the work email of the person you want to invite
3. Select a role (see below for role details)
4. Click **Send Invite**
They'll receive an email invitation with a link to join your Corridor team.
## Team roles
| Role | Permissions |
| ----------------- | ------------------------------------------------------------------------------------------------------------------- |
| **Owner** | Full access—manage members, billing, integrations, and all team settings |
| **Admin** | Manage projects, guardrails, and findings, use IDE extension, respond to findings. Cannot manage members or billing |
| **Standard User** | Use IDE extension and MCP guardrail checks only—no dashboard access |
The **Standard User** role is useful for larger teams where not every developer needs to manage Corridor, only to use it.
## Onboarding new members
When the invited user clicks the link in their email:
1. They will automatically be added to your team upon accepting the invite
2. The GitHub App is typically installed at the team level, so individual devs may not need to do separate OAuth
## Domain verification
Enterprises can complete domain verification so that anyone with their company's email domain can automatically sign into Corridor. Under **Team Details** on the **Teams** page, follow the steps under **Domain Verification**. Anyone who logs in without being invited will automatically become a Standard User.
## Post-invite instructions
Once a teammate joins, guide them on how to start:
* **IDE Setup**: Instruct them to install the Corridor integration in their IDE (Cursor, VS Code, etc.) so they get guardrails while coding. They can follow the docs under [IDE Setup](/ide-setup/vscode)
* **Viewing the Dashboard**: Owners and Admins will have access to the Corridor dashboard for the team's projects
* **Handling Findings**: Developers can start by looking at open findings for their projects and addressing them
## Managing members
Team members can be modified and removed by clicking the three dots next to their role on the **Teams** page.
## Team limits
| Tier | Team Members |
| ---------- | ------------ |
| Pro | 1 |
| Team | Up to 20 |
| Enterprise | Custom |
## Next steps
Set up security guardrails for your team
Track security metrics
# Configuring Guardrails
Source: https://docs.corridor.dev/onboarding/configuring-guardrails
Enable and configure security guardrails for your team.
After you've added projects, you may want to fine-tune which guardrails are in effect or add new ones. Configuring guardrails ensures Corridor is focusing on relevant issues and enforcing any specific policies your organization needs.
Guardrails can be configured at two levels:
* **Project level** (all plans): Configure guardrails for a specific project by selecting the specific project and then clicking **Guardrails**.
* **Team level** (Enterprise only): Configure guardrails across all projects from the **Guardrails** page. Team-level guardrails provide greater control and consistency across projects.
Both levels expose the same settings, but team-level guardrails allow enterprises to enforce policies uniformly without configuring each project individually.
## Default guardrails
By default, Corridor applies the **Corridor Default Security Pack**: a comprehensive pack of essential security guardrails covering common vulnerability classes including injection attacks, authentication issues, and access control flaws.
## Guardrail packs
Corridor provides a menu of pre-loaded security packs tailored to specific languages, app types, and standards. Teams can also create custom packs on the **Guardrails** page comprised of guardrails unique to their needs.
## Custom guardrails
Custom guardrails are available on **Team** and **Enterprise** plans.
To create a custom guardrail, go to your project → **Guardrails** → **Add Guardrail**. You'll have three options:
* **Auto-Generate Guardrail**: Describe the vulnerability or vulnerability type, and Corridor will automatically create a guardrail for it.
* **Create Manually**: Write your own guardrail from scratch. It's best practice to clearly articulate in plain language the security requirements for the guardrail, including any relevant internal libraries or standards to adhere to. Think of these as the security standards you would share with your engineering team.
* **Import from Document**: Upload a document, and Corridor will automatically generate guardrails based on its contents.
## Adding custom context
Custom context is available on **Team** and **Enterprise** plans.
You can add context documents or notes to enhance security reviews:
1. Look for an **Add Context** option in the guardrails settings
2. Paste text (like a policy excerpt) or upload a file
3. Select whether the context applies to **PR Reviews** and/or **MCP Plan** (to guide agentic code generation)
Context expands Corridor's knowledge to include your security expertise, making AI reviews more relevant and reducing false positives.
## Verify guardrails are working
After adjusting guardrails, it's a good idea to test them:
1. Open a project in your IDE with the Corridor extension installed
2. Try writing code that violates a guardrail (e.g., if you added "no eval allowed", use `eval` in a code generation prompt)
3. Corridor should catch and flag it
4. You can also trigger a test pull request that violates a guardrail to ensure Corridor comments appropriately
## Tuning guardrails
Guardrail configuration is key to reducing false positives and false negatives:
* If Corridor is flagging too many things that aren't issues, consider loosening or turning off certain guardrails (or improving context)
* If Corridor misses something important, consider adding a new guardrail or tightening an existing one
## Next steps
Deep dive into how guardrails work
Install the IDE extension
# Connecting GitHub
Source: https://docs.corridor.dev/onboarding/connecting-github
Connect your GitHub account and repositories to Corridor.
To integrate Corridor with your code, the first onboarding step is connecting your version control. Currently GitHub is supported (GitHub Cloud and GitHub Enterprise via app installation).
## Prerequisites
* A Corridor account
* Admin access to the GitHub repositories you want to connect
## Connect your GitHub account
In the Corridor app, click **Connect GitHub** (this appears during sign-up or on [app.corridor.dev/teams](https://app.corridor.dev/teams) under **Team Details**). This will redirect you to GitHub to authorize the Corridor GitHub App.
During the GitHub authorization flow, you'll have the option to either grant access to **All repositories** or select specific ones.
* If you plan to use Corridor on many repos, selecting **All repositories** is convenient (you can still add only specific projects later in Corridor).
* If you prefer to limit access, choose **Only select repositories** and pick the repos you want Corridor to have access to.
If you go with selected repos, you'll need to revisit this if you want to add more projects in Corridor later (to grant Corridor access to the new repo).
Approve the installation/authorization. You'll be redirected back to Corridor when done.
## Permissions requested
Corridor's GitHub App requests the following permissions needed to scan code changes and provide feedback directly on PRs:
| Permission | Access | Purpose |
| ------------------- | ---------- | -------------------------------- |
| **Code** | Read | Analyze code for security issues |
| **Pull requests** | Read/Write | Post PR review comments |
| **Checks** | Read/Write | Update status checks |
| **Commit statuses** | Read | Track review status |
If using GitHub Enterprise Server, ensure your admin has installed the Corridor app on your GHES instance with appropriate scopes.
## What happens after connecting
After connecting, Corridor now has the ability to read the code and post PR comments for the repositories you allowed. However, you still need to **add each repository as a Project** inside Corridor to kick off scans (see [Adding Projects](/onboarding/adding-projects)). The GitHub connection just sets up credentials—it doesn't automatically start scanning every repo until you specify.
## Next steps
Create projects from your connected repositories
Learn about automated security reviews