
Attack scenario 1: Malicious code and credential theft via supply chain
Attack scenario 2: Over-privileged credentials enable lateral movement
Attack scenario 3: Prompt injection triggers unauthorized database operations
Attack scenario 4: Exposed Remote MCP Servers with no authentication
Attack scenario 5: Credential leakage through logs and crash dumps
Detecting MCP security incidents
The following table maps each signal category to what you should monitor and the detection rule most likely to surface a real incident.
| Signal category | What to monitor | Example detection rule |
|---|---|---|
Credential access | Secrets manager audit logs | Alert if the credential is accessed outside business hours or by an unknown service identity. |
API usage | Backend service API logs (GitHub, AWS, DB) | Alert if MCP-associated token makes >500 API calls in one hour or accesses a new resource category. |
Network behavior | MCP server egress traffic | Alert if MCP server connects to a domain not in the approved allowlist. |
Process behavior | MCP server system calls, child processes | Alert if MCP server spawns unexpected child processes or writes to unexpected file paths. |
User activity | MCP client connection logs | Alert if MCP tool invocations do not correlate with active user sessions. |
The most effective detection rule combines multiple signals. For example: "Alert if the MCP server accesses the GitHub token from the secrets manager AND makes more than 1,000 GitHub API calls within one hour, AND the associated user account belongs to an offboarded employee." This type of compound rule reduces false positives while catching attacks that exploit legitimate credentials.
Knowing when something went wrong is only half the picture. The mitigation matrix below shows which risks you should prioritize.
| Risk category | Highest-impact mitigation | Second priority | Third priority |
|---|---|---|---|
Supply chain | Vendor from trusted sources, code review | Network egress filtering | Process sandboxing |
Over-privileged credentials | Fine-grained, least-privilege tokens | Separate read/write credentials | Runtime credential fetching |
Prompt injection | Read-only credentials, command allowlisting | Human confirmation for destructive ops | Input sanitization |
Network exposure | Private subnet deployment, require auth | Continuous exposure monitoring | Mutual TLS |
Log/crash leakage | Automatic secret redaction | Restrict log access | Runtime credential fetching |
Layered defense starts with knowing where you're most exposed. Map which backend services each MCP server connects to, what permissions each credential grants, and who has access. That exercise alone tends to surface the highest-risk gaps before any attacker does.
These five scenarios, from supply chain credential theft and lateral movement through over-privileged tokens to prompt injection, unauthenticated server exposure, and credential leakage through logs, all stem from common configuration patterns seen across real MCP deployments. Defending against them requires a layered approach.
If you are deploying MCP servers in your organization, start with a threat modeling exercise. Map which backend services each server connects to, what permissions each credential grants, how those credentials are stored and rotated, and who has access to them. That mapping will reveal your highest-risk exposure points and show you where to invest first.
Trusted by the world’s best DevOps and security teams. Doppler is the secrets manager developers love.
