Skip to main content

Address the OWASP MCP Top 10

Work through the ten risks in the OWASP MCP Top 10 and configure the MintMCP controls that cover each one. Every risk on the list has at least one control in the product, and most have several, so this page pairs each risk with what to turn on and where.

Use it as a rollout guide or as evidence for a security review. Each section states the risk in a sentence, lists the controls that apply, and links to the page with the configuration steps. The checklist at the end collapses all ten into the settings worth confirming before you scale a deployment.

Risk to control map​

OWASP riskMintMCP controls
MCP01 Token mismanagement and secret exposureGateway-held credentials, secret providers, per-user OAuth, bearer key expiry, M2M tokens, secret-detection rules
MCP02 Privilege escalation via scope creepOne Virtual MCP per role with directory-group access policies, tool curation, custom org roles, agent identities
MCP03 Tool poisoningTool change notifications, manual-approval update policy, description overrides, injection-screening middleware
MCP04 Supply chain and dependency tamperingHosted connectors on pinned image digests, curated MCP store, manifest change history, force-disable new tools
MCP05 Command injection and executionTool-argument rules, middleware with fail-closed behavior, tool curation, kill switch
MCP06 Intent flow subversionPrompt-injection rules, tool call approval at the gateway, the ask-user action for supported clients, post-phase middleware, Live Activity
MCP07 Insufficient authentication and authorizationOAuth on every Virtual MCP, SSO and SCIM, access policies, agent credentials, client IP allowlist
MCP08 Lack of audit and telemetryGateway request logs, Agent Monitor, signed access-grant history, SIEM export
MCP09 Shadow MCP serversThe gateway as the single entrypoint, tool inventory across every client, allowlist policy layered on top, MDM-deployed monitoring
MCP10 Context injection and over-sharingPer-role tool curation, per-user credentials, identity forwarding, DLP masking middleware

MCP01: Token mismanagement and secret exposure​

The risk: hard-coded credentials and long-lived tokens sit where an agent can read them, so a prompt injection or a debug trace turns into credential theft.

MintMCP moves the credential off the machine running the agent. The gateway holds it and injects it into each upstream call as a header or environment variable, which means the AI client authenticates to MintMCP and never sees the downstream token at all.

What to configure:

  • Keep shared tokens in your own secret store. A secret provider points MintMCP at AWS Secrets Manager (or GCP Secret Manager and Azure Key Vault, available by request) and resolves the value per request, so MintMCP stores the reference rather than the secret. Rotations in your store take effect within about five minutes with no MintMCP change, and every read lands in your own cloud audit trail.
  • Prefer per-user OAuth where the downstream supports it. MintMCP stores each user's access and refresh tokens encrypted and refreshes them automatically, so no one holds a static key. See authentication models.
  • Put an expiry on every agent credential. Bearer keys take an optional name and expiry and revoke individually, and M2M tokens go further: the client secret only appears during the token exchange and each request carries a short-lived access token instead.
  • Catch secrets in the traffic itself. The built-in secret rules match API keys, access tokens, and credentials in prompts and tool responses, and you set the action to block or ask the user on the Rules page.
  • Broker secrets for hosted agents. Coworker Agents can run against a placeholder while MintMCP substitutes the real value into outbound requests, so the raw secret never reaches the model or the agent's own code.

Credential values stay out of the logs. The audit trail records that a credential was created, updated, rotated, or revoked, along with who did it, and the gateway request log has always scrubbed bearer tokens.

MCP02: Privilege escalation via scope creep​

The risk: permissions defined loosely at rollout keep widening, until an agent can reach systems nobody intended it to touch.

The control is structural rather than reactive: build each role a Virtual MCP containing only the connectors and tools that role needs, and a tool that isn't in the server can't be called, because it isn't there to call.

