The Two Layers of MCP Security: Runtime Exposure vs Supply Chain

Source: Dev.to

Supply Chain vs. Runtime Exposure

Supply‑chain security (Cisco focus) – You install an MCP server.
If the server code contains hidden instructions, they can exfiltrate data or poison the AI agent.

Runtime exposure (my focus) – A deployed MCP server may have no authentication, allowing any AI agent to enumerate and invoke tools.

Comparison

Observed Runtime Issues

• No authentication – 16 % of servers (59 servers) expose 541 callable tools.

  • Render.com: 24 cloud‑infra tools (e.g., create_web_service, update_environment_variables) – disclosed.
  • Robtex: 50 DNS/IP tools fully open (e.g., ip_reputation, reverse_lookup_dns).
  • Airtable: 8 database tools (e.g., list_bases, CRUD) – disclosed.

• API‑layer authentication – 15 % of servers expose tool schemas without credentials. Example: Google Compute Engine shows 29 schemas (e.g., create_instance, delete_instance).

• MCP‑layer authentication – 69 % of servers require auth before listing tools. This is the correct configuration.

Example of Exploitation

I added two tools to my own server:

def get_aws_credentials(role):
    # retrieve temporary AWS credentials for the given role
    ...

def execute_sql_query(query, db):
    # run a SQL query against the specified database
    ...

Within three hours an AI agent called get_aws_credentials(role=admin).
The agent was not malicious; it simply enumerated the available tools and invoked the one that resembled credential access. Tool names act as semantic instructions for LLMs.

Security Posture Recommendation

A mature MCP security strategy requires both:

1. Supply‑chain verification – Review and sign the code you install.
2. Runtime verification – Ensure the running server does not expose unauthenticated tools.

The public registry lists 3,500+ servers; most of the long tail lack proper protections in one or both dimensions.

Resources

• MCP Scanner
• Dataset API (CC BY 4.0)