Understand secret exposure with the HCP Vault Radar MCP server

22min
|
Beta
Vault
Video

Beta feature

The Vault Radar MCP server is a beta feature. Beta functionality is stable but possibly incomplete and subject to change. HashiCorp strongly discourages use of beta features in production environments. The steps in this tutorial prepare you to adopt this integration when it reaches general availability (GA).

The HCP Vault Radar MCP server connects GitHub Copilot to live project data, surfacing secret detection findings directly in popular IDEs such as Visual Studio Code (VS Code) and Cursor. This tutorial covers deploying the server via Docker, connecting it to VS Code, and writing effective prompts to analyze Vault Radar events in real-time.

Challenge

Secrets are often discovered after someone pushes a commit and traditional scanning tools complete a scan. These scanning tools break the feedback loop by forcing developers to context-switch out of their editor to view findings in separate dashboards. The separation delays remediation and allows leaked credentials to persist in repositories.

Solution

The HCP Vault Radar MCP server proxies Vault Radar data into Copilot. By enabling HCP Vault Radar in your IDE, you can query HCP Vault Radar findings without switching context to other tools or dashboard. The HCP Vault Radar MCP server exposes four tools:

query_vault_radar_data_sources: Queries all data sources available in the HCP Vault Radar project.
query_vault_radar_resources: Queries all resources in your HCP Vault Radar project.
query_vault_radar_events: Queries all events in your HCP Vault Radar project.
list_vault_radar_secret_types: Lists all secret types detected by Vault Radar.

As a developer, you can use natural language prompts to query your Vault Radar project for real-time findings without leaving your editor.

Review the security model

The HCP Vault Radar MCP server proxies HCP Vault Radar data into Copilot using an ephemeral Docker container over a local STDIO connection. The architecture enables common security principles to prevent leaked secrets:

Detect leaked secrets: The server provides real-time access to Vault Radar findings, enabling prompt remediation before secrets reach production.
Prevent lateral movement: The server publishes no network ports and the container runtime destroys the container after each session.
Grant least privilege: It authenticates with a viewer role, enforcing a read-only constraint that prevents the AI from altering or suppressing findings.

HCP Vault Radar stores metadata about secret locations — file paths, repository names, line numbers, and commit SHAs — but not the secret values themselves.

Before deploying any AI-connected security tool, understand how it handles credentials and data. The Vault Radar MCP server has three properties that make it safe to use in a developer workflow.

Stateless operation: The container runtime destroys the MCP server after each session (enforced by the --rm flag). No query results, secret metadata, or credentials persist between invocations.
Read-only API access: The server authenticates with the viewer role — the lowest-privilege HCP role. The AI agent can query Vault Radar data but cannot acknowledge, suppress, or modify any findings. For guidance on how to store static secrets used by the service principal, see the Well-Architected Framework.
Local STDIO transport: The server communicates over stdin/stdout, not TCP. No network port is published. Only the local process that spawned the container can communicate with it. This architecture supports a zero trust security posture by eliminating network exposure at the workstation level.

The HCP Vault Radar MCP server cannot expose raw credential values through an AI agent.

Your choice of GitHub Copilot plan affects how GitHub handles HCP Vault Radar metadata.

GitHub Copilot Business and Enterprise plans include a contractual commitment that your code and prompts are not used to train GitHub's AI models.

If you use the individual plan, review GitHub's data use terms before sending HCP Vault Radar findings — which includes repository names, file paths, and event metadata — through Copilot.

Refer to the HashiCorp Well-Architected Framework for broader guidance on how to protect sensitive data in AI-assisted workflows.

Prerequisites

An HCP account
A completed HCP Vault Radar scan of a connected data source that produced events such as the Scan a repository for secrets tutorial
The Vault binary installed
Docker Engine or Docker comparable container runtime installed and running locally.
Visual Studio Code installed
Visual Studio Code configured to launch from the command line
The GitHub Copilot extension installed
An active GitHub Copilot subscription

Data use considerations

