How to Security-Check an MCP Configuration: Secrets, Shell, Remote MCP, and Permissions

The configuration problems most likely to survive into production are often not JSON syntax errors. They are credential and permission boundaries that work well enough to be ignored: real credentials stored in config, an overly broad shell boundary, a remote MCP endpoint treated as an ordinary URL, authentication data copied into logs, or a read-only agent running with write privileges.

Static scanning is useful here, but the opposite failure mode is also common: treating every command, shell or env field as a critical vulnerability. Security findings need execution context.

1. Exposed credentials

The problem is not the name of an environment variable. The problem is a real secret value ending up in a file that can be committed, copied, logged or screenshotted.

A safer configuration stores only references or identifiers and injects the real value through a controlled runtime environment. Documentation, issues and screenshots should use redacted placeholders rather than production values.

MCP authorization guidance distinguishes HTTP and stdio transports. A local stdio process should not copy an HTTP OAuth flow; credentials should come from an appropriate local secure environment. Remote HTTP servers need explicit authorization boundaries such as protected-resource metadata, resource binding and appropriately scoped credentials rather than one long-lived credential copied into every client.

Before deployment, review whether the config is version-controlled, whether errors echo authentication fields, whether CI can copy credentials into public artifacts, and whether example config is likely to be pasted into a public repository.

2. Shell is not automatically a vulnerability

These are very different execution boundaries:

fixed executable + fixed working directory + constrained parameters

versus:

general command interpreter + model-controlled arguments + privileged identity

When a scanner finds bash, sh, powershell or another command execution surface, the next questions are more important than the keyword itself:

• Can user or model input reach command arguments?
• Is the working directory constrained?
• Are arbitrary filesystem, network or child-process actions possible?
• Does the process run with more privilege than the task needs?
• Do mutating operations require authorization or confirmation?
• Are commands and outputs copied into logs?

String matching can identify a review point. It cannot prove an arbitrary-command-execution vulnerability on its own.

3. A remote MCP endpoint is a trust boundary

Connecting to remote MCP is not the same as calling an ordinary content URL. The agent may receive Tools, Resources or Prompts from the server. Before trusting the connection, confirm:

1. The domain and documentation belong to the expected provider.
2. The endpoint uses HTTPS.
3. Authorization material is sent only to the intended resource.
4. Scopes are no broader than necessary.
5. Remote tool descriptions and returned content are treated as model input with appropriate validation.
6. Access can be revoked when the provider or connection changes.

Notion’s MCP security guidance similarly tells users to verify official endpoints and reminds them that connecting MCP can expose the connected user’s workspace permissions to the AI system using that connection. If the remote endpoint also needs protocol, catalog, and authorization preflight, continue with the read-only MCP Server preflight so configuration risk and protocol health stay separate.

4. Logging and retention are separate controls

A provider-level data control does not imply that your MCP client, agent memory, traces, application database and logs all have the same retention behavior.

Review these independently:

• authentication headers in logs;
• sensitive fields in tool arguments;
• full request bodies in error logging;
• trace retention;
• local caches, memory and vector-store cleanup.

This is the same distinction covered in OpenAI ZDR and Agent data boundaries: provider controls and end-to-end agent retention are not interchangeable claims.

Run a browser-local static check

The XBSTACK Agent Security Auditor is designed as a browser-local static scanner. Paste redacted MCP/Agent configuration or code, and it reviews signals around credentials, shell boundaries, remote MCP, permissions, retention, logging and execution limits.

A useful workflow is:

1. Redact real credentials before copying anything
2. Run the local scan
3. Use each finding to locate the exact field
4. Decide whether it is a real risk or an intentionally constrained configuration
5. Fix the boundary
6. Scan again and keep before/after evidence

The evidence-plus-review step matters. A fixed read-only script may legitimately be launched through a shell; the scanner should surface the boundary, but the presence of bash alone does not prove arbitrary command execution.

Pre-deployment checklist

[ ] No real credentials in repository/config examples
[ ] Remote MCP endpoint matches provider documentation
[ ] HTTP authorization resource and scope match the intended service
[ ] Shell/command parameter sources are controlled
[ ] Filesystem and network permissions are task-scoped
[ ] Mutating operations require business authorization or confirmation
[ ] Logs do not retain secrets
[ ] Trace/Memory/DB retention has an explicit policy
[ ] Third-party MCP/dependency provenance is known
[ ] Test and production credentials are separated

If several of these are unknown, fix the boundaries before adding more tools.

Bottom line

MCP configuration security is not “remove every command” and it is not “OAuth means safe.” The real questions are where credentials live, who can invoke what, under which execution identity, where data is retained, and who supplies remote capabilities.

Agent Security Auditor helps surface those configuration-level signals quickly and consistently. Production security still depends on code review, runtime permissions, server-side authorization, dependency governance and business-level tests.

Topic path / MCP

Continue from protocol details to production MCP governance

The MCP hub connects protocol fundamentals, transports, authentication, security, JSON-RPC debugging and production deployment without splitting the search intent across isolated guides.

Open MCP hub → Review the security checklist Subscribe