Skip to main content
Glama

Detectar secretos embebidos en texto plano (credenciales hardcodeadas)

detect_hardcoded_secrets_risk

Analiza código fuente o un archivo de configuración (incluido el bloque "env" de un servidor en la config de mcpServers, o un archivo ".env") en busca de credenciales escritas tal cual en texto plano, en vez de venir de una variable de entorno o un gestor de secretos: (1) cadenas con el formato reconocible de una credencial real (llaves de OpenAI, AWS, GitHub, Slack, Google, o el encabezado de una llave privada PEM); (2) una variable o llave de configuración con nombre de credencial (api_key, secret, token, password…) con un valor literal en el propio código; (3) una línea al estilo ".env" que asigna un valor literal a una variable de entorno cuyo nombre indica una credencial; y (4) una variable de entorno con un valor de reserva ("fallback") hardcodeado — si la variable de entorno no está definida, el código sigue funcionando igual con el secreto embebido, lo que anula el propósito de usar una variable de entorno. Motivada por un reporte real de Hush Security (septiembre 2026) que escaneó ~82.000 archivos de configuración MCP públicos en GitHub: el 12% de los espacios de credenciales tenía un secreto literal embebido, el 53% de esos con acceso a nivel de toda la organización, y el 55% sin ningún formato de token conocido. También documentado por Trend Micro (48% de 19.402 servidores MCP con almacenamiento inseguro de secretos) y catalogado como MCP01 en el OWASP MCP Top 10. Reconoce placeholders/ejemplos comunes ("your-api-key-here", "changeme", la llave de ejemplo oficial de AWS) para no marcarlos como riesgo. Es un análisis estático por patrones de texto (no ejecuta el código ni revisa el historial de git) — mismo enfoque que detect_ssrf_risk, detect_path_traversal_risk, detect_command_injection_risk, detect_sql_injection_risk y detect_token_passthrough_risk. Requiere una llave de acceso válida (usos gratis o créditos) — ver POST /crear-llave.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "codigo": "<codigo>"
    },
    "name": "detect_hardcoded_secrets_risk"
  }
}

Input Schema

NameRequiredDescriptionDefault
codigoYesEl código fuente o archivo de configuración a revisar, en texto plano.
lenguajeNoSolo informativo (ej. "javascript", "python", "json", "env") — la detección ya cubre varios formatos a la vez, este campo no cambia el resultado.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations supplied, the description carries the full burden and does substantial work: it discloses the static-pattern methodology, the negative scope (no execution, no git history), the placeholder whitelist, and the authentication/credits requirement. What it does not disclose is what the analysis returns (findings list? severity? locations?), which matters given there is no output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The opening sentence and the four-item enumeration are front-loaded and operational, but the middle passage on the Hush Security report (~82,000 files, 12%, 53%, 55%), Trend Micro's 48% of 19,402 servers, and OWASP MCP01 is motivation rather than usage guidance and does not help an agent call the tool correctly. The sibling-comparison sentence is useful; the statistics block could be compressed to a clause.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter, single-required-field scanner the input side is fully covered: what content is accepted, which formats are recognized, what is deliberately not flagged, and that the language field does not affect results. The remaining gap is the return value, absent both from the description and from any output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds real meaning: 'codigo' is not just source code but also an mcpServers 'env' block or a .env file, which expands what an agent knows it can pass. It also implicitly confirms that 'lenguaje' is cosmetic, matching the schema's own statement.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and target (analyze source code or config file for literal credentials) and enumerates the four concrete detection patterns: recognizable token formats, credential-named keys with literal values, .env-style assignment lines, and hardcoded fallback values. This is far more specific than a restatement of the name, and the resource class (MCP server config env blocks, .env files) is pinned down.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear context for when the tool applies: static pattern analysis of source/config text, not code execution or git-history review, with explicit note that common placeholders ('your-api-key-here', 'changeme', AWS example key) are whitelisted so they are not flagged. It also states the access-key prerequisite. What is missing is an explicit exclusion clause saying which cases belong to a sibling tool instead of this one.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources