When the MCP server keeps your credentials: the silent attack vector of the IA in production

The incorporation of IA agents into business processes has opened a practical way for production systems and data to be accessible from models: it is called Model Context Protocol (MCP) and, according to its original specification, was promoted by Anthropic so that attendees and agents can call live data and tools. What has started to be noticed in audits and technical reports is that the MCP server - that intermediary that connects the agent to APIs, files and databases - usually becomes the repository of the credentials necessary to act. When such credentials are poorly protected, the ability of an attacker to read data becomes the ability to act on behalf of the agent.

Technically, an MCP server exposes a set of actions that the agent can invoke and, to execute these actions, needs credentials: service keys, OAuth tokens, environment variables with secrets or configuration chains. In many practical implementations, these credentials end up in local configuration files or in flat text environment variables; in others, they replicate between environments (development, staging, production) because there is no centralized warehouse or automatic rotation processes. In addition, the agent operates with non-human identities (NHIs) that allow not only reading but also modifying and implementing changes. So, stealing a token from the MCP server is not just filtering data: it is getting a key to perform operations on the systems that the agent had access to manage.

Exposure vectors that are confirmed by multiple analyses and public incidents include, inter alia: flat text configuration files or environment variables containing tokens; proliferation and duplication of credentials without rotation; prompt injection where malicious content in a document or web induces the agent to expose secrets or execute undue actions; excessive permits assigned for comfort during development that then reach production; and supply chain risks when connecting to unreliable MCP servers. A public example cited in technical reports is the vulnerability assigned as CVE-2025-6514 in mcp-remote - a proxy OAuth used in customers and with more than 400,000 downloads - where a malicious server could trigger the injection of operating system commands and remote code execution, thus allowing the theft of credentials on the client machine. For more technical information on MCP and its design, see the public repository of the GitHub specification: https: / / github.com / anthropic / mcp and the public registration of vulnerability in MITRE: https: / / cve.mitre.org / cgi-bin / cvename.cgi? name = CVE-2025-6514.

Who's at risk is a practical question: any organization that integrates IA agents with access to internal systems and that depends on MCP servers to delegate actions is potentially affected. This includes development teams that deploy agents in pipelines, support teams that use assistants to operate on tickets and data, and cloud architectures that expose APIs that agents should invoke. Also at risk are supply chains that rely on third-party components (e.g. proxies or utilities such as mcp-remote) without integrity and update controls.

The real consequences that can be derived are varied and of practical gravity: from leaks of internal documentation and API secrets to malicious actions carried out with stolen NHIs (erasing of records, scalating of privileges, lateral cloud movement). In addition, the autonomous nature of the agents makes the time between commitment and damage very short, and the evidence of an abuse is dispersed between logs of different systems if there is no centralized traceability.

We must distinguish: the facts described above are confirmed by the technical specification of MCP and by reported public incidents; the frequency statements (for example, that flat text storage is "routine") are estimates based on audits and practices observed in rapid deployment of IA projects; and there is still uncertainty about the aggregate scope of the problem at the level of all organizations that have deployed MCP internally (there is not yet a public global inventory).

Against this background, the specific measures that security teams and developers should implement immediately are clear and applicable:

1) Remove secrets in flat text and centralize them in a managed vault. Move keys and tokens out of configuration files and environment variables to a secret manager with access control and access log. If a commercial solution with masking and verification by confirmation is sought, there are tools in the market that implement these ideas; for example, Keeper Secrets Manager offers use flows for agents and display controls with confirmation: https: / / www.keepersecurity.com / secrets-manager /.

2) Use short-term and automatic rotation credentials. Avoid static keys. Generating ephemeral tokens with automatic expiration and renewal significantly reduces the exposure window if there is a leak.

(3) Forging the principle of minor privilege. Assign to each agent only the minimum permissions necessary for your task and check by automatic revisions and rules that these permissions are not increased for development comfort. For definitions and access control guides, reference should be made to access control and least privileged good practice guides: https: / / csrc.nist.gov / Glossary / term / least _ privilege.

4) Keep a human in the loop for sensitive operations. Actions such as revealing an unmasked secret, deleting production data or running changes in critical infrastructure must require authenticated human confirmation and registration of approval.

5) Instrumentar logging, audit and detection specific to agents. To record each request of the agent, the NHI identity used and the resource concerned; to enable abnormal behaviour alerts (for example, out-of-time requests or unusual resources) and to keep sufficient logs for forensic audit.

6) Inventory and control all MCP servers and client proxies. Act against "Shadow MCP": scan repositories, development machines and cloud environments to locate instances, apply patches and revoke tokens if vulnerable software is detected (e.g. update or remove mcp-remote affected by CVE-2025-6514).

7) Protect against prompt injection and adverse content. Filter, heal and verify the origin of the content that agents process; maintain validation mechanisms and, where necessary, limit the access of agents to non-reliable external documents.

In summary, MCP introduces an operational layer that facilitates the usefulness of IA agents but also concentrates risk: the MCP server often ends as a custodian of credentials capable of acting in critical systems. Defenses are not exotic: centralize secrets, use ephemeral credentials, apply least privilege, add human reviews at critical points, audit actions and maintain a complete inventory are technical and organizational steps that must now be applied to mitigate a risk that may otherwise go unnoticed until the damage is irreversible.