What to configure:

  • One Virtual MCP per role, with the access policy pointed at a directory group. Role-based access control walks through the pattern, including the read-only and read-write split where the same connector appears in two servers with different tool sets and different groups.
  • Let SCIM drive membership. Group membership comes from your IdP, so a transfer or a departure changes tool access at the next sync without an admin touching MintMCP. See SSO and SCIM.
  • Trim the tool set to the job. Tool customization disables the tools a role doesn't need, which shrinks both the attack surface and the context window.
  • Delegate without handing out admin. Grant Can Edit on a single Virtual MCP, or assemble a custom org role for a team that needs guardrails or connector deployment but not the whole organization. Org-wide admin bypasses every Virtual MCP access policy, so keep that role small.
  • Give each agent its own identity and its own server. An agent identity gets a narrow Virtual MCP, its own credential, and its own audit trail, instead of running on a human's key and inheriting everything that human can do.

For access reviews, each Virtual MCP's settings page shows the grant and revoke history with the role, subject, actor, and timestamp, so you can reconstruct who could reach a server at any point in time.

MCP03: Tool poisoning​

The risk: a tool or its description changes after you approved it, and because descriptions feed straight into the agent's reasoning, the new text steers behavior without any code changing on your side.

MintMCP compares each refreshed connector manifest against the stored one and treats a changed tool surface as an event you review rather than a silent update.

What to configure:

  • Set the manual-approval update policy on any Virtual MCP whose callers run in production or whose connector is operated by a third party, so new tools arrive disabled until an admin enables them. That's a different control from tool call approval and the ask-user rule action covered under MCP06, both of which approve an individual call rather than a new tool joining the server. Enterprise organizations can apply Force-disable new tools org-wide from the MCP store settings tab so the policy holds everywhere. See org-wide force-disable.
  • Turn on Slack alerts for tool changes so an added, removed, or modified tool reaches a human channel. The tool change history keeps every manifest version with a character-level diff of the descriptions, and acknowledging a version records that an admin reviewed it.
  • Override the descriptions that matter. Renaming a tool and adding your own documentation puts the text the agent reads under your control rather than the upstream server's. See tool customization.
  • Screen tool traffic with middleware. The OpenAI jailbreak detection, AWS Bedrock guardrails, and Google Cloud Model Armor starter templates send arguments and responses to a classifier and block or mask high-confidence flags.

MCP04: Supply chain and dependency tampering​

The risk: a dependency or an image changes underneath a connector and alters what it does.

MintMCP's answer is containment plus change detection: control what runs, pin what it runs from, and keep a record of what its tool surface looked like at each point.

What to configure:

  • Pin hosted connector images to a digest. In connector settings, set the Container Image to a digest reference such as org/my-server@sha256:... rather than a floating tag, so a redeploy runs the bits you reviewed. See Docker images for hosted servers.
  • Run third-party servers as hosted connectors. They run inside MintMCP's managed infrastructure with no inbound route from the internet, and the gateway is the only thing that can reach them, so a compromised server has nowhere to accept connections from.
  • Keep the MCP store curated. Admins register connectors and members consume what's published, so the review happens once, at registration, instead of on every developer's laptop.
  • Keep the manifest change history as your record of what changed. Every version of a connector's tool surface is stored with a diff, so "when did this tool start doing that?" has an answer, even though that answer covers what changed rather than where the image or package originated. See tool change notifications.
  • Authenticate to private registries with npm_config_* environment variables on the connector rather than publishing internal packages. See private npm packages.

MCP05: Command injection and execution​

The risk: an agent builds a shell command or a query out of untrusted input and executes it.

What to configure:

  • Write tool-argument rules for the dangerous shapes. A rule matches a tool pattern plus argument conditions, so Bash with command: kubectl.*secret blocks before it runs. Actions are flag, block, ask the user, mask, or notify Slack. See Agent Monitor rules.
  • Match the phase to the outcome you want. Pre-tool rules stop execution; post-tool rules only shape what the model sees afterward. The support matrix covers which combinations work on Claude Code, Codex, Cursor, and GitHub Copilot.
  • Use middleware when a regex isn't enough. Middleware parses arguments structurally, checks them against a list it fetches at call time, and rejects what doesn't match. Set the failure behavior to fail-closed for policy-critical checks, and stage new logic in dryrun mode against real traffic first.
  • Remove the capability where the role doesn't need it. Disabling raw-execution tools on a Virtual MCP is cheaper and harder to bypass than filtering their arguments.
  • Keep the kill switch in your runbook for the case where something is already running.

