--- title: "How MCP Servers Expose Enterprise Secrets: Five Paths and the CVEs Behind Them" description: "MCP servers are where agent credentials actually live. Five exposure paths - plaintext config, sprawl, injection, over-permissioning, and the server supply chain - with the CVEs that prove each one." url: "https://anomity.ai/blog/mcp-server-secrets-exposure-enterprise-credentials/" source: html --- On this page - The five paths, at a glance - Path 1: the config file is the new .env - Path 2: sprawl, and the credential that never rotates - Path 3: injection turns a valid credential into an attacker's credential - Path 4: development scopes that shipped - Path 5: the connector itself - The mitigations, ordered by what they actually fix - The inventory is the precondition, not the last step - A working sequence - Where Anomity fits - Frequently asked questions [← Back to blog](https://anomity.ai/blog/) - Home - Blog - How MCP Servers Expose Enterprise Secrets: Five Paths and the CVEs Behind Them ![Anomity robot illustrating How MCP Servers Expose Enterprise Secrets: Five Paths and the CVEs Behind Them] Guide # How MCP Servers Expose Enterprise Secrets: Five Paths and the CVEs Behind Them Anomity Research Anomity Research · Aug 17, 2026 · 9 min read Share: Copied TL;DR - An MCP server is the component that holds the credential. The agent asks; the server authenticates. That makes the server, not the model, the place enterprise secrets are most often exposed. - Path 1 - plaintext config. Tokens and keys sit in local JSON config, unencrypted, copied between machines and committed to Git by accident. - Path 2 - credential sprawl. Without a central store, the same secrets scatter across dev, staging, and production servers and are rarely rotated, so they stay valid indefinitely. - Path 3 - prompt injection. Instructions hidden in a document, ticket, or web page steer the agent into misusing a tool or disclosing a secret. Cross-channel variants such as GhostSplice defeat per-message filtering entirely. - Path 4 - over-permissioning. Broad scopes granted during development ship to production because nobody revisits them. - Path 5 - the server supply chain. CVE-2025-6514 in mcp-remote , an OAuth proxy with more than 400,000 downloads, let a malicious server trigger OS command injection and reach RCE on the machine running the proxy. - The compounding factor is that an MCP credential is not just readable, it is actionable. A leaked token does not only expose data; it grants an autonomous system the ability to act on it. There is a useful way to think about where AI agent credentials actually live, and it is not the model. The model reasons. The **MCP server** authenticates. When an agent queries Jira or writes to a bucket, the tool call goes to a connector that holds a token and makes the real request. That design keeps secrets out of the context window, which is correct, and it relocates them into a component that most security programmes have never inventoried. **MCP server secrets exposure** is therefore a filesystem, identity, and supply-chain problem wearing an AI label, and it responds to conventional controls if you can find the servers. A contributed piece published by The Hacker News on 17 August 2026, written by Ashley D'Andrea of Keeper Security, lays out five mechanisms by which this goes wrong. The framing is a vendor's and the underlying mechanics are not in dispute, so what follows takes each path and attaches the specific incidents and CVEs that demonstrate it, which is the part a vendor overview leaves out. > A leaked MCP credential does not only expose data. It hands an autonomous system the ability to act on it. Anomity Research ## The five paths, at a glance Path What goes wrong Demonstrated by Control that closes it Plaintext credentials in config Tokens and keys stored unencrypted in local JSON, copied and committed Routine finding on developer endpoints across every fleet we have looked at Managed store plus runtime injection Credential sprawl Same secrets duplicated across dev, staging, and prod servers, never rotated Long-lived static tokens surviving team changes Short-lived credentials with automatic rotation Prompt injection Hidden instructions steer the agent into disclosing or misusing a secret [GhostSplice](https://anomity.ai/blog/ghostsplice-cross-channel-mcp-instruction-splitting/), [MCP tool poisoning](https://anomity.ai/blog/mcp-tool-poisoning-hidden-instructions-campaign/) Tool-call evaluation at execution time Over-permissioning Broad development scopes ship to production unreviewed [MCP server for Kubernetes tool access bypass](https://anomity.ai/blog/mcp-server-kubernetes-tool-access-bypass-cve-2026-46519/) Least privilege per server, reviewed on promotion Server supply chain The connector itself is vulnerable or hostile `CVE-2025-6514` in [`mcp-remote`](https://anomity.ai/blog/mcp-remote-os-command-injection-cve-2025-6514/) Vetting plus an inventory of what got installed anyway ## Path 1: the config file is the new .env MCP servers routinely store tokens and keys in local configuration files, in plaintext. That file gets overlooked, copied between machines, and committed to a repository by accident. None of this is novel; it is the `.env` problem, inherited by a component that did not exist two years ago and therefore sits outside whatever secret-scanning and pre-commit hygiene the organisation already built. What is new is the reader. A plaintext credential on a developer laptop used to require an attacker with code execution on that laptop. Now it also requires only an agent with local file access and a bad afternoon, because agents read config files as a matter of course. That is the mechanism in [the lethal trifecta](https://anomity.ai/blog/lethal-trifecta-ai-agent-data-exfiltration/) and the reason the GhostSplice researchers targeted `.env` and `.ssh/id_rsa` specifically: those paths are where the value is, and the agent can already reach them. The fix is the standard one, applied to a new location: keep secrets in a managed store, inject them at runtime, and never persist them to the agent's working environment. [Secrets management for AI agents](https://anomity.ai/blog/secrets-management-for-ai-agents/) works through the practices in detail. The MCP-specific addition is that you have to know which config files exist before you can empty them. ## Path 2: sprawl, and the credential that never rotates Without centralised storage, the same secrets end up duplicated across servers in development, staging, and production. The article's sharpest observation is about time rather than place: these secrets rarely get rotated, leaving them valid and static indefinitely. Static is the operative word. A human credential has a lifecycle attached to an employee: onboarding, review, offboarding. An MCP server's token has no such anchor. It was created for a proof of concept by someone who has since changed teams, it works, and nothing in the system has an opinion about how old it is. This is the non-human identity problem in its most mundane form, covered in [non-human identity governance](https://anomity.ai/blog/non-human-identity-governance-guide/), and it is why the survey finding that **63% of enterprises still report credential sharing somewhere in the fleet** is entirely believable even among organisations that have issued per-agent identities, as discussed in [the agent containment gap](https://anomity.ai/blog/ai-agent-containment-gap-identity-without-isolation/). ## Path 3: injection turns a valid credential into an attacker's credential Attackers hide instructions inside a document, support ticket, or web page the agent accesses, and the agent misuses a tool or reveals a secret. The important property is that no credential is stolen in the traditional sense. The legitimate credential is used, by the legitimate agent, to perform the attacker's request. This is why vaulting alone does not close the path. A short-lived, properly scoped, freshly rotated token will happily service an injected instruction. [Indirect prompt injection](https://anomity.ai/blog/indirect-prompt-injection-explained/) covers the general mechanism, and the current state of the art is worse than per-message filtering can handle: [GhostSplice](https://anomity.ai/blog/ghostsplice-cross-channel-mcp-instruction-splitting/) distributes the instruction across a tool description and two tool results so that no individual fragment is objectionable, and researchers report average model compliance rising from 42% to 82% as a result. [MCP tool poisoning](https://anomity.ai/blog/mcp-tool-poisoning-hidden-instructions-campaign/) is the same idea placed in the tool metadata itself. The control that survives contact with this is evaluation at the point of the tool call. The fragments are invisible; the outbound request carrying `.env` contents to an unfamiliar host is not. ## Path 4: development scopes that shipped Developers grant MCP servers broad permissions to get something working, and those permissions tend to reach production because nobody remembers to narrow them. The pattern is familiar from OAuth applications and CI service accounts. What differs is the actor at the other end: an autonomous system that will exercise the full breadth of a scope without the implicit self-restraint a human operator applies. Concrete examples of scope failure in MCP implementations are already on record. [The Kubernetes MCP server tool access bypass](https://anomity.ai/blog/mcp-server-kubernetes-tool-access-bypass-cve-2026-46519/) is a case where declared restrictions did not hold, and [LiteLLM's allowed-routes privilege escalation](https://anomity.ai/blog/litellm-allowed-routes-privesc-cve-2026-47101/) is the same category in the gateway layer. Our own data on what agents ask for is in [the most requested AI permissions](https://anomity.ai/blog/most-requested-ai-permissions/), and the principle is worked through in [least privilege for AI agents](https://anomity.ai/blog/least-privilege-for-ai-agents/) and [AI access control and least privilege](https://anomity.ai/blog/ai-access-control-and-least-privilege/). A practical rule: treat scope as something reviewed on promotion, not on creation. The scope that was reasonable on a laptop against a test project is the scope that becomes a production incident when the same config is copied to a shared runner. ## Path 5: the connector itself The strongest evidence in the piece is `CVE-2025-6514` in **mcp-remote**, an OAuth proxy for MCP with more than **400,000 downloads**, where a malicious server could trigger OS command injection and achieve remote code execution on the machine running the proxy. We covered it in [mcp-remote OS command injection](https://anomity.ai/blog/mcp-remote-os-command-injection-cve-2025-6514/). The lesson is not that one package was flawed. It is that the MCP supply chain now includes proxies, bridges, and inspectors that developers install from a README without any of the review a production dependency would attract. That class is well populated at this point: [the MCP Inspector proxy unauthenticated RCE](https://anomity.ai/blog/mcp-inspector-proxy-unauth-rce-cve-2025-49596/), [the MCP Connect bridge unauthenticated RCE](https://anomity.ai/blog/mcp-connect-bridge-unauthenticated-rce-ghsa-wvr4-3wq4-gpc5/), [Atlassian MCP SSRF to RCE](https://anomity.ai/blog/mcp-atlassian-ssrf-to-rce-cve-2026-27825/), [the Windows MCP unauthenticated PowerShell RCE](https://anomity.ai/blog/windows-mcp-unauthenticated-powershell-rce-ghsa-vrxg-gm77-7q5g/), and the design-level exposure in [stdio transport as an RCE surface by design](https://anomity.ai/blog/anthropic-mcp-stdio-by-design-rce/). Add [the fURI SSRF pattern across the ecosystem](https://anomity.ai/blog/mcp-furi-markitdown-ssrf-ecosystem-scale/) and the shape is clear: connectors are code, they run with the developer's privileges, and they were adopted at a speed no review process matched. ## The mitigations, ordered by what they actually fix Control Closes Does not close Centralised secret store, injected at runtime Plaintext config, accidental commits Over-permissioning, injection, unknown servers Short-lived credentials with automatic rotation Sprawl, indefinitely valid tokens Injection, since a fresh token services the attacker's request Least privilege per server, reviewed on promotion Blast radius of any single compromise The fact that a compromise happened Human approval for sensitive actions Obviously wrong invocations Approval fatigue, and prompts that show a tool name rather than a payload Logging and audit of agent actions The ability to answer what happened Nothing in real time, unless the log is evaluated before execution Inventory of every MCP server present The precondition for all of the above Nothing by itself. It is the enumeration, not the enforcement Two entries in that table deserve emphasis because they are routinely treated as complete answers when they are not. Human approval degrades predictably: a reviewer approving twenty tool calls an hour is not reading them by the fifth, which is the approval-fatigue dynamic behind every blanket allow rule and the reason [Claude Code's dangerously-skip-permissions flag](https://anomity.ai/blog/claude-code-dangerously-skip-permissions-explained/) gets set. And logging answers questions after the fact. An audit trail is essential evidence and it is not a control until something evaluates the call before it runs, which is the distinction drawn in [how Claude Code hooks work](https://anomity.ai/blog/how-claude-code-hooks-work/). ## The inventory is the precondition, not the last step The article's final recommendation is to inventory all MCP servers to eliminate shadow AI, and it belongs at the top rather than the bottom. Every other control in the list binds to a specific server: you cannot vault credentials for a server you have not found, cannot scope its permissions, cannot review its supply chain, and cannot rotate what it holds. In practice the gap between the architecture diagram and the endpoints is where the exposure lives. Developers install MCP servers from README snippets and one-click deeplinks, which is exactly how [DeepJack](https://anomity.ai/blog/deepjack-cursor-deeplink-mcp-install-rce/) worked, and the resulting population is invisible to provider-native tooling because it spans providers. [How to build an MCP server registry](https://anomity.ai/blog/how-to-build-an-mcp-server-registry/) covers the approval path, [how to build an AI agent inventory](https://anomity.ai/blog/how-to-build-an-ai-agent-inventory/) covers the enumeration, and [MCP security explained](https://anomity.ai/blog/model-context-protocol-mcp-security-explained/) covers the protocol-level context. For the authentication design itself, [OAuth for MCP servers](https://anomity.ai/blog/oauth-for-mcp-servers-explained/) and [AI gateway OAuth passthrough](https://anomity.ai/blog/ai-gateway-oauth-passthrough-mcp/) explain why token passthrough patterns quietly widen the blast radius. ## A working sequence - Enumerate MCP servers from endpoints rather than from documentation, and reconcile the two lists. Expect the endpoint list to be longer. - Sort the result by which servers hold credentials to production systems, and treat that subset as in-scope for immediate remediation. - Empty the plaintext configs into a managed store, and switch to runtime injection so nothing durable remains on disk. - Re-scope on promotion. Any server moving from a laptop to shared infrastructure gets its permissions reviewed as a gate, not as a follow-up ticket. - Add tool-call evaluation for the specific pattern that matters: sensitive file contents appearing in the arguments of an outbound call. - Alert on MCP servers appearing on endpoints outside the registry, and on installed servers whose tool surface changes after installation. - Rotate anything a hostile or unreviewed server could have read, on the assumption that static credentials in an agent's reach have already been read once. ## Where Anomity fits Anomity supplies the enumeration the whole list depends on. A lightweight, unprivileged Endpoint Sensor inventories **eight AI artifact types** per machine - agents, MCP servers, skills, extensions, plugins, hooks, CLIs, and **secrets** - so plaintext credentials sitting beside an MCP config are a finding rather than an assumption. It is provider-agnostic, which matters because the same developer typically has servers wired into more than one client. Metadata only leaves the endpoint over HTTPS, and secrets are redacted on the endpoint before anything is transmitted, so the tool that finds your exposed credentials does not become another copy of them. On agents that expose a hook, such as Claude Code's `PreToolUse`, [runtime governance](https://anomity.ai/#runtime-governance) returns **allow**, **deny**, or **log** on each tool call before it executes, which is the layer that catches path three when filtering has already failed. Every added, changed, and removed artifact lands in a [queryable 90-day audit trail](https://anomity.ai/#outcomes), and violations route to your SIEM, Slack, email, and Jira through [continuous policy evaluation](https://anomity.ai/#features). Anomity complements a secrets manager rather than replacing one: the vault fixes where credentials live, and Anomity tells you which servers still have credentials somewhere else. To see which MCP servers and secrets are present across your fleet today, [book a 30-minute demo](https://anomity.ai/#early-access). For a concrete identity-broker failure - spoofable sessions plus SSRF - see [Grafana MCP CVE-2026-19516](https://anomity.ai/blog/grafana-mcp-session-spoofing-ssrf-cve-2026-19516/). Shared MCP env credentials become an unauthenticated broker under the [MCP HTTP fallback-auth pattern](https://anomity.ai/blog/mcp-http-fallback-auth-global-credentials-class-2026/). A concrete Critical is [mcp-atlassian CVE-2026-77254](https://anomity.ai/blog/mcp-atlassian-http-auth-bypass-global-credentials-cve-2026-77254/). Share: Copied ## Frequently asked questions Why do MCP servers hold secrets at all? Because MCP is the connector layer, and connecting to Jira, GitHub, Snowflake, or an internal API requires authenticating to it. The agent issues a tool call; the MCP server performs the authenticated request on its behalf. That division is deliberate and sensible, since it keeps credentials out of the model's context window. The consequence is that credentials accumulate in the server's configuration and environment instead, which is a filesystem problem rather than a prompt problem, and it is handled by an entirely different set of controls. What is wrong with putting a token in an MCP config file? Three things. It is stored unencrypted, so anything that can read the developer's home directory can read it, including another agent running on the same machine. It travels, because config files get copied between machines, shared in onboarding docs, and committed to repositories by accident. And it is static, because nothing about a file on disk causes rotation, so a token written during a proof of concept can still be valid a year later. The pattern is the .env file problem inherited by a new component, which is the argument in secrets management for AI agents. How does prompt injection lead to credential exposure specifically? The agent can read content it did not author - a support ticket, a scraped page, a README, a tool result - and that content can contain instructions. If the agent has both a tool that reads local files and a tool that makes outbound requests, an injected instruction can move the contents of a credential file from one to the other. Neither tool did anything it was not authorized to do. This is the lethal trifecta pattern: private data access, exposure to untrusted content, and an outbound channel, present simultaneously. What was CVE-2025-6514? A command injection vulnerability in mcp-remote, a widely used OAuth proxy for MCP with more than 400,000 downloads. A malicious or compromised MCP server could trigger OS command injection in the proxy, leading to remote code execution on the machine running it. It is the clearest available demonstration that the MCP supply chain is a real attack surface: the vulnerable component was not the agent and not the model, but a piece of connector plumbing most teams installed without review. Is a managed secrets vault enough on its own? It is necessary and it is not sufficient. A vault fixes storage and rotation, which removes the plaintext and sprawl paths. It does nothing about over-permissioning, since a short-lived credential with excessive scope is still excessive. It does nothing about injection, since the agent will use a properly injected credential to perform the attacker's request. And it does nothing about a server you did not know was installed. Vaulting plus scoping plus runtime evaluation plus inventory is the working set. Where do I start if I have no MCP inventory today? Start with enumeration, because every other control binds to it. Collect the MCP server configurations present on developer endpoints, not the ones in your architecture diagram, and reconcile the two lists. In most organisations the endpoint list is longer and contains servers nobody approved. From there, sort by which servers hold credentials to production systems, and fix those first. Building an MCP server registry describes the approval path that keeps the list from re-diverging. ## Related [Advisory Critical ### mcp-atlassian HTTP Auth Bypass Falls Back to Global Credentials - CVE-2026-77254 CVE-2026-77254 (CVSS 9.1): unauthenticated HTTP MCP requests to mcp-atlassian below 0.22.0 fall through to globally configured Jira/Confluence credentials. Sibling CVE-2026-77244 (CVSS 10.0) accepts any non-empty token. Anomity Research · Sep 28, 2026 · CVE-2026-77254 (CVSS 9.1, GHSA-vc8m-84rp-53hx); sibling CVE-2026-77244 (CVSS 10.0, GHSA-wrhw-j3f9-8vc6)](https://anomity.ai/blog/mcp-atlassian-http-auth-bypass-global-credentials-cve-2026-77254/) [Advisory Critical ### GitLab MCP CVE-2026-61568 - Streamable HTTP DNS Rebinding to Localhost CVE-2026-61568 (CVSS 9.6): @zereight/mcp-gitlab Streamable HTTP skipped SDK DNS-rebinding Host/Origin allowlists on loopback - fixed in 2.1.30. Anomity Research · Sep 21, 2026 · CVE-2026-61568 (CVSS 9.6, GHSA-vmp7-252j-cwp7)](https://anomity.ai/blog/mcp-gitlab-streamable-http-dns-rebinding-cve-2026-61568/) [Advisory Critical ### MySQL MCP Server CVE-2026-59971 - Unauthenticated SQL via SSE DNS Rebinding CVE-2026-59971 (CVSS 10.0): mysql-mcp-server SSE mode skipped Host/Origin DNS-rebinding protection, bound 0.0.0.0 with no auth - unauthenticated SQL until 0.4.2. Anomity Research · Sep 21, 2026 · CVE-2026-59971 (CVSS 10.0, GHSA-rqfv-2mw9-78g2)](https://anomity.ai/blog/mysql-mcp-server-sse-dns-rebinding-unauth-sql-cve-2026-59971/) ## Structured data ```json { "@context": "https://schema.org", "@type": "Article", "headline": "How MCP Servers Expose Enterprise Secrets: Five Paths and the CVEs Behind Them", "description": "MCP servers are where agent credentials actually live. Five exposure paths - plaintext config, sprawl, injection, over-permissioning, and the server supply chain - with the CVEs that prove each one.", "datePublished": "2026-08-17", "dateModified": "2026-08-17", "author": { "@type": "Organization", "name": "Anomity", "url": "https://anomity.ai/", "sameAs": [ "https://www.linkedin.com/company/anomity", "https://github.com/Anomity-ai", "https://www.wikidata.org/wiki/Q140763940" ] }, "publisher": { "@type": "Organization", "name": "Anomity", "url": "https://anomity.ai/", "sameAs": [ "https://www.linkedin.com/company/anomity", "https://github.com/Anomity-ai", "https://www.wikidata.org/wiki/Q140763940" ], "logo": { "@type": "ImageObject", "url": "https://anomity.ai/icon-512.png" } }, "mainEntityOfPage": { "@type": "WebPage", "@id": "https://anomity.ai/blog/mcp-server-secrets-exposure-enterprise-credentials/" }, "image": { "@type": "ImageObject", "url": "https://anomity.ai/assets/blog/covers/mcp-servers.jpg", "width": 1200, "height": 630 }, "articleSection": "MCP Server Security", "url": "https://anomity.ai/blog/mcp-server-secrets-exposure-enterprise-credentials/", "keywords": "MCP server secrets exposure, MCP server secrets exposure, MCP security, credential sprawl, plaintext config, over-permissioning, prompt injection, supply chain, shadow AI" } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Why do MCP servers hold secrets at all?", "acceptedAnswer": { "@type": "Answer", "text": "Because MCP is the connector layer, and connecting to Jira, GitHub, Snowflake, or an internal API requires authenticating to it. The agent issues a tool call; the MCP server performs the authenticated request on its behalf. That division is deliberate and sensible, since it keeps credentials out of the model's context window. The consequence is that credentials accumulate in the server's configuration and environment instead, which is a filesystem problem rather than a prompt problem, and it is handled by an entirely different set of controls." } }, { "@type": "Question", "name": "What is wrong with putting a token in an MCP config file?", "acceptedAnswer": { "@type": "Answer", "text": "Three things. It is stored unencrypted, so anything that can read the developer's home directory can read it, including another agent running on the same machine. It travels, because config files get copied between machines, shared in onboarding docs, and committed to repositories by accident. And it is static, because nothing about a file on disk causes rotation, so a token written during a proof of concept can still be valid a year later. The pattern is the .env file problem inherited by a new component, which is the argument in secrets management for AI agents." } }, { "@type": "Question", "name": "How does prompt injection lead to credential exposure specifically?", "acceptedAnswer": { "@type": "Answer", "text": "The agent can read content it did not author - a support ticket, a scraped page, a README, a tool result - and that content can contain instructions. If the agent has both a tool that reads local files and a tool that makes outbound requests, an injected instruction can move the contents of a credential file from one to the other. Neither tool did anything it was not authorized to do. This is the lethal trifecta pattern: private data access, exposure to untrusted content, and an outbound channel, present simultaneously." } }, { "@type": "Question", "name": "What was CVE-2025-6514?", "acceptedAnswer": { "@type": "Answer", "text": "A command injection vulnerability in mcp-remote, a widely used OAuth proxy for MCP with more than 400,000 downloads. A malicious or compromised MCP server could trigger OS command injection in the proxy, leading to remote code execution on the machine running it. It is the clearest available demonstration that the MCP supply chain is a real attack surface: the vulnerable component was not the agent and not the model, but a piece of connector plumbing most teams installed without review." } }, { "@type": "Question", "name": "Is a managed secrets vault enough on its own?", "acceptedAnswer": { "@type": "Answer", "text": "It is necessary and it is not sufficient. A vault fixes storage and rotation, which removes the plaintext and sprawl paths. It does nothing about over-permissioning, since a short-lived credential with excessive scope is still excessive. It does nothing about injection, since the agent will use a properly injected credential to perform the attacker's request. And it does nothing about a server you did not know was installed. Vaulting plus scoping plus runtime evaluation plus inventory is the working set." } }, { "@type": "Question", "name": "Where do I start if I have no MCP inventory today?", "acceptedAnswer": { "@type": "Answer", "text": "Start with enumeration, because every other control binds to it. Collect the MCP server configurations present on developer endpoints, not the ones in your architecture diagram, and reconcile the two lists. In most organisations the endpoint list is longer and contains servers nobody approved. From there, sort by which servers hold credentials to production systems, and fix those first. Building an MCP server registry describes the approval path that keeps the list from re-diverging." } } ] } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://anomity.ai/" }, { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://anomity.ai/blog/" }, { "@type": "ListItem", "position": 3, "name": "How MCP Servers Expose Enterprise Secrets: Five Paths and the CVEs Behind Them", "item": "https://anomity.ai/blog/mcp-server-secrets-exposure-enterprise-credentials/" } ] } ```