Llm Data Leakage in Echo Go with Api Keys

When an Echo Go application exposes an endpoint that returns sensitive data and also integrates with LLM tooling, the combination can unintentionally leak API keys and other secrets through model outputs. This occurs when the application embeds credentials in prompts, logs, or structured responses that an LLM endpoint can observe or regurgitate. For example, if a handler constructs a prompt by directly concatenating an API key read from configuration or environment variables, that key may appear verbatim in the request to an LLM endpoint. If the LLM response is returned to users or downstream services without output scanning, the key can be exfiltrated in replies, tool calls, or function arguments.

Echo Go services that stream structured JSON or use tool-calling patterns increase risk because LLMs may learn to echo or reproduce values seen during training or runtime. Real attack patterns include prompt injection attempts that trick the model into repeating sensitive context, and data exfiltration probes where the model is asked to "remember" and regurgitate embedded secrets. Inadequate output scanning means API keys, tokens, or internal identifiers can surface in chat completions, function_call objects, or LangChain agent traces. This violates principles of least privilege and secret isolation, and can lead to compromised credentials across integrated services.

middleBrick detects this class of risk under LLM/AI Security by scanning for system prompt leakage patterns (27 regexes covering ChatML, Llama 2, Mistral, and Alpaca formats), active prompt injection probes, and output scanning for API keys and PII. For Echo Go endpoints that serve LLM responses, unauthenticated LLM endpoint detection identifies publicly reachable completions that may expose sensitive context. Because the scan correlates OpenAPI/Swagger specs (with full $ref resolution) against runtime behavior, it can highlight mismatches where documentation claims no secrets are exposed, but runtime findings show embedded credentials in model interactions.

Remediation focuses on preventing API keys from entering contexts visible to LLMs and ensuring outputs are sanitized before exposure. In Echo Go, store keys exclusively in secure environment variables or a secrets manager, and access them only in server-side logic that never reaches the LLM layer. Avoid constructing prompts, headers, or JSON fields that include raw keys; instead pass opaque references or scoped tokens that the downstream service can validate without exposing the original credential.

Use structured logging that redacts sensitive fields, and apply output scanning on any LLM response before it leaves your service. Below are two Go code examples: one demonstrating a vulnerable pattern and one showing a hardened approach.

// Vulnerable: API key embedded in prompt sent to LLM endpoint
package main

import (
	"fmt"
	"net/http"
	"os"

	"github.com/labstack/echo/v4"
)

func handler(c echo.Context) error {
	apiKey := os.Getenv("EXTERNAL_API_KEY")
	prompt := fmt.Sprintf("Use this key to authenticate: %s", apiKey)
	// Assume callToLLM sends prompt to an unauthenticated LLM endpoint
	resp, err := callToLLM(prompt)
	if err != nil {
		return c.String(http.StatusInternalServerError, err.Error())
	}
	return c.JSON(http.StatusOK, resp)
}

func callToLLM(prompt string) (map[string]interface{}, error) {
	// Placeholder for actual HTTP request to an LLM endpoint
	return map[string]interface{}{
		"choices": []interface{}{
			map[string]interface{}{
				"message": map[string]interface{}{
					"content": prompt,
				},
			},
		},
	}, nil
}

// Hardened: keep keys server-side, sanitize LLM output
package main

import (
	"encoding/json"
	"fmt"
	"net/http"
	"os"
	"strings"

	"github.com/labstack/echo/v4"
)

// sanitize removes potential secrets from model output before returning to user
func sanitize(text string) string {
	// Simple redaction example; extend with regexes for API key patterns
	re := regexp.MustCompile(`\b[A-Za-z0-9/+=]{40}\b`) // example API key length
	return re.ReplaceAllString(text, "[REDACTED]")
}

func handler(c echo.Context) error {
	apiKey := os.Getenv("EXTERNAL_API_KEY")
	// Use key only in server-to-server call, never in LLM prompt
	data, err := fetchExternalData(apiKey)
	if err != nil {
		return c.String(http.StatusInternalServerError, err.Error())
	}

	// Build a safe prompt without embedding the key
	prompt := fmt.Sprintf("Analyze this data: %s", data)
	resp, err := callToLLM(prompt)
	if err != nil {
		return c.String(http.StatusInternalServerError, err.Error())
	}

	// Extract content and sanitize before response
	content := resp["choices"].([]interface{})[0].(map[string]interface{})["message"].(map[string]interface{})["content"].(string)
	clean := sanitize(content)

	// Optionally log sanitized output for audit
	_ = clean
	return c.JSON(http.StatusOK, map[string]string{"result": clean})
}

func fetchExternalData(key string) (string, error) {
	// Server-side use of key; returns data without exposing the key
	return "sample dataset", nil
}

func callToLLM(prompt string) (map[string]interface{}, error) {
	// Placeholder for actual request
	return map[string]interface{}{
		"choices": []interface{}{
			map[string]interface{}{
				"message": map[string]interface{}{
					"content": prompt,
				},
			},
		},
	}, nil
}

These examples align with remediation guidance from middleBrick findings, which provide severity and remediation steps mapped to frameworks like OWASP API Top 10 and SOC 2. If you integrate middleBrick via the CLI (middlebrick scan <url>), GitHub Action, or MCP Server in your AI coding assistant, you can automate detection of such leakage patterns and enforce secure coding practices in Echo Go projects.