MCP06: Intent flow subversion​

The risk: instructions hidden in the context (a document, a ticket, a tool result) redirect the agent away from what the user asked for.

Direct injection arrives in the prompt and indirect injection arrives in a tool result, so cover both phases.

What to configure:

  • Enable the built-in prompt-injection rules and add regex rules for patterns specific to your environment, from the Rules page.
  • Gate a consequential tool behind approval at the gateway. Tool call approval pauses a specific tool for every caller, not just clients with hook support: the agent gets back an error telling the user to open a link, and the call only runs once a person approves the exact arguments in the browser. This approves the call itself, not new tools joining a server (that's MCP03's update policy).
  • Add the ask-user rule action for supported coding agents. Agent Monitor rules can pause a matching call and prompt the user inside the client itself, for clients with hook support. Agents that can't prompt from a hook block the call instead, and on Codex the call proceeds with the rule's reason passed to the agent as context.
  • Mask on the post phase for indirect injection. Hostile text usually rides in on a tool result, so a post-phase middleware that sanitizes the result lets the agent keep working on clean content, and the jailbreak-detection template already screens both arguments and responses.
  • Watch the flagged traffic. Rules set to flag only still record the match, and the detections in each record name the rule, the action, and the matched text, so you can tune before you enforce.

MCP07: Insufficient authentication and authorization​

The risk: weak or missing identity validation between clients, servers, and agents.

Every Virtual MCP exposes an OAuth 2.0 endpoint, so there is no unauthenticated path to a gateway tool call, and the access policy is evaluated per request rather than at connect time.

What to configure:

  • Delegate authentication to your IdP. SSO and SCIM covers Okta, Microsoft Entra ID, Google Workspace, and other SAML and OIDC providers. Suspending a user in the IdP deactivates them in MintMCP and invalidates their sessions.
  • Authenticate non-human callers as agents, not as people. CI jobs and runtimes use bearer keys or M2M tokens bound to an agent identity, and an M2M client ID is bound to one Virtual MCP, so a token minted for one agent can't be replayed against another.
  • Restrict callers by network where it applies. The Client IP allowlist middleware template checks the caller's public IP as resolved by MintMCP's ingress, not a caller-supplied header, and fails closed when the origin isn't trusted.
  • Know who bypasses policy. Org-wide admins bypass all Virtual MCP access policies by design, so audit that role during access reviews.
  • Keep the kill switch available. It rejects user and agent authentication paths together while leaving the admin UI and audit reads working, which is what you want during an investigation.

MCP08: Lack of audit and telemetry​

The risk: limited logging leaves an investigation with nothing to work from.

MintMCP logs on both sides of the agent: the gateway records what came through it, and Agent Monitor records what the agent did locally, including file reads, commands, and MCP calls to servers the gateway never saw.

What to configure:

  • Export to your SIEM. SIEM export streams gateway requests, Agent Monitor tool calls and prompt submissions, and audit events over OTLP/HTTP or Splunk HEC, with documented schemas for each record type. Gateway records carry the user or agent, the tool, the status, the duration, and a detections array naming every rule that fired.
  • Verify audit records offline. Access-grant history rows are signed per record at write time and stored append-only, the signature travels with the exported record, and the public verification key is published as JWKS at /.well-known/mintmcp/audit-signing/jwks.json. An auditor can confirm an exported record matches what MintMCP wrote without trusting the pipeline it passed through.
  • Cover configuration as well as traffic. The enterprise audit log shows version-by-version diffs of configuration changes, with encrypted header values represented as stable fingerprints so you can confirm a secret changed without exposing it. Operational actions (kill switch, tool enable and disable, connector restarts, credential updates) land in the same place.
  • Set retention to match your policy. Agent Monitor keeps logs for 7 days by default, and enterprise organizations can customize retention per field. See data retention and permissions.

For the full requirements view, see audit and observability.

MCP09: Shadow MCP servers​

The risk: unapproved servers running outside governance, often with default credentials and permissive configuration.

