How to Prevent AI Agents from Reading Credentials Through MCP

How credential exposure happens through MCP

An agent does not need to be asked for a secret. It needs a tool that can reach one and an input that steers it there. Five mechanisms account for most exposure.

File read tools are the most direct. A file tool that accepts a raw path can read anything the server process can reach, including home directories, SSH private keys and cloud credential files. Shell or command tools reach the same files plus environment variables, and OWASP classes agent-built commands from untrusted input as a top MCP risk (MCP05). Path traversal and symlinks are a variant of the first two: a path that appears to sit inside an allowed directory can resolve outside it if it is not normalized before it is checked.

The fifth mechanism is the return path. Credentials, file contents and environment variables can be passed as tool arguments without any awareness of data classification, and secrets can persist in model memory, protocol logs and debug traces (OWASP MCP01). Once a secret is in tool output or context, it can reach an external model provider or be echoed into later calls.

The OWASP Q3 2026 exploit roundup describes the Deadbugz campaign, which shows why one-time approval is not enough. A malicious MCP server behaved normally for its first three tool calls, then changed its tool metadata to direct the connected agent toward SSH keys, AWS credentials, shell history and Kubernetes configuration, while hiding the activity from the operator. The server did not need to read the files itself. The agent did, because its instructions changed after approval.

Layer 1: Harden the configuration

Start with what the agent can call at all. Configuration is the cheapest control and removes the most risk, but it is static. It reflects what you anticipated when you wrote it.

Prefer allowlists to denylists. A denylist of .env and .ssh paths blocks known locations and misses everything you did not list, so use it as a backstop to explicit directory scoping rather than the primary control. Resolve symlinks and normalize paths before comparing them to the allowed roots. In coding assistants, add explicit deny rules for credential reads and for network commands such as curl and wget, and disable any permission-bypass mode. The rule syntax is product-specific, so confirm it against the assistant's own documentation.

• Remove shell execution from the MCP tool surface unless the task requires it.
• Scope file tools to named project directories, with path normalization and symlink resolution before the check.
• Deny credential locations by default: .env files, SSH directories and cloud credential stores.
• Give each MCP server its own scoped credentials, never shared across servers, and use stdio for local communication.
• Keep sensitive servers (payment, auth, PII) separate from general-purpose ones.
• Require re-approval when tool definitions change, review new servers like any software dependency, and disable automatic server discovery.

Layer 2: Isolate the agent and broker credentials

Assume configuration will have gaps and limit what is reachable when it does. Run coding agents in dev containers, restricted shells, VMs or ephemeral cloud workspaces. Do not run them with a developer's full SSH keys and cloud tokens, and do not expose production or organization-level secrets from the development environment. Where an agent needs access to a system, issue an ephemeral, task-scoped credential instead of letting it inherit the developer's account.

Combine filesystem and network restrictions, because they stop different steps. In the AgentBound research scenario, network isolation blocked transmission of a key that had been read, but the key was still read. Filesystem restriction prevented the read entirely. Access and transmission are separate stages, and each needs its own control.

The limits are practical. A sandbox protects only what sits outside it, so a credential mounted into the workspace is still readable. Short-lived credentials reduce how long a leaked secret is useful, but they do not stop it entering model context. Both layers shrink the impact of a bad call. Neither decides whether a given call should happen.

Layer 3: Enforce policy on each tool call and response

Tool inputs originate from model output, which can be shaped by malicious context, so they must be treated as untrusted. That means enforcement cannot rely on prompt instructions. It has to sit in the path and evaluate each call before it executes and each response before it returns to the model.

Four decisions cover most cases. Allow calls that match policy. Block calls whose resolved target is a credential store, or whose arguments carry secret material. Redact secret patterns in tool output so a legitimate read does not place a key or token in context. Escalate sensitive calls to a human, and bind the approval to the specific action and arguments so it cannot be reused for a different call.

Be clear about the limits. Pattern-based redaction misses formats it does not recognize. Path rules depend on resolving the real target, not the string the agent supplied. Policy is only as good as its classification of sensitive resources. This is why runtime enforcement sits on top of the first two layers and does not replace them.

Where Trussed fits

Trussed provides the runtime layer described above. It enforces policy in the execution path across models, agents, tools, MCP servers and coding assistants, at the level of individual interactions and tool calls: allow, redact, block, rate limit, or escalate for human approval. Enforcement happens at runtime, not through review after the fact.

That enforcement generates audit-ready evidence, mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST, so a regulated enterprise can show what its AI was allowed to do and what it did. Trussed can be self-managed in the customer cloud, with configurable retention and data residency. It has run in continuous production in a regulated enterprise for 18+ months, with 99.95% uptime on live production traffic.

Trussed does not replace configuration hardening, isolation or short-lived credentials. Those reduce what is reachable. Policy enforcement decides, at each call, whether a reachable resource should be touched.