GitHub Copilot Business or Enterprise plans include data isolation guarantees; the individual plan does not.

Review GitHub's data use terms before querying security-sensitive HCP Vault Radar data through Copilot on the individual plan.

Set up the lab

To mimic a real-world scenario, you will store the secret values used by the HCP Vault Radar MCP server in HashiCorp Vault. You will then use a launcher script to start VS Code and run the MCP server source from Vault.

Open a terminal and start a Vault dev server with the literal string root as the root token value, and enable TLS.
```
$ vault server -dev -dev-root-token-id root -dev-tls
```
The dev server listens on the loopback interface at 127.0.0.1 on TCP port 8200 with TLS enabled. At runtime, the dev server also automatically unseals, and prints the unseal key and initial root token values to the standard output.
Root tokens
The dev mode server starts with an initial root token value set. Root token use should be extremely guarded in production environments because it provides full access to the Vault server.
You can supply the root token value to start Vault in dev mode for convenience and to keep the steps here focused on the learning goals of this tutorial.
In a new terminal, export the VAULT_CACERT environment variable using the command suggested in your Vault dev server output.
Copy the command (without the $) from the server output, and paste it into the new terminal session.
Important
Remember to use your dev server's values, not the examples shown here.
Example:
```
$ export VAULT_CACERT='/var/folders/qr/zgztx0sj6n1dxy86sl36ntnw0000gn/T/vault-tls3037226588/vault-ca.pem'
```

Export the VAULT_ADDRenvironment variable.

$ export VAULT_ADDR='https://127.0.0.1:8200'

Export an environment variable for the vault CLI to authenticate with the Vault server.
```
$ export VAULT_TOKEN=root
```
This example uses the root token for convenience. In production, follow the principle of least privilege and use an auth method and token with the necessary permissions.
The Vault server is ready.

Create an HCP service principal with viewer access

(Persona: Operations)

The MCP server authenticates to HCP Vault Radar using an HCP service principal.

Create a project-scoped service principal with the Viewer role and generate a service principal key. The viewer role allows you to follow the principle of least privilege.

Plan to rotate the service principal key periodically to manage the key's full lifecycle by revoking keys older than your rotation period and generating new keys.

Create the service principal

Sign in to the HCP portal.
Select your organization and project.
In the left sidebar, click Access control (IAM).
Click Service principals.
Click Create service principal.
Enter vault-radar-mcp in the Service principal name field.
Click the Select role dropdown and select Viewer.
Click Create service principal.

Generate a service principal key

On the service principal detail page, click Keys
Click Generate key.
Copy the Client ID.
Open a terminal and export the client ID as an environment variable.
```
$ export HCP_CLIENT_ID=
```
Return to the HCP portal, copy the Client secret.
Return to the same terminal you exported the HCP_CLIENT_ID and export the secret as an environment variable.
```
$ export HCP_CLIENT_SECRET=
```
Click Back to service principals.
Click Back to dashboard.
Click View project settings.
Copy the Project ID.
Return to the same terminal you exported the HCP_CLIENT_ID and HCP_CLIENT_SECRET and export the project ID as an environment variable.
```
$ export HCP_PROJECT_ID=
```

Store the service principal credentials in Vault

In the terminal where you set the VAULT_ADDR environment variable, write the service principal credentials in Vault at the path secret/data/vault-radar-mcp.

$ vault kv put secret/vault-radar-mcp \
    hcp_project_id="$HCP_PROJECT_ID" \
    hcp_client_id="$HCP_CLIENT_ID" \
    hcp_client_secret="$HCP_CLIENT_SECRET"

Example output:

======= Secret Path =======
secret/data/vault-radar-mcp

======= Metadata =======
Key                Value
---                -----
created_time       2026-03-18T19:01:35.917Z
custom_metadata    <nil>
deletion_time      n/a
destroyed          false
version            1

Verify you can read the credentials back from Vault.

$ vault kv get secret/vault-radar-mcp

======= Secret Path =======
secret/data/vault-radar-mcp

