How MCP Servers Can Expose Enterprise Secrets

1. Executive summary

Model Context Protocol (MCP) servers — the middleware connecting AI agents to enterprise data, APIs and infrastructure — are accumulating production credentials (API keys, service account tokens, SSH keys) in plaintext configuration files with over-permissioned access and no central governance. Combined with demonstrated prompt-injection attack chains (corroborated by Microsoft Incident Response and Invariant Labs) that can silently exfiltrate secrets via poisoned tool descriptions, MCP servers represent a rapidly expanding, largely ungoverned attack surface. EMEA financial services deploying AI agents with read-write access to business systems face risk of silent credential theft and data exfiltration that may bypass existing security monitoring, as agents execute actions using legitimate Non-Human Identities (NHIs).

2. Regulatory framing

3. Technical analysis & attack chain

Background. MCP is an open standard introduced by Anthropic that allows AI assistants to connect to external tools and data. An MCP server sits between the AI agent and the target system (database, file store, API), exposing specific actions the agent may perform. To act on the target system, the MCP server holds that system's credentials — API keys, service account keys, tokens, and other secrets. Agents use Non-Human Identities (NHIs) to execute actions across enterprise systems.

Exposure vectors (corroborated across primary source and Microsoft research)

1. Plaintext credentials in configuration files. MCP servers routinely store tokens and keys in local configuration files in plaintext. Setup typically involves pasting a configuration string containing the credentials themselves. These files are left on disk, copied between machines, or committed to Git repositories. Once an attacker reaches the server, all stored credentials are readable.
2. Credential sprawl across ungoverned servers. Without a central secrets store, each AI agent manages its own credentials. The same API keys and tokens are scattered across config files and environment variables, with duplicate copies across development, staging, and production. No full inventory exists; secrets are rarely rotated and remain valid indefinitely.
3. Over-permissioning. Developers grant MCP servers broad permissions during build to avoid authorisation errors. These broad permissions are not subsequently narrowed before production deployment.
4. Prompt injection. Attackers hide instructions within documents, support tickets, or web pages the agent accesses. The agent follows hidden directions as legitimate commands, misusing tools or handing over secrets it was trusted to protect.

Confirmed attack chain — tool description poisoning (corroborated by Microsoft Incident Response and Invariant Labs, April 2025)

This chain was described by Microsoft Threat Intelligence (corpus-3) and reflects techniques first disclosed by Invariant Labs. It maps to OWASP Agentic Applications Top 10 categories ASI02 (Tool Misuse) and ASI04 (Agentic Supply Chain Vulnerabilities).

