# 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, SSO, single-tenant |
### 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**: 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** | - | - | ✓ |
| **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 |
| Fleet | 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.
## Managing PATH yourself
By default the installer adds `~/.corridor/bin` to `PATH` by appending a small block to one of the user's shell profiles (`~/.zshenv` for zsh, the existing bash login profile on macOS, `~/.bashrc` on Linux). The entry is always appended, never prepended, so system binaries keep priority, and it is guarded so nested shells don't accumulate duplicate `PATH` entries.
If you provision `PATH` through a managed profile instead, tell the installer to leave shell profiles alone:
* **macOS** — `curl -fsSL https://app.corridor.dev/cli/install.sh | bash -s -- --no-path-modify`
* **Windows**, or anywhere you prefer an environment variable — set `CORRIDOR_NO_PATH_MODIFY=1`
The binary still installs to `~/.corridor/bin/corridor` (`%USERPROFILE%\.corridor\bin\corridor.exe` on Windows), so make sure your managed profile puts that directory on `PATH`—or invoke the absolute path in scripts and hooks.
### fish users
fish reads none of the POSIX profiles above. For a fish login shell the installer instead writes its `PATH` block to `config.fish`, in native fish syntax, under `$XDG_CONFIG_HOME/fish/` when that variable is set (and absolute) or `~/.config/fish/` otherwise. Two consequences for managed installs:
* **Run the installer with the target user's environment.** fish reads `config.fish` from the user's `XDG_CONFIG_HOME` at login. If you run the installer with a different (or unset) `XDG_CONFIG_HOME` than the user's fish session sees, the block lands where that session never reads it. Run the install step as the target user, or export their absolute `XDG_CONFIG_HOME` for the install. A relative `XDG_CONFIG_HOME` is rejected (the installer cannot predict the directory fish will resolve it against).
* **Mixed-shell machines.** `config.fish` is authoritative for fish. A corrected `PATH` block a previous install wrote to a POSIX profile is left in place, so a user who also runs `sh`/`bash` keeps `corridor` resolving there; only an old Corridor-managed `~/.local/bin` prepend is stripped.
Opting out also leaves any `~/.local/bin` `PATH` prepend an older installer wrote in place. That directory takes priority over system binaries, so if your fleet installed Corridor before this change, strip the `# Added by Corridor CLI installer` block from the shell profile as part of your rollout (the CLI also corrects it on its next run).
## 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). We recommend setting the [execution frequency](https://learn.jamf.com/r/en-US/jamf-pro-documentation-11.21.0/Execution_Frequency_for_Policies) to 'Once every week' so that developers who install or set up an IDE after the initial rollout still get the Corridor extension installed and kept up to date. Choose whichever frequency best fits your organization.
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.
## Fleet (macOS only)
For Fleet, you must deploy a configuration profile that pushes the `User email` and `Device serial` fields to each managed Mac, then run the Corridor script. Fleet can only substitute its per-host variables into configuration profiles, not into scripts, so both are required.
### Prerequisites
* Fleet Premium with MDM enabled on your macOS hosts (the configuration profile requires MDM). Script execution is on by default for MDM-enrolled hosts; otherwise deploy `fleetd` with `--enable-scripts`.
* Each host must have an end user in Fleet, through your IdP integration or a human-to-host mapping. Without one, Fleet cannot resolve the profile's variables and the profile will not deliver.
* A user must be logged in on the Mac when the script runs (a locked screen is fine). At the login window the script skips and retries later, so credentials are not written to the wrong home directory.
### Store your team token as a Fleet custom variable
In Fleet, go to **Controls → Variables** and add a custom variable named `CORRIDOR_TEAM_TOKEN` with your universal team token. Do **not** paste the token into the script. Reference it as `$FLEET_SECRET_CORRIDOR_TEAM_TOKEN` (Fleet adds the `FLEET_SECRET_` prefix and masks the value).
### Creating a configuration profile
Download the Corridor Fleet configuration profile:
```bash theme={null}
curl -fsSL https://raw.githubusercontent.com/CorridorSecurity/CorridorSecurity/refs/heads/main/mdm/fleet-dev.corridor.mdm.mobileconfig -o fleet-dev.corridor.mdm.mobileconfig
```
In Fleet, go to **Controls → OS settings → Configuration profiles** and upload the profile, scoped to the fleet that contains your target hosts. It writes `$FLEET_VAR_HOST_END_USER_IDP_USERNAME` and `$FLEET_VAR_HOST_HARDWARE_SERIAL` to `/Library/Managed Preferences/dev.corridor.mdm.plist`.
On a test Mac:
```bash theme={null}
defaults read "/Library/Managed Preferences/dev.corridor.mdm.plist"
```
You should see `UserEmail` and `SerialNumber`. If the profile fails with a missing IdP username error, set the host's **IdP username** (email) on the host details page. Fleet resends once it resolves.
### Add the Corridor script
Download the Corridor Fleet script:
```bash theme={null}
curl -fsSL https://raw.githubusercontent.com/CorridorSecurity/CorridorSecurity/refs/heads/main/mdm/fleet-macos.sh -o fleet-macos.sh
```
In Fleet, go to **Controls → Scripts** and upload the file. Leave the `$FLEET_SECRET_CORRIDOR_TEAM_TOKEN` reference as-is.
### Run the script
Go to **Hosts**, select a host, then **Actions → Run script**. From the CLI:
```bash theme={null}
fleetctl run-script --script-path=fleet-macos.sh --host=
```
Attach the script to a policy automation so it runs as hosts come into scope.
Once users restart their IDEs, they are automatically signed in to Corridor and the extension is 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.
## Rolling back a deployment
You don't need a custom teardown script — the Corridor CLI ships an uninstaller that reverses everything the rollout does. Rolling back has two independent halves, and you'll usually want both:
1. **Stop provisioning** so no device gets (re)installed.
2. **Remove Corridor** from devices that were already provisioned.
### 1. Stop provisioning
* **Unscope or delete the Corridor install policy** (and, for JAMF, the `dev.corridor.mdm` configuration profile) in your MDM, so devices stop receiving the install.
* **(Optional, org-wide kill switch) Revoke the Universal Team Token.** Go to [app.corridor.dev/teams](https://app.corridor.dev/teams) → **Universal Team Tokens** and revoke the token used in your MDM scripts. Once revoked, any `/mdm-sync-device` call fails, so no new users or device tokens are created. Devices already provisioned keep their per-user token until you run the uninstall below.
### 2. Remove Corridor from a device
Run the uninstaller **as the logged-in user**. It revokes that device's Corridor API token on the server and removes the CLI, agent hooks, MCP config, agent rules, and the `~/.corridor/` directory:
```bash theme={null}
curl -fsSL https://app.corridor.dev/cli/uninstall.sh | bash
```
Or, if the CLI binary is still present, call it directly:
```bash theme={null}
~/.corridor/bin/corridor uninstall --non-interactive
```
The uninstaller removes Corridor's hooks, MCP config, agent rules, and credentials, but leaves the Corridor **IDE extension** itself installed (it's inert once the token is revoked). To also remove the extension binary, uninstall it per IDE — e.g. `code --uninstall-extension corridor.Corridor` and `cursor --uninstall-extension corridor.Corridor`. The JAMF script below does this for you.
Push the uninstall through your MDM the same way you pushed the install.
Prefer running the uninstaller as the logged-in user. Some MDMs (such as Kandji) run custom scripts as root. When `uninstall.sh` runs as root, it resolves the logged-in console user and removes that user's install. Set `CORRIDOR_UNINSTALL_USER=` to name the target user when detection is unavailable. When no user is logged in, it acts on root's own home, so a root-owned install (for example in a container or CI image) is still removed. On macOS, if no console user resolves and root's home holds no install either, it exits non-zero so the MDM retries at the next check-in instead of reporting a false success.
The JAMF script below resolves the console user itself and runs the uninstaller as that user. It exits 0 when no one is logged in, so the policy retries at the next check-in.
#### JAMF (macOS only)
In JAMF, go to **Settings → Scripts** and create a new script (shell/bash) named something like `Corridor Uninstall Script`, with these contents:
```bash theme={null}
#!/bin/bash
# Corridor JAMF uninstaller (macOS) — reverses jamf-macos.sh.
# Scope this to a policy on the devices you want to roll back.
set -u
# Act on the logged-in user's home, not root's.
CONSOLE_USER=$(/usr/bin/stat -f%Su /dev/console)
if [ -z "$CONSOLE_USER" ] || [ "$CONSOLE_USER" = "root" ]; then
echo "No console user logged in; will retry on next check-in."
exit 0
fi
USER_HOME=$(/usr/bin/dscl . -read "/Users/${CONSOLE_USER}" NFSHomeDirectory | sed -n 's/^NFSHomeDirectory: //p')
run_as_user() { /usr/bin/sudo -u "$CONSOLE_USER" /bin/bash -lc "$*"; }
# 1. Revoke the device token + remove the CLI, hooks, MCP config and ~/.corridor/.
CORRIDOR_BIN="${USER_HOME}/.corridor/bin/corridor"
if [ -x "$CORRIDOR_BIN" ]; then
run_as_user "'${CORRIDOR_BIN}' uninstall --target ide-extension --non-interactive" || true
run_as_user "'${CORRIDOR_BIN}' uninstall --non-interactive" || true
else
run_as_user "curl -fsSL https://app.corridor.dev/cli/uninstall.sh | bash" || true
fi
# 2. Remove the Corridor IDE extension itself (VS Code / Cursor, if present).
for IDE in code cursor; do
if run_as_user "command -v ${IDE}" >/dev/null 2>&1; then
run_as_user "${IDE} --uninstall-extension corridor.Corridor" || true
fi
done
echo "Corridor rollback complete for ${CONSOLE_USER}."
exit 0
```
Go to **Computers → Policies → New**. Name it `Corridor Uninstall Policy`, add the `Corridor Uninstall Script` under **Scripts**, set the trigger to **Recurring Check-in** with execution frequency **Once per computer**, and scope it to the devices you're rolling back.
After the uninstall has run, unscope or delete the `Corridor Installation Policy` and the `dev.corridor.mdm` configuration profile so devices are not re-provisioned on their next check-in.
#### Fleet (macOS only)
In Fleet, go to **Controls → Scripts** and upload a rollback script whose contents are:
```bash theme={null}
#!/bin/bash
# Corridor Fleet uninstaller (macOS) — reverses fleet-macos.sh.
set -u
CONSOLE_USER=$(/usr/bin/stat -f%Su /dev/console)
if [ -z "$CONSOLE_USER" ] || [ "$CONSOLE_USER" = "root" ]; then
echo "No console user logged in; will retry on the next run."
exit 0
fi
USER_HOME=$(/usr/bin/dscl . -read "/Users/${CONSOLE_USER}" NFSHomeDirectory | awk '{print $2}')
run_as_user() { /usr/bin/sudo -u "$CONSOLE_USER" /bin/bash -lc "$*"; }
CORRIDOR_BIN="${USER_HOME}/.corridor/bin/corridor"
if [ -x "$CORRIDOR_BIN" ]; then
run_as_user "'${CORRIDOR_BIN}' uninstall --target ide-extension --non-interactive" || true
run_as_user "'${CORRIDOR_BIN}' uninstall --non-interactive" || true
else
run_as_user "curl -fsSL https://app.corridor.dev/cli/uninstall.sh | bash" || true
fi
for IDE in code cursor windsurf; do
if run_as_user "command -v ${IDE}" >/dev/null 2>&1; then
run_as_user "${IDE} --uninstall-extension corridor.Corridor" || true
fi
done
echo "Corridor rollback complete for ${CONSOLE_USER}."
exit 0
```
Run it via **Actions → Run script** or `fleetctl run-script`. Then remove the Corridor script from any policy automation and delete the `dev.corridor.mdm` configuration profile so hosts are not re-provisioned.
#### Kandji / Iru (macOS only)
Add a **Custom Script** (Execution Frequency: **Run once per device**) whose contents are `curl -fsSL https://app.corridor.dev/cli/uninstall.sh | bash`, assign it to the Blueprint you're rolling back, then remove the Corridor Custom Script and the Global Variables profile from that Blueprint.
#### Intune
Add a platform script that runs the uninstaller, then unassign the install script:
* **macOS** — set **Run script as signed-in user: Yes** and use `curl -fsSL https://app.corridor.dev/cli/uninstall.sh | bash`.
* **Windows** — set **Run this script using the logged on credentials: Yes** and run the CLI directly: `& "$env:USERPROFILE\.corridor\bin\corridor.exe" uninstall --non-interactive`.
# 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**. You'll share these securely with the Corridor team in the next step.
Contact the Corridor team to finish enabling SSO and share your credentials over a secure channel.
Never send your **Client Secret** over email, chat, or any other unencrypted channel. Email inboxes are not secure storage, and secrets shared this way can be retained indefinitely and later exposed.
1. Email [support@corridor.dev](mailto:support@corridor.dev) to start the SSO setup. You can include your **Okta domain** (`*.okta.com`), but do **not** include your Client ID or Client Secret in the email.
2. The Corridor team will arrange a secure, encrypted channel (for example, a one-time secret-sharing link) for you to send your **Client ID** and **Client Secret**.
3. Share your **Client ID** and **Client Secret** only through that secure channel to complete the setup.
## 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).
# Artifact Inventory
Source: https://docs.corridor.dev/agent-governance/artifact-inventory
A continuously updated catalog of the MCP servers, Agent skills, hooks, plugins, and editor extensions used across your team's coding agents.
Artifact Inventory shows what is installed across your developers' AI coding agents. Corridor scans each developer's coding-agent configuration and builds a team-wide catalog of MCP servers, agent skills, hook configurations, harness plugins, and editor extensions. The catalog shows who has each artifact, how many devices it appears on, and whether it has security findings (such as plaintext credentials).
Artifact Inventory is part of [Agent Governance](/agent-governance/overview) and is available on the **Enterprise** plan. Corridor collects coding-agent configuration for **Claude Code**, **Cursor**, and **OpenAI Codex**. It collects editor extensions from the VS Code family (VS Code, Cursor, Devin Desktop) and JetBrains IDEs.
## What's in the inventory
Open **Governance → Inventory** in the Corridor dashboard. The **All** view combines every artifact type and includes type filters, text search, and a security-only toggle. Separate views cover **MCP**, **Skills**, **Hooks**, **Plugins**, and **Extensions**.
Each artifact shows its **presence** (the developers and devices that have it), its **enabled or disabled** state on each device, when it was **first and last seen**, and any **security signals**. Expand a row to see installations by device, then select an installation to open its details.
| Artifact type | What you see |
| ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
| **MCP servers** | Transport (stdio/HTTP/SSE), configuration scope (user, project, or plugin), a masked configuration snippet, and the tools exposed by the server |
| **Agent skills** | Version, file count and size, content address, a bill of materials with the hash of every file in the skill bundle, and a bundle download |
| **Hook configurations** | Events, matcher, and a masked configuration snippet |
| **Plugins** | Version, marketplace, scope, author, and bundled MCP servers, hooks, skills, commands, and agents |
| **Editor extensions** | Extension ID, version, publisher, host IDE, and editor compatibility range |
### Security signals
Artifacts can show these security signals:
* **Secret findings**: Corridor scans artifact configuration for embedded credentials, including API keys, tokens, passwords, and credentials in URLs. A finding names the detector and affected field but never includes the secret value.
* **Disabled on devices**: Corridor flags an artifact when it is disabled on some devices but enabled on others.
## What gets scanned
Corridor's hooks scan known user, project, and plugin configuration locations for each supported coding agent:
| | Claude Code | Cursor | Codex |
| ---------------------------------------------- | :---------: | :----: | :---: |
| MCP servers (user, project, and plugin scopes) | ✓ | ✓ | ✓ |
| Agent skills | ✓ | ✓ | — |
| Hook configurations | ✓ | ✓ | ✓ |
| Plugins | ✓ | ✓ | — |
Editor extensions are collected separately from the coding-agent configuration. Corridor collects each extension's enabled or disabled state from the VS Code family (VS Code, VS Code Insiders, Cursor, Devin Desktop) and JetBrains IDEs.
Cursor MCP servers registered at runtime without a configuration file are not visible to the file-based scan. Corridor parses Codex configuration on a best-effort basis.
## How collection works
The Corridor hooks binary, installed with the CLI or IDE extension, runs an inventory scan in the background about every 30 minutes while a coding agent is in use. Each scan:
1. Reads known coding-agent and editor configuration locations on the device.
2. Masks credential-shaped values in MCP, hook, and plugin configuration snippets before upload, so that Corridor never accesses or stores your credentials. Agent skill bundles are uploaded as complete, content-addressed bundles so teams can inspect and download them from the Inventory.
3. Sends the artifact catalog to Corridor, where it is merged into your team's inventory.
The scan runs separately from the agent's workflow. A scan failure does not interrupt the developer or agent.
## Enabling and disabling
Artifact Inventory requires the Enterprise plan. Your team controls collection:
* In **Team Settings → Agent Observability**, the **Artifact Inventory** toggle controls collection for the whole team. Only team **Owners** can change it.
* Turning the toggle off makes the server drop incoming inventory data immediately. Connected clients stop sending it shortly afterward.
* Team **Owners** and **Admins** can view the inventory.
## Next steps
Set allow/block policy for MCP servers and tools
# MCP Tool Controls
Source: https://docs.corridor.dev/agent-governance/mcp-tool-controls
Allow or block MCP servers and individual tools across your team's AI coding agents.
MCP Tool Controls add per-tool policy to Corridor's [MCP Compliance](/features/mcp-compliance). The policy page lists each MCP server observed across your team, with **Inherit / Allow / Block** controls for the server and every tool it exposes.
MCP Tool Controls are part of [Agent Governance](/agent-governance/overview) and are available on the **Enterprise** plan. Enforcement supports **Cursor**, **Claude Code**, **Factory Droid**, **OpenAI Codex**, and **Devin Desktop** through Hooks.
## The policy page
Open **Governance → MCP** in the Corridor dashboard.
The page shows one row for each MCP server found in your team's [Artifact Inventory](/agent-governance/artifact-inventory). Each row shows the server's installations, observed tools, rules, and current policy. Expand the row to see its tools and installations, then select an installation to open its details.
Choose one setting for each server:
| Setting | Behavior |
| ----------- | --------------------------------------------------------------------------------------- |
| **Inherit** | The server follows your team default. Newly discovered servers start with this setting. |
| **Allow** | Tools on the server are allowed unless a tool-level rule blocks them. |
| **Block** | Tools on the server are blocked unless a tool-level rule allows them. |
Each tool has the same **Inherit / Allow / Block** settings. The page shows the tool's effective decision and whether it came from a tool rule, server setting, or team default.
The team-wide default at the top of the page, **Allow all** or **Block all**, applies to every tool without an explicit rule. Before you confirm a change, Corridor shows how many tools will switch.
### How Corridor resolves a decision
The most specific explicit setting wins:
1. **Tool rule**: An explicit Allow or Block on a tool overrides a server-level setting. You can block a server while allowing one approved tool, or allow a server while blocking a specific tool.
2. **Server setting**: If the tool has no rule, the server's Allow or Block setting applies.
3. **Team default**: If the server is set to Inherit, the team-wide default applies.
Corridor's MCP tools are always allowed and appear locked, so your policy cannot block Corridor's security analysis.
A rule for a server also applies when a coding-agent plugin provides that server. You do not need a separate rule for the plugin-provided version.
### Reviewing new servers and tools
Newly discovered servers and tools show a **NEW** badge until someone marks them reviewed. The page also counts items that still need review. Corridor shows how each observed tool was discovered: from the server's published tool list, a session transcript, or a live agent tool call.
### Roles
| Action | Who can do it |
| --------------------------------------------------------------------------- | ------------------------------ |
| Set server and tool policy, change the team default, or mark items reviewed | Team **Owners** |
| View the policy page and inventory | Team **Owners** and **Admins** |
## How enforcement works
When a developer's agent attempts an MCP tool call, Corridor's hook checks the call against your team's policy before it executes. A blocked call never reaches the MCP server. The agent receives a message explaining that your organization's compliance policy blocked the tool and that the developer should contact a team administrator.
Enforcement is **best-effort and fail-open**. If Corridor cannot check the policy, such as when the developer's machine is offline, the call is allowed so development can continue. [Agent Telemetry](/agent-governance/telemetry) records which tools were called, including calls that enforcement could not check.
Some locally launched MCP servers on Cursor and Devin Desktop are identified by their launch command. Configure these servers through the legacy MCP Compliance allow/block lists. The server and per-tool settings on this page do not apply to those calls.
## Next steps
See every MCP server, skill, and plugin across your team
Deny risky shell commands with bans and patterns
# Agent Governance
Source: https://docs.corridor.dev/agent-governance/overview
Enterprise visibility and control for AI coding agents through telemetry, inventory, and on-device policy enforcement.
Agent Governance gives Enterprise security teams visibility into agent activity and installed software, along with control over what agents can do. It covers tools, MCP calls, shell commands, skills, and plugins that would otherwise run mostly outside the security team's view.
## Features
| Capability | Description |
| ------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------- |
| [Agent Telemetry & Timeline](/agent-governance/telemetry) | A searchable stream of agent events, with analytics and per-session views of tool calls, MCP usage, shell commands, skills, and sessions |
| [Artifact Inventory](/agent-governance/artifact-inventory) | A team-wide catalog of installed MCP servers, Agent Skills, hooks, harness plugins, and editor extensions, with secret scanning |
| [MCP Tool Controls](/agent-governance/mcp-tool-controls) | Allow/block policy for MCP servers and their tools |
| [Shell Command Controls](/agent-governance/shell-command-controls) | A deny-list for agent shell commands, including pattern-based rules |
## Observability and control
Telemetry and inventory give security teams a shared view of agent activity and installed software. MCP and shell policies run on the developer's device, inside Corridor's agent hooks, before an action executes.
These controls are designed to stop a cooperating agent from taking an action your team has ruled out. When a control cannot evaluate an action, it fails open so it does not block development.
## Supported agents
Corridor delivers Agent Governance through hooks installed by the [Corridor CLI](/getting-started/quickstart) or IDE extension:
| Capability | Cursor | Claude Code | OpenAI Codex | Factory Droid | Devin Desktop |
| ---------------------- | :----: | :---------: | :----------: | :-----------: | :-----------: |
| Agent Telemetry | ✓ | ✓ | ✓ | ✓ | ✓ |
| Artifact Inventory | ✓ | ✓ | ✓ | — | — |
| MCP Tool Controls | ✓ | ✓ | ✓ | ✓ | ✓ |
| Shell Command Controls | ✓ | ✓ | ✓ | ✓ | ✓ |
✓ means the capability is supported when Agent Governance is enabled for the team.
The Artifact Inventory row covers coding-agent configuration. Editor-extension inventory also covers the VS Code family and JetBrains IDEs, regardless of which coding agent is in use. GitHub Copilot has no hook interface, so these capabilities do not cover it.
Agent Governance is rolling out to Enterprise teams. If you don't see these pages in your dashboard yet, contact [support@corridor.dev](mailto:support@corridor.dev) or your Corridor representative.
## Availability and enablement
* Agent Governance is available on the **Enterprise** plan, including Enterprise trials.
* In **Team Settings → Agent Observability**, the **Agent Telemetry** and **Artifact Inventory** toggles control what Corridor collects from your developers' machines. Turning a stream off makes the server drop incoming data and connected clients stop sending it. Only team **Owners** can change these settings.
* Governance dashboards, including Agent Sessions, are visible to team **Owners** and **Admins**.
* Only team **Owners** can change MCP and shell rules.
## Where to find it
Open **Governance** in the Corridor dashboard:
* **Analytics**: Tool Call Analytics
* **Timeline**: the event stream, session list, and shell usage views
* **Agent Sessions**: the per-conversation session browser
* **Inventory**: the artifact catalog, with an All view and separate MCP, Skills, Hooks, Plugins, and Extensions views
* **MCP**: MCP server and tool policy
* **Shell Controls**: shell command rules
## Next steps
See what your agents are doing
See what's installed across your team
Set allow/block policy by server and tool
# Shell Command Controls
Source: https://docs.corridor.dev/agent-governance/shell-command-controls
Ban shell commands or block risky invocation patterns before an AI coding agent runs them on a developer's machine.
Shell Command Controls let your team deny shell commands run by AI coding agents. You can ban a command or block specific invocations with patterns matched against each parsed command's text. Corridor's agent hooks enforce the rules on the developer's machine before a command runs.
Shell Command Controls are part of [Agent Governance](/agent-governance/overview) and are available on the **Enterprise** plan. Enforcement supports **Cursor**, **Claude Code**, **Factory Droid**, **OpenAI Codex**, and **Devin Desktop** through Hooks.
## How it works
1. **Intercept the command**: Corridor's hook runs when an AI agent attempts a shell command.
2. **Parse the command**: Corridor splits the command line into individual commands, including compound commands (`a && b`), pipelines, subshells, and loops.
3. **Evaluate the rules**: Corridor checks each command against your team's rules. If any command matches, the entire invocation is blocked.
4. **Return the decision**: A blocked command does not run. The agent receives a policy message so it can take another approach.
When Agent Telemetry is enabled, the [Agent Timeline](/agent-governance/telemetry) also records shell commands run by agents.
## Rule types
Rules apply to an executable name, such as `git` or `terraform`. Each command can have one of these rule types:
| Rule type | Behavior |
| ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Ban** | Blocks every invocation of the command and overrides patterns for the same command. You can add a note explaining the ban. |
| **Patterns** | Blocks invocations whose parsed command text matches a regular expression, such as `push\s+--force` for `git`. Other invocations remain allowed. |
Commands without a rule are always allowed; there is no allow-list mode. Patterns use RE2 regular-expression syntax, which does not support lookahead or backreferences. Corridor validates patterns when you save them, so you cannot save a pattern that a device cannot enforce.
For compound commands, such as `rm -rf build && git push --force`, a match on either command blocks the entire invocation. Rules cannot target the Corridor CLI.
## Managing rules
Open **Governance → Shell Controls** in the Corridor dashboard.
The page lists commands observed across your team's agents and commands added manually. Summary cards show the number of controlled commands, active patterns, and observed commands without rules. Expand a command to toggle a ban or create patterns.
Corridor suggests rules based on risky commands observed across your team. Suggestions are advisory and are never applied automatically. Select **Review** to open a suggestion in the rule editor.
### Roles
| Action | Who can do it |
| ----------------------------------------------- | ------------------------------ |
| Create, edit, or delete rules | Team **Owners** |
| View the rules list | Team **Owners** and **Admins** |
| View observed command lines and suggested rules | Team **Owners** |
## Enforcement details
* Rules are enforced **on the developer's device** by the same Corridor hook that powers MCP compliance. No network request is required when a command runs.
* Cursor and Claude Code fetch rules at session start. All supported agents refresh them about every **15 minutes**, so rule changes reach devices within minutes without a reinstall.
* If a device cannot reach Corridor, it continues to enforce its last-synced rules for up to **7 days**. Corridor then discards the stale policy and stops enforcement until the device can sync again, allowing development to continue rather than enforcing stale rules.
When a command is blocked, the agent receives a message like:
```text theme={null}
BLOCKED: This command is not allowed by your organization's shell command
policy. Do not attempt to bypass this by rewording, wrapping, or obfuscating
the command — use a different approach, or ask your team administrator to
update the policy if this is a false positive.
```
## A guardrail, not a sandbox
Shell Command Controls can stop a cooperating agent from running a destructive cleanup, force-push, or risky deployment command, while creating an audit trail. They do not create a security boundary against a compromised agent or motivated user because enforcement runs inside the agent's environment.
* Commands the parser cannot decompose fail **open** and run.
* Heavily wrapped, obfuscated, or dynamically constructed commands may not match a pattern written for the plain command.
* Commands are not evaluated if they run outside the agent's tool-call path or on a machine where Corridor's hooks have been removed.
[Agent Telemetry](/agent-governance/telemetry) provides a server-side record of commands that enforcement could not block.
## Next steps
Allow or block MCP servers and individual tools
See commands in the Agent Timeline
# Agent Telemetry & Timeline
Source: https://docs.corridor.dev/agent-governance/telemetry
Monitor tool calls, MCP usage, shell commands, skills, and sessions across your team's AI coding agents.
Agent Telemetry shows your security team how developers use AI coding agents. Hooks on developers' machines collect tool calls, MCP usage, shell commands, skill invocations, and session lifecycle events for **Tool Call Analytics**, the **Agent Timeline**, and **Agent Sessions**.
Agent Telemetry is part of [Agent Governance](/agent-governance/overview) and is available on the **Enterprise** plan. Corridor collects events from **Cursor**, **Claude Code**, **OpenAI Codex**, **Devin Desktop**, and **Factory Droid** through Hooks. Event coverage varies by agent; Cursor and Claude Code provide the fullest event streams today.
## What's collected
Corridor classifies each agent lifecycle event by type:
| Event type | What it captures |
| ----------- | ------------------------------------------------------ |
| **Session** | Session start, end, and stop events |
| **Prompt** | A prompt submitted to the agent |
| **MCP** | An MCP tool call, with the server and tool name |
| **Shell** | A shell command, split into its commands and arguments |
| **Skill** | An Agent Skill or slash-command invocation |
| **Tool** | A built-in agent tool, such as a file read or edit |
| **Other** | An event that does not fit the other categories |
Dashboards display fields such as tool names, commands, and file paths.
## Tool Call Analytics
**Governance → Analytics** shows aggregate agent tool-call activity across your team, including MCP, shell, skill, and built-in tool activity.
* **Tool calls over time**: a time-series chart with totals, a period from 1 hour to 90 days, an adjustable bucket size, and breakdowns by MCP server, tool, shell command, platform, or event kind
* **MCP Servers**: tool-call totals for each server
* **Top Tools** and **Top Bash Commands**: breakdown tables that identify the agent platform each entry predominantly came from
The data refreshes about once a minute while the page is open.
## Agent Timeline
**Governance → Timeline** shows a searchable, row-level stream of agent events across your team. A volume histogram can group events by platform or event type, and you can drag over it to zoom into a time range.
The page has three tabs:
* **Events** lists individual events. You can filter by text, time period, event type (included or excluded), platform, and shell command. Select a row to see event details, including the parsed shell command and event payload. Recent time windows update every few seconds.
* **Sessions** lists each agent session with its start time, duration, developer, platform, and activity mix across shell, MCP, tool, skill, and prompt events. Select a session to open its trace.
* **Shell Usage** focuses on shell commands and uses advisory risk badges to highlight sensitive or destructive commands. [Shell Command Controls](/agent-governance/shell-command-controls) can block these commands before they run.
## Agent Sessions
**Governance → Agent Sessions** is available to team Owners and Admins. It shows coding-agent conversations across your team, with a searchable session list on the left and the selected session's transcript on the right.
The transcript presents each session as a sequence of prompts and agent actions, including shell commands, MCP or tool calls, and skill invocations.
## How collection works
1. A developer installs the Corridor CLI or IDE extension, which registers Corridor's hooks with the coding agent.
2. The hooks send lifecycle events to Corridor as the agent works.
3. Corridor uses the authenticated token to resolve the user, team, and project on the server. It does not trust identity asserted by the client.
4. The events become available in your team's telemetry and the three dashboard views.
Telemetry covers only machines where Corridor's hooks are installed and enabled. Corridor cannot observe an agent from the server alone.
## Enabling and disabling
Agent Telemetry requires the Enterprise plan. Your team controls collection:
* In **Team Settings → Agent Observability**, the **Agent Telemetry** toggle controls collection for the whole team. Only team **Owners** can change it.
* Turning the toggle off makes the server drop incoming events immediately. Connected clients stop sending events shortly afterward.
* Tool Call Analytics, the Agent Timeline, and Agent Sessions are visible to team **Owners** and **Admins**.
## Next steps
Block shell commands before they run
# 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
# 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 click **Add secret**. Set **Permission** to **Team** — not Environment; environment-scoped secrets are not available to cloud agents. Then add:
* **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 a secret named `CORRIDOR_API_KEY` with **Permission** set to **Team**.
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.
# 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.
We recommend [Corridor Agent](/features/corridor-agent) for new conversations. It answers the same kinds of questions as Chats and can work across one project, several, or all of your projects at once.
Corridor's Chat feature lets you interact with an AI assistant that is contextually aware of your codebase and security issues. 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 reference your actual code: "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 Agent
Source: https://docs.corridor.dev/features/corridor-agent
A security teammate you can talk to. Ask about findings across your projects, get explanations, and have it fix issues and open pull requests.
Corridor Agent is available on **Enterprise** plans.
Corridor Agent is a security teammate you can talk to. Ask it what's broken across your projects, have it explain a finding, or tell it to fix a security issue and watch it open a pull request for you. It is the recommended way to talk to Corridor, in the dashboard and in Slack.
A few things to ask Corridor Agent:
* "What are our open critical and high findings?"
* "Explain this finding and how to fix it."
* "Fix the SQL injection in checkout and open a PR."
* "Check whether that same SQL injection pattern exists in our other services."
* "Give me a report of findings by severity."
## Choosing a scope
When you start a session, pick which projects it covers:
| Scope | How to select it | What the Agent covers |
| ----------------- | ---------------------------------------------- | ------------------------------------------------------------ |
| Single project | Pick one project | That project only |
| Multiple projects | Pick two or more projects | The projects you selected |
| All projects | Pick all projects, or leave the selector empty | Every project your team owns, including projects added later |
A common pattern is to start with all projects to triage, then open a single-project session to remediate.
## What you can do
* **Investigate findings**: Ask about open findings across every project in scope, compare severity across repositories, or check whether a pattern from one service shows up in another.
* **Fix code**: Tell the Agent to fix an issue. It proposes a diff you can review in the session and turn into a pull request.
* **Generate reports**: Ask for a summary of findings by severity, project, or state.
* **Attach files**: Add files to a session to give the Agent extra context.
## How it works
The Agent reads findings for every project in scope through Corridor's built-in tools, so it can answer questions that span repositories. For code-level questions and fixes, it works in a repository from your scope. For projects connected through GitHub, it can also read the source of the other in-scope repositories on demand with read-only access. When it changes code, it produces a diff you can review in the session and turn into a pull request.
On GitHub, the Agent can read source across every repository in scope. On GitLab, it works with findings across your scope but reads code only in the repository it is working in.
## Corridor Agent in Slack
Mention **@Corridor** in a public channel to ask about a finding or dig into an issue. Corridor replies in the thread and keeps its context, so you can ask follow-ups. Sessions started from Slack also appear in the Agent tab. See the [Slack integration](/integrations/slack) page for setup.
## Getting started
1. Open the [Agent tab](https://app.corridor.dev/agent) in the dashboard.
2. Pick your projects: one, several, or all of them.
3. Ask your first question.
If you prefer to work from Slack, mention **@Corridor** in a public channel.
## Next steps
View and manage security findings
Talk to Corridor from your Slack workspace
# 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, plus relevant code snippets from the files you are working with |
| `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
# Merge Policy
Source: https://docs.corridor.dev/features/merge-policy
Set a team-wide security merge policy so Corridor holds any pull request with open findings at your chosen severities until they're resolved or accepted.
Merge Policy lets your security team decide what's safe to ship and have Corridor enforce it automatically. You choose which finding severities should stop a merge as a team-wide standard, and Corridor holds any pull request with open findings at those severities—across every repository—until they're resolved or explicitly accepted. Enforcement lives inside the GitHub workflow your developers already use.
## 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
Your merge policy is enforced by the **Corridor Review** check, which appears as a required status check on the pull request—the same place developers already look before merging:
* **Passing** — no open findings at your policy's severities.
* **Failing** — one or more findings need attention. When the check is required in branch protection, the merge is held until they're resolved or accepted.
You decide what the policy enforces: choose which severities gate a merge (for example, **Critical** and **High**), while lower-severity findings are surfaced for visibility without holding the merge.
## Setting your merge policy
There are two steps: set your policy 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 policy in Corridor
Go to **Governance → Merge Policy** and:
1. Ensure [Pull Request Reviews](/features/pr-reviews) are enabled for your team.
2. Under **Your merge policy**, select the finding severities your team requires resolved before a pull request can merge (for example, **Critical** and **High**). Leaving every severity unselected turns enforcement off.
3. Ensure **Leave Comments on Pull Requests** is on. Corridor posts each finding as an inline comment, and that comment thread is where developers resolve a held pull request (reply `false positive` or `unblock`).
Findings at severities you leave unselected are still surfaced on the pull request for visibility without holding the merge. The policy is a **team-wide** standard—it applies to every project on the team and can't be overridden per project.
### 2. Require the check in GitHub
This is the step that enforces the policy—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 pull request so the check runs, then it'll be selectable.
Without step 2, the Corridor Review check still runs and reports pass/fail on every pull request, but GitHub won't prevent merges—branch protection is what turns the signal into enforcement.
## Resolving a held pull request
Developers can bring a pull request into line with your policy in whatever way fits the situation, all from the pull request:
* **Fix the code** — push a fix and Corridor automatically re-validates 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.
## Reviewing what's held for review
The **Governance → Merge Policy** page gives your security team a single view of every pull request currently held by policy. You can see which projects are accumulating held pull requests, how long each has been waiting, and how many findings are open on it. Filter by severity or project, or open any pull request directly on GitHub.
## Availability
Merge Policy works with GitHub today. GitLab support is on the roadmap.
## Next steps
How Corridor reviews pull requests and how to reply to findings
Track and manage security findings
# 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 |
| **Merge Policy** | Choose the finding severities that hold a merge until they're resolved. Team-wide setting, configured on the **Governance → Merge Policy** page. See [Merge Policy](/features/merge-policy) |
| **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, with 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 Agent](/features/corridor-agent) to investigate and 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** | - | ✓ | ✓ |
| **Corridor Agent** | - | - | ✓ |
| **SSO** | - | - | ✓ |
## 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 checks for updates in interactive terminal sessions. To disable automatic CLI and hook updates, set `CORRIDOR_NO_AUTO_UPDATE=1`. You can still run `corridor update` manually.
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 checks for updates in interactive terminal sessions. To disable automatic CLI and hook updates, set `CORRIDOR_NO_AUTO_UPDATE=1`. You can still run `corridor update` manually.
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 checks for updates in interactive terminal sessions. To disable automatic CLI and hook updates, set `CORRIDOR_NO_AUTO_UPDATE=1`. You can still run `corridor update` manually.
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
* **Merge Policy**: Optionally require Corridor as a status check so merges are held 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.
## Enforcing a merge policy
Corridor can act as a required status check so pull requests with unresolved findings can't be merged. There are two parts: set your merge policy in Corridor by choosing which finding severities hold a merge (**Governance → Merge Policy**), then require the **Corridor Review** check in your GitHub branch protection or rulesets.
| Corridor Review result | Meaning |
| ---------------------- | ----------------------------------------------------------------------------------------------------- |
| **Success** | No open findings at your policy's severities |
| **Failure** | One or more findings need attention—the merge is held when the check is required in branch protection |
See [Merge Policy](/features/merge-policy) for the full setup, including branch protection and rulesets, and how developers resolve a held pull request (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