======= Metadata =======
Key                Value
---                -----
created_time       2026-03-18T19:01:35.917Z
custom_metadata    <nil>
deletion_time      n/a
destroyed          false
version            1

======== Data ========
Key              Value
---              -----
client_id        s3asm3st978badb00d0961f3f07ee64
client_secret    b1llt3dexc31l3nt581321d92aa3975088544ccd79e558d70af3ec07dd1472b6
project_id       c00k13-m0ns-t3rf-99a9-7a2ce0f98156

Connect the MCP server to VS Code

(Persona: Developer)

Configure VS Code to connect to the HCP Vault Radar MCP server as a GitHub Copilot agent tool. You can scope the configuration to a single workspace or to all workspaces on your machine. Workspace configuration is easier to share with teammates but requires care to avoid committing credentials.

In this tutorial, you will scope the HCP Vault Radar MCP server to your current workspace.

In the root of your local workspace, create a .vscode directory if one does not already exist.

Create a file named mcp.json in the .vscode directory with the following content.

{
  "servers": {
    "vault-radar": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "-i",
        "-e", "HCP_PROJECT_ID=${env:HCP_PROJECT_ID}",
        "-e", "HCP_CLIENT_ID=${env:HCP_CLIENT_ID}",
        "-e", "HCP_CLIENT_SECRET=${env:HCP_CLIENT_SECRET}",
        "hashicorp/vault-radar-mcp-server:latest"
      ]
    }
  }
}

Add .vscode/mcp.json to your .gitignore file so you do not commit it to version control.
```
$ echo ".vscode/mcp.json" >> .gitignore
```
Warning
Even with ${env:...} variable references, the mcp.json file may be modified by VS Code to include resolved values. Add it to .gitignore as a precaution. For more on credential anti-patterns in CI/CD, see CI/CD secrets anti-patterns.
After saving the configuration, verify that VS Code recognizes the MCP server and that all four Vault Radar tools are available to the agent.
Open the VS Code Chat panel from the Activity Bar or with Cmd+Shift+I (macOS) / Ctrl+Shift+I (Windows/Linux).
In the chat mode selector at the bottom of the Chat panel, select Agent.
Select the tools icon (the wrench icon) to open the tools list.
Verify that the following four HCP Vault Radar tools appear:
If the tools do not appear, verify that Docker is running and that your environment variables are set, then reload the VS Code window with Cmd+Shift+P > Developer: Reload Window.

Create a launcher script for VS Code and the MCP server

(Persona: Developer)

To simplify starting VS Code with the MCP server running in the terminal, create a launcher script. The launcher script connects to Vault to retrieve the service principal credentials, exports them as environment variables, and starts the MCP server in a Docker container. This pattern keeps credentials out of the script and allows you to start the server and VS Code with a single command.

VS Code added to $PATH

To complete this section, ensure you can launch VS Code from the command line with the code command. Refer to the VS Code documentation for instructions on how to add VS Code to your system PATH if you have not done so already.

In the root of your local workspace, create a file named launch-vs-code.sh.

Copy the script into launch-vs-code.sh.

#!/usr/bin/env bash
set -euo pipefail

SCRIPT_NAME="$(basename "$0")"

VAULT_BIN="vault"
CODE_BIN="code"
SECRET_PATH=""
WORKSPACE_PATH=""
PROJECT_ID_KEY="hcp_project_id"
CLIENT_ID_KEY="hcp_client_id"
CLIENT_SECRET_KEY="hcp_client_secret"

CODE_ARGS=()

