// Scan files, content, or recent changes for secrets such as API keys, passwords, tokens, and credentials using the GitHub MCP Server's run_secret_scanning tool.
| name | secret-scanning |
| description | Scan files, content, or recent changes for secrets such as API keys, passwords, tokens, and credentials using the GitHub MCP Server's run_secret_scanning tool. |
| allowed-tools | Bash(git:*) Glob Grep Read |
This skill uses the GitHub MCP Server's run_secret_scanning tool to detect secrets in content, files, or git changes. It helps identify sensitive material like API keys, passwords, and credentials that could pose a security risk if exposed.
In this context, values that grant access, impersonate a user or service, sign requests, or decrypt protected data are generally treated as secrets.
Treat these as high-confidence secret material:
Prefer context, not just regex:
password, token, secret, client_secret, private_key, or authorization are higher riskNot everything that looks random is a secret. Example placeholders such as YOUR_API_KEY_HERE, obvious test stubs, and documented sample values can be false positives.
This skill scans for secrets that could compromise security if leaked. A committed secret can persist in git history, trigger incident response, and block deployment at push protection checks.
Important: Only use this skill when a user explicitly asks to scan content or check for secrets. Do not run secret scanning unprompted or as part of general workflows.
| User goal | How to respond | Tools needed |
|---|---|---|
| Check a config snippet or code paste | Scan as content | MCP |
| Check a specific file in the repo | Read file, then scan | Read + MCP |
| Check all staged changes before commit | Get diff, then scan | Bash(git:*) + MCP |
GitHub MCP Server: The skill requires the GitHub MCP Server with the secret_protection toolset enabled. This repository includes a default .mcp.json configured for the GitHub MCP Server, allowing the skill to communicate with it out of the box.
Configure in your MCP settings:
{
"mcpServers": {
"github": {
"type": "http",
"url": "https://api.githubcopilot.com/mcp/"
}
}
}
Note: Cursor uses
serversinstead ofmcpServersas the top-level key.
Required information for scanning:
git remote get-url origin or ask the usergit remote get-url origin or ask the userRead tool), or git diff output (from git diff)If the user doesn't provide repository owner and repository name, ask for them before running the scan.
What NOT to scan: By default, avoid scanning large generated or vendor content (for example: node_modules/, build artifacts, compiled assets, or other machine-generated files) for performance and noise reduction. Files listed in .gitignore may still contain secrets (such as .env or local config), so only skip them if the user agrees; if the user explicitly asks to scan them, include them in the scan.
When to use: The user provides text or code snippets they want checked for secrets.
How: Use the run_secret_scanning tool with the content as input (as a single-item array).
Example
You: Check if this config snippet has secrets
User provides:
DB_PASSWORD=MyP@ssw0rd123
API_KEY=abc123xyz
Agent: I'll scan that for secrets.
⚠️ Found 2 potential secret(s):
1. DB_PASSWORD value looks like a password
2. API_KEY value looks like an API key
Consider replacing hardcoded values with environment variables.
When to use: The user asks to check specific files in the repository for secrets.
How: Use the Read tool to get file contents, then pass them to run_secret_scanning.
Example (secrets found)
You: Check if config.py has secrets
Agent: I'll read and scan that file.
⚠️ Found 1 potential secret:
- Line 10: database_password value looks like a password
Suggestion: Move to environment variable or .env file.
Example (no secrets found)
You: Check if utils.js has any secrets
Agent: I'll read and scan that file.
✅ No secrets detected in utils.js
When to use: The user wants to check git staged changes for secrets before committing.
How: Use git diff --cached to get staged content, then pass it to run_secret_scanning.
Example (clean)
You: Check my staged changes for secrets before I commit
Agent: I'll scan your staged changes.
✅ No secrets found in staged changes. Safe to commit.
Example (secrets detected)
You: Scan my staged changes
Agent: I'll check your staged changes.
⚠️ Found 1 potential secret in staged changes:
- database.js line 5: password value looks like a credential
Suggestion: Unstage that change, move the credential to env vars, and restage.
When you call run_secret_scanning:
The tool works on content you provide. It doesn't need push access or special GitHub permissions.
When you request a scan, file contents are sent to GitHub's secret detection infrastructure. The scanning happens server-side against GitHub's known secret patterns. Scan results are returned without retaining the content on GitHub servers beyond the scan request.
If secrets are found:
.env filesexample.env or documentation exists that shows the expected structureIf no secrets are found:
For more details on secret scanning, credential management, and GitHub security features:
Scan repository dependencies for known vulnerabilities using the GitHub MCP Server's Dependabot toolset and the GitHub Advisory Database. Use when asked to check dependency security, audit lockfiles, or verify packages before merging.
Comprehensive guidance for building web apps with opinionated defaults for tech stack, design system, and code standards. Use when user wants to create a new web application, dashboard, or interactive interface. Provides tech choices, styling guidance, project structure, and design philosophy to get users up and running quickly with a fully functional, beautiful web app.
Query Microsoft 365 Copilot for workplace intelligence - emails, meetings, documents, Teams messages, and people information. USE THIS SKILL for ANY workplace-related question where the answer likely exists in Microsoft 365 data. This includes questions about what someone said, shared, or communicated; meetings, emails, messages, or documents; priorities, decisions, or context from colleagues; organizational knowledge; project status; team activities; or any information that would be in Outlook, Teams, SharePoint, OneDrive, or Calendar. When in doubt about workplace context, try WorkIQ first. Trigger phrases include "what did [person] say", "what are [person]'s priorities", "top of mind from [person]", "what was discussed", "find emails about", "what meetings", "what documents", "who is working on", "what's the status of", "any updates on", etc.