MintMCP's answer has two layers that mature independently: give people a sanctioned path good enough that they use it, and build an inventory of what still runs outside it so a server nobody approved shows up as a decision instead of staying invisible. That inventory is the control you can count on across every client. Turning it into a hard block is a policy layer on top, and how completely a denial enforces depends on the tool-identity detail the calling client's Agent Monitor hooks report.

What to configure:

  • Make the gateway the entrypoint. Users connect their AI client to a Virtual MCP and authenticate once, and because MintMCP holds the downstream credentials, there is no local server to stand up and no token to copy onto a laptop. See clients overview.
  • Inventory what agents actually call, across every client. Agent Monitor hook events identify local stdio MCP servers by command as well as remote servers by URL, so a server someone configured privately in Claude Code or Cursor appears in Live Activity and in your SIEM export alongside sanctioned traffic, whether or not you ever enforce against it.
  • Layer allow and deny decisions on top where client coverage supports it. Open Guardrails → Rules and the Tool allowlist tab, where tools appear once MintMCP observes them in agent traffic and you allow or deny at the level that fits: a single tool, an entire agent, or an entire MCP server. Treat this as policy on top of an inventory that already covers every client, not a uniform network-level block, since enforcement depends on the tool identity each client's hooks expose. Newly observed tools still land in an uncategorized state with their own review queue, so a server nobody approved surfaces as a decision instead of disappearing into ordinary traffic.
  • Alert on the uncategorized state. Attach a Slack notification to uncategorized detections so a new server reaches your security channel when it first appears, and add a block or ask action on top where you want it enforced rather than just flagged.
  • Deploy monitoring through MDM. Pushing managed-settings.json through Kandji, Intune, or Jamf takes precedence over user-level settings, which keeps hooks, and the inventory they feed, in place on every machine. See MDM deployment.

MCP10: Context injection and over-sharing​

The risk: context that's shared or scoped too broadly exposes one user's, one task's, or one agent's data to another.

What to configure:

  • Scope the context to the role. A Virtual MCP built for a role carries only that role's tools, so nothing about another team's systems enters the agent's context. See tool customization.
  • Push authorization down to the system that owns the data. Per-user credentials mean the downstream applies its own permissions per caller. Where a shared credential is the only option, identity forwarding passes the caller's email (X-MintMCP-User-Email for remote connectors, opt-in per connector, and MINTMCP_USER_EMAIL for hosted connectors) so a cooperating upstream can still enforce and log per user.
  • Redact sensitive content in flight. The AWS Bedrock guardrails (mask), Google Cloud Model Armor (mask), and Teleskope PII/PCI redaction templates substitute redacted content and let the call continue, so a match doesn't cost the user their workflow. Originals are preserved in the audit log even when a call is masked.
  • Separate agents by purpose. One agent identity per workflow keeps one agent's credentials and results out of another's context, and agent-scoped secrets are namespaced so one agent can't read another's.

Rollout checklist​

Confirm these before a deployment scales past a pilot:

  • Shared bearer tokens resolve from a secret provider rather than pasted values (MCP01)
  • Every agent credential has an expiry, and agents that can run a token exchange use M2M tokens (MCP01)
  • Each Virtual MCP maps to one role, with its access policy pointed at a directory group (MCP02)
  • Every agent has its own identity and its own narrow Virtual MCP (MCP02)
  • Production Virtual MCPs require manual approval for new tools, and Slack alerts go to a channel someone reads (MCP03, MCP04)
  • Hosted connector images are pinned to a digest (MCP04)
  • Tool-argument rules cover the destructive commands in your environment, on the pre-tool phase (MCP05)
  • Policy-critical middleware is set to fail closed (MCP05)
  • Prompt-injection rules are enabled, tool call approval gates consequential tools, and post-phase screening covers tool results (MCP06)
  • SSO and SCIM are configured, and the org-wide admin role is small (MCP07)
  • SIEM export is enabled and receiving gateway, Agent Monitor, and audit records (MCP08)
  • Agent Monitor hooks are deployed through MDM so the tool inventory covers every machine, not just some (MCP09)
  • The tool inventory is reviewed regularly, with the allowlist enforcing where client coverage supports it and an alert on uncategorized tools (MCP09)
  • DLP or PII masking middleware runs on connectors that touch regulated data (MCP10)