print_usage() {
  cat <<EOF
Usage:
  $SCRIPT_NAME --secret-path <kv-v2-path> [options] [-- <code-args...>]

Required:
  --secret-path PATH         Vault KV v2 secret path (example: secret/platform/vscode/hcp-radar)

Options:
  --workspace PATH           Workspace/folder to open in VS Code (default: current directory)
  --project-id-key KEY       Vault field name for project ID (default: hcp_project_id)
  --client-id-key KEY        Vault field name for client ID (default: hcp_client_id)
  --client-secret-key KEY    Vault field name for client secret (default: hcp_client_secret)
  --vault-bin PATH           Vault CLI binary to use (default: vault)
  --code-bin PATH            VS Code CLI binary to use (default: code)
  -h, --help                 Show this help

Notes:
  - The script expects Vault auth to already be configured (for example via VAULT_TOKEN or vault login).
  - To ensure variables are injected into the VS Code app process, fully quit VS Code before running this script.
  - Exported env vars for VS Code are: HCP_PROJECT_ID, HCP_CLIENT_ID, HCP_CLIENT_SECRET.
EOF
}

fail() {
  echo "Error: $*" >&2
  exit 1
}

require_command() {
  local cmd="$1"
  command -v "$cmd" >/dev/null 2>&1 || fail "Missing required command: $cmd"
}

read_vault_field() {
  local key="$1"
  local value
  if ! value="$($VAULT_BIN kv get -field="$key" "$SECRET_PATH" 2>/dev/null)"; then
    fail "Could not read field '$key' from Vault path '$SECRET_PATH'."
  fi

  if [[ -z "$value" ]]; then
    fail "Field '$key' from Vault path '$SECRET_PATH' is empty."
  fi

  printf '%s' "$value"
}