Phase 1 — Tool description poisoning. A developer pushes an update to a third-party MCP server (in Microsoft's scenario, an invoice enrichment server). The tool name and user-facing summary remain unchanged, but the MCP tool description — the natural-language metadata the agent reads to decide how and when to call the tool — is silently modified. A hidden instruction block, buried within apparent formatting guidance, directs the agent to retrieve sensitive records (e.g., the last thirty unpaid invoices), summarise them, and attach that summary as an additional parameter in the enrichment call, framed as a fraud-heuristic requirement.

Phase 2 — Silent re-trust. MCP reflects tool metadata updates dynamically. Where description changes do not trigger a re-approval workflow, the poisoned instructions become active in production without additional review.

Phase 3 — User invocation. A user (in the scenario, a financial analyst) asks the agent a routine question. The agent follows the hidden instructions embedded in the poisoned tool description, collecting sensitive financial records beyond the scope of the original request and forwarding them as part of the enrichment call to the attacker-controlled or compromised third-party server. No visible indication is presented to the user.

Confirmed attack chain — instruction splitting (single-sourced; Invariant Labs via corpus-2)

A malicious MCP tool server connected to an AI coding assistant can exfiltrate SSH keys, environment secrets, source code, and customer data by splitting a harmful request into fragments that each appear routine. The fragments are placed in channels the assistant already uses. The attack succeeds even after a blunt version of the same theft request is refused — the split fragments individually do not trigger refusal logic. This technique is single-sourced via The Hacker News reporting on Invariant Labs research; verify before enforcement.

Confidence caveat: No MITRE ATT&CK actor attribution is available in the verified reference data for this item. Attribution to any named threat actor is unconfirmed. The attack patterns are described as research disclosures and observed techniques, not attributed to a specific actor.

4. Mitigation & containment

P1 — Within 24 hours

• Inventory all MCP servers. Identify every MCP server running in the environment, including development and staging. Determine which systems each connects to and what credentials each holds. Many deployments occur without security team awareness.
• Audit plaintext credential storage. Search MCP server configuration files and environment variables for plaintext API keys, tokens, and service account credentials. Check Git repositories for committed configuration strings containing credentials.
• Restrict MCP server permissions. Review and narrow permissions on all MCP servers to least privilege. Remove broad wildcard permissions granted during development.

P2 — Within 72 hours

• Centralise secrets management. Move MCP server credentials from plaintext config files and environment variables to a managed secrets vault (e.g., HashiCorp Vault, Azure Key Vault). Ensure MCP servers retrieve credentials at runtime rather than storing them on disk.
• Implement tool-description change detection. Establish a re-approval workflow for MCP tool metadata updates. Monitor for changes to tool descriptions and alert security teams when modifications occur without review. Where possible, pin tool descriptions to known-good versions and block dynamic metadata refresh.
• Review third-party MCP servers. Conduct security review of all third-party and community MCP servers connected to production agents. Evaluate the tool provider's update mechanism and whether description changes propagate without approval.

P3 — Within 7 days

• Deploy agent behaviour monitoring. Implement detection for anomalous agent tool invocations — requests that retrieve data beyond the scope of the user's original query, unexpected additional parameters in tool calls, or data forwarding to external MCP servers. Microsoft indicates that in default configurations no alarm fires for these actions.
• Implement credential rotation. Rotate all credentials currently stored in MCP server configurations, particularly those that have been committed to repositories or copied between environments.
• Establish MCP governance policy. Define requirements for security review before MCP server deployment, mandatory secret management controls, permission scoping standards, and tool-description integrity verification. Include MCP servers in ICT third-party risk assessments under DORA Art. 28.

5. Indicators of compromise

No indicators of compromise available in the source material.

Behavioural indicators

6. Detection

Insufficient indicators to author detection rules.

The source material describes behavioural patterns (tool description poisoning, instruction splitting, credential sprawl) but does not contain specific atomic artefacts — file hashes, distinctive strings, command-line flags, mutex names, or registry keys — that would enable reliable YARA or Sigma rule authorship. The behavioural indicators in §5 should be implemented as custom detection logic in agent orchestration monitoring and SIEM correlation rules, keyed to the behaviours described rather than to static indicators.

7. Sources

• The Hacker News, "How MCP Servers Can Expose Enterprise Secrets," https://thehackernews.com/2026/08/how-mcp-servers-can-expose-enterprise.html, 2026-08-17
• The Hacker News, "Microsoft Warns Poisoned MCP Tool Descriptions Can Make AI Agents Leak Data," https://thehackernews.com/2026/06/microsoft-warns-poisoned-mcp-tool.html, 2026-06
• The Hacker News, "Malicious MCP Servers Can Split Instructions to Make AI Coding Agents Exfiltrate Secrets," https://thehackernews.com/2026/08/malicious-mcp-servers-can-split.html, 2026-08
• Microsoft Threat Intelligence, "Securing AI agents: When AI tools move from reading to acting," https://www.microsoft.com/en-us/security/blog/2026/06/30/securing-ai-agents-ai-tools-move-from-reading-acting/, 2026-06-30

8. Adverse Trace position

This is a high-severity exposure class for EMEA financial services actively deploying AI agents with MCP integrations. The attack surface is real and expanding: MCP servers hold production credentials, are deployed without security review, store secrets in plaintext, and are vulnerable to demonstrated prompt-injection chains that exfiltrate data without triggering alerts. The tool-description poisoning chain is corroborated by Microsoft Incident Response and Invariant Labs; the instruction-splitting technique is single-sourced and should be verified before enforcement. No specific threat actor attribution is confirmed. Clients should treat MCP server governance as an immediate priority: inventory, secrets centralisation, permission scoping, and tool-description change monitoring are the minimum viable controls. We will continue tracking MCP-related attack techniques and will issue updated guidance as detection patterns mature.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.