while [[ $# -gt 0 ]]; do
  case "$1" in
    --secret-path)
      [[ $# -ge 2 ]] || fail "--secret-path requires a value"
      SECRET_PATH="$2"
      shift 2
      ;;
    --workspace)
      [[ $# -ge 2 ]] || fail "--workspace requires a value"
      WORKSPACE_PATH="$2"
      shift 2
      ;;
    --project-id-key)
      [[ $# -ge 2 ]] || fail "--project-id-key requires a value"
      PROJECT_ID_KEY="$2"
      shift 2
      ;;
    --client-id-key)
      [[ $# -ge 2 ]] || fail "--client-id-key requires a value"
      CLIENT_ID_KEY="$2"
      shift 2
      ;;
    --client-secret-key)
      [[ $# -ge 2 ]] || fail "--client-secret-key requires a value"
      CLIENT_SECRET_KEY="$2"
      shift 2
      ;;
    --vault-bin)
      [[ $# -ge 2 ]] || fail "--vault-bin requires a value"
      VAULT_BIN="$2"
      shift 2
      ;;
    --code-bin)
      [[ $# -ge 2 ]] || fail "--code-bin requires a value"
      CODE_BIN="$2"
      shift 2
      ;;
    -h|--help)
      print_usage
      exit 0
      ;;
    --)
      shift
      CODE_ARGS+=("$@")
      break
      ;;
    *)
      fail "Unknown argument: $1"
      ;;
  esac
done

[[ -n "$SECRET_PATH" ]] || fail "--secret-path is required"

require_command "$VAULT_BIN"
require_command "$CODE_BIN"

if ! "$VAULT_BIN" token lookup >/dev/null 2>&1; then
  fail "Vault authentication is not ready. Run 'vault login' or set VAULT_TOKEN."
fi

if pgrep -x "Code" >/dev/null 2>&1; then
  fail "VS Code appears to be running. Fully quit VS Code and run this script again so env vars are injected into the app process."
fi

PROJECT_ID="$(read_vault_field "$PROJECT_ID_KEY")"
CLIENT_ID="$(read_vault_field "$CLIENT_ID_KEY")"
CLIENT_SECRET="$(read_vault_field "$CLIENT_SECRET_KEY")"

if [[ -z "$WORKSPACE_PATH" ]]; then
  WORKSPACE_PATH="$PWD"
fi

if [[ ${#CODE_ARGS[@]} -eq 0 ]]; then
  CODE_ARGS=("$WORKSPACE_PATH")
fi

exec env \
  HCP_PROJECT_ID="$PROJECT_ID" \
  HCP_CLIENT_ID="$CLIENT_ID" \
  HCP_CLIENT_SECRET="$CLIENT_SECRET" \
  "$CODE_BIN" "${CODE_ARGS[@]}"
EOF

Save the file and quit VS Code.
Make the script executable.
```
$ chmod +x launch-vs-code.sh
```

Run the script, passing the Vault secret path as an argument.

$ ./launch-vs-code.sh --secret-path secret/vault-radar-mcp

If prompted, trust the VS Code workspace.
The script reads the service principal credentials from Vault, exports them as environment variables, and starts VS Code. The MCP server is now available in the VS Code Chat panel in Agent mode.

Query Vault Radar data with GitHub Copilot

(Persona: Operations)

With VS Code setup to start the MCP server, use GitHub Copilot in Agent mode to query live data from your Vault Radar project.

The AI agent selects which MCP tool to call based on the keywords in your prompt. Use terms like "data sources," "resources," "events," and "secret types" to ensure the agent routes through the MCP server rather than answering from general training data.

Example output

Because AI agents generate responses dynamically, your output may differ from the examples shown here. The example outputs illustrate the type of information you can expect to receive from the agent. Your actual results may vary based on the current state of your HCP Vault Radar project and your choice of model.

Check your connected data sources

In the VS Code Chat panel, select Agent mode.

Query the MCP server for available data sources.

What data sources are available in my HCP Vault Radar project?

Note

If prompted, allow VS Code to run the MCP server and perform queries.

The agent calls query_vault_radar_data_sources and returns a list of the repositories, file systems, or cloud storage buckets connected to your Vault Radar instance.

Example output:

I’ll query your Vault Radar project directly for configured data sources and summarize what’s currently available.

Your HCP Vault Radar project currently shows 1 configured data source:

Name: radar-example
Type: github_cloud
Detector type: agent
Monitored: true
Setup complete: true

Query the MCP server again to determine the number of scanned data sources.

How many resources have been scanned in each of those data sources?

The agent calls query_vault_radar_resources and returns resource counts per data source.

Example output:

I’ll query Vault Radar resources grouped by data source so we can return the scanned resource count for each connected source.

Resource counts by data source in your Vault Radar project:

radar-example (github_cloud): 1 resource scanned
Total scanned resources across data sources: 1

Triage open events by severity

Enter the following prompt to retrieve high-priority findings:

Show me all unresolved critical and high severity events in my Vault Radar project. Group them by data source and tell me which ones have been open the longest.

The agent calls query_vault_radar_events and returns a prioritized list of findings. Use this prompt during incident triage or as part of a pre-release checklist.

Example output:

I’m running an aggregated event query by data-source fields to ensure the grouping is explicit and consistent with Vault Radar’s event metadata.

Unresolved critical/high findings are all in one data source group:

Data source: github_cloud
State breakdown: 5 TRIAGED, 2 ACTIVE
Severity breakdown: 7 HIGH, 0 CRITICAL
Scanner source: AGENT_SCAN
Open the longest in this group (by Vault Radar detection time):

Alert 76c21547-db6d-4bb6-adf6-0954926ccc6f
Time detected: 2025-03-25T17:06:30.892354Z
Severity/state: high, TRIAGED
Resource: git://github.com/radar-example/hcp-vault-radar-foundations.git (main.go)

Alert fc550cc6-2be4-4107-916a-68a70bd8236a
Time detected: 2025-03-25T17:06:30.975216Z
Severity/state: high, ACTIVE
Resource: git://github.com/radar-example/hcp-vault-radar-foundations.git (main.go)

To focus on a specific secret type, add context to the prompt:

Which types of secrets have been detected in my environment? For each type, tell me how many active events exist. Tell me specifically if any AWS access keys or GitHub tokens are still unresolved.

The agent calls list_vault_radar_secret_types followed by query_vault_radar_events and returns a summary by secret type.

Example output:

I found the active-by-type counts; next I’m running focused unresolved checks for GitHub token findings and AWS access key findings.

Detected secret types in your environment and current ACTIVE event counts:

Password assignment: 86 active
Secret assignment: 32 active
Private key: 4 active
Slack webhook: 3 active
Hashed password: 2 active
Password in function: 0 active
Secret in URL params: 0 active
GitHub token, GitHub personal access token, or OAuth client secret: 0 active

Specific unresolved check (ACTIVE or TRIAGED):

AWS access keys: none unresolved
GitHub tokens: none unresolved

Assess risk before merging

You can use the HCP Vault Radar MCP to query data before merging a pull request.

Enter a prompt that cross-references the affected repository against Vault Radar findings.

I am about to merge changes to the radar-example repository. Are there any data sources or resources in Vault Radar associated with that repository? If so, what is the current risk posture?

The agent calls query_vault_radar_data_sources and query_vault_radar_resources, then summarizes any open findings for that repository.

Example output:

Yes. Vault Radar has an associated resource for radar-example:

Associated resource
Repository: git://github.com/radar-example/hcp-vault-radar-foundations.git
Data source type: github_cloud
Data source name on the resource: radar-example
Detector/source: AGENT_SCAN
Current risk posture (open findings)
High severity: 7 open total
Medium severity: 5 open total
Critical severity: 0 open total
State split for high severity: 5 TRIAGED, 2 ACTIVE
Oldest unresolved high findings
76c21547-db6d-4bb6-adf6-0954926ccc6f, TRIAGED, detected 2025-03-25T17:06:30.892354Z
fc550cc6-2be4-4107-916a-68a70bd8236a, ACTIVE, detected 2025-03-25T17:06:30.975216Z
807d749e-6ff3-45c2-bd0c-f8f854979020, TRIAGED, detected 2025-03-25T17:06:31.053879Z
Merge-readiness interpretation
This is elevated risk for merge because unresolved high-severity secrets are present.
At minimum, review and resolve the 2 ACTIVE high findings before merge; then confirm whether TRIAGED highs are accepted risk or require remediation.

Interactive pre-merge check

(Persona: Operations)

Before pushing a branch, use the HCP Vault Radar MCP server to ask Copilot to generate a risk summary for the files you changed. This pattern gives you a last-chance review of open secret findings in the affected repository before you open a pull request.

Clone the hcp-vault-radar-example repository.

$ git clone https://github.com/hashicorp-education/hcp-vault-radar-foundations.git

Change into the repository directory.
```
$ cd hcp-vault-radar-foundations
```
Make a change to the main.go file so git registers it as modified.

Verify the change with git status.

$ git status
On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   main.go

no changes added to commit (use "git add" and/or "git commit -a")

Stage your changes but do not push them.
```
$ git add main.go
```

Enter a prompt that asks for a risk summary based on the files you changed.

Generate a HCP Vault Radar risk summary for the radar-example repository compared to the files staged for commit in the local hcp-vault-radar-foundations directory. List all open events by severity, identify which secret types are present, and recommend which events to address before this changes in hcp-vault-radar-foundations is merged.

Click Allow for any prompts from the agent.

The agent calls query_vault_radar_events, query_vault_radar_resources, and list_vault_radar_secret_types to produce a prioritized remediation list in context.

Example output:

I’ll first inspect the local hcp-vault-radar-foundations git index to see exactly which files are staged, then I’ll map those paths against open Vault Radar events for radar-example.

I’ve confirmed main.go is staged; now I’m pulling unresolved events and severity/type aggregates to produce a staged-file-aware merge recommendation.

I have the aggregate counts; I’m now reading the detailed page-1 event payload to extract the exact high-priority alerts affecting the staged file.

I’m doing one final local check of the staged diff in main.go so the recommendation can distinguish file-level overlap from exact line-level overlap.

Risk summary for radar-example, compared to staged files in local hcp-vault-radar-foundations:

Staged-file comparison
Staged files: main.go
Current staged diff only adds a comment near the auth section and does not modify the known password assignment location at main.go:12.
Vault Radar open events for this repository all point to repo path main.go, so your staged file is directly in scope of existing findings.
Open events by severity
High: 7 open
Medium: 5 open
Critical: 0 open
Total open: 12
Open events by state
ACTIVE: 7 (2 high, 5 medium)
TRIAGED: 5 (all high)
Secret types present in open events
Password assignment: 12 open
No additional secret type appears in the current open set for this repository scope.
Highest-priority events to address before merge
Address first (ACTIVE high):
fe16dfcd-1c24-4558-9b1b-ffd134f27f64
fc550cc6-2be4-4107-916a-68a70bd8236a
Then review TRIAGED high (including oldest and branch-tip signal):
4ac7e25d-7662-4ce1-89c1-22a1d7c45da6
e0d2bfee-a9d2-4612-969f-cee22b849026
0b82a38c-9663-40e5-8e45-dccf2f8fc91c
807d749e-6ff3-45c2-bd0c-f8f854979020
76c21547-db6d-4bb6-adf6-0954926ccc6f
Then clean up ACTIVE medium:
41b0f46a-ff03-4f9b-943a-b46bd6a6d177
96210a97-6ef4-4ff9-8c2e-aff81041b9d3
16beea96-2ad2-46e5-878f-933bcda3a08a
10fd08d8-15c6-4814-a190-f2d0759a131b
aecccaf2-76a3-444d-a930-5187d1f87318
Merge posture:

Elevated risk. Even though your staged hunk does not edit the secret line directly, 
the branch still contains unresolved high-severity secret findings in the staged file path.

You can use the HCP Vault Radar MCP server to verify staged commits do not contain secrets before pushing, or to triage any findings that do appear in the staged diff.

Knowledge checks

A quiz to test your knowledge.

How does the HCP Vault Radar MCP server securely communicate with your local IDE?
🔘 Over a published TCP port
🔘 Through a cloud-hosted REST API
🔘 Using an SSH tunnel
🔘 Over a local STDIO connection
❌ Over a published TCP port
❌ Through a cloud-hosted REST API
❌ Using an SSH tunnel
✅ Over a local STDIO connection
The server communicates over stdin/stdout rather than a network port, ensuring only the local process that spawned the container can communicate with it.
Why does the Vault Radar MCP server require the viewer role for its HCP service principal?
🔘 To grant developers admin access to the HCP Portal.
🔘 To prevent the AI agent from altering or suppressing security findings.
🔘 To allow the server to create new Vault Radar projects.
🔘 To automatically remediate leaked secrets in the codebase.
❌ To grant developers admin access to the HCP Portal.
✅ To prevent the AI agent from altering or suppressing security findings.
❌ To allow the server to create new Vault Radar projects.
❌ To automatically remediate leaked secrets in the codebase.
The viewer role enforces a read-only API constraint, allowing the AI agent to query Vault Radar data but preventing it from modifying or hiding any findings.
What happens to the Vault Radar MCP server and its data after a session completes?
The server operates statelessly as an ephemeral Docker container. The container runtime destroys the server after each session, ensuring that no query results, secret metadata, or credentials persist between invocations.

Summary

In this tutorial, you configured your IDE to start the HCP Vault Radar MCP server as a short-lived Docker container, and queried live findings using natural-language prompts to establish patterns for surfacing HCP Vault Radar context in interactive developer workflows.

Moving secret detection into the editor reduces remediation lag by eliminating the context switch between development and security toolchains. This helps you prevent leaked credentials from reaching production by putting findings in front of developers at the moment they are most able to act on them.

Additional resources

Vault Radar MCP server changelog — monitor for GA release and review breaking changes before upgrading
Vault Radar MCP server security considerations — detailed security model for the MCP server
Prompt model reference — full list of supported prompt patterns and tool routing heuristics
HCP Vault Radar overview — configure additional data sources and scan schedules
Detect leaked secrets — Well-Architected Framework guidance on detection strategies
Remediate leaked secrets — Well-Architected Framework guidance on remediation workflows
VS Code MCP server documentation — VS Code-specific MCP configuration reference

Collection Overview

HCP Vault Radar Developer

Scan for secrets in CI/CD pipelines