Llm Data Leakage in Echo Go with Dynamodb

When building Go services with the Echo framework that use Amazon DynamoDB as a persistence layer, developers can inadvertently expose sensitive data through LLM-related endpoints or integrations. LLM Data Leakage occurs when application logic that retrieves or stores data in DynamoDB feeds into LLM endpoints—such as for summarization, chat completions, or embeddings—without proper controls. In Echo Go, routes like /api/chat or /api/summary may pull user records from a DynamoDB table and forward raw or minimally processed content to an LLM service.

The risk arises at the intersection of three elements: the Echo HTTP framework’s flexible routing and middleware chaining, DynamoDB’s behavior of returning rich item structures (including nested maps and lists), and the application’s handling of LLM inputs/outputs. For example, an Echo handler might scan a DynamoDB item and directly include attributes such as user_id, email, or notes into a prompt. If the LLM endpoint is unauthenticated or weakly guarded, an attacker could use prompt injection techniques to coax the system into returning other users’ DynamoDB records through crafted inputs. MiddleBrick’s LLM/AI Security checks specifically flag this scenario by testing for system prompt leakage and output exposure of PII or API keys that may reside in DynamoDB items.

Echo Go applications that use the AWS SDK for Go to interact with DynamoDB may also propagate sensitive context across middleware, such as logging or tracing, which is then passed into LLM calls. Without strict input validation and output scanning, data that should remain in DynamoDB—such as personally identifiable information or credential-like strings—can appear in LLM responses. This violates data minimization and confidentiality expectations. The scanner’s checks for output PII and system prompt leakage are designed to detect these cross-component exposures, highlighting how an insecure Echo route combined with a DynamoDB backend can become an inadvertent data exfiltration path.

Additionally, configuration issues in how the application serializes or deserializes DynamoDB attribute values can introduce further risk. If numeric or binary fields are mishandled when constructing prompts, malformed inputs may trigger unexpected behavior in LLM tooling. Furthermore, insufficient rate limiting or missing authentication on Echo endpoints that invoke LLMs can enable cost exploitation or repeated jailbreak probing. MiddleBrick’s active prompt injection tests—covering system prompt extraction, instruction override, DAN jailbreak, data exfiltration, and cost exploitation—are particularly effective at surfacing these weaknesses in an Echo Go and DynamoDB stack.

To mitigate LLM Data Leakage in Echo Go with DynamoDB, apply strict data handling and validation at the boundaries between the database, the HTTP layer, and any LLM calls. Begin by ensuring that DynamoDB queries retrieve only the attributes required for the immediate business purpose. Use projection expressions in the AWS SDK for Go to limit returned fields, and avoid scanning entire items before constructing prompts.

Example of a safe DynamoDB query in Go using the SDK, retrieving only non-sensitive fields:

params := &dynamodb.GetItemInput{
    TableName: aws.String("users"),
    Key: map[string]types.AttributeValue{
        "user_id": &types.AttributeValueMemberS{Value: userID},
    },
    ProjectionExpression: aws.String("display_name,locale"), // explicitly limit fields
}
result, err := svc.GetItem(context.TODO(), params)
if err != nil {
    log.Printf("failed to get item: %v", err)
    return echo.ErrInternalServerError
}
if result.Item == nil {
    return echo.ErrNotFound
}
displayName := *result.Item["display_name"].(*types.AttributeValueMemberS).Value
locale := *result.Item["locale"].(*types.AttributeValueMemberS).Value

Next, sanitize and validate all data flowing into LLM prompts. In Echo handlers, construct prompts from vetted fields and enforce strict type assertions on DynamoDB attribute values. Do not directly include raw item maps in prompts.

Example of building a prompt safely in an Echo handler:

func handleChat(c echo.Context) error {
    userID := c.Param("user_id")
    var req struct {
        Message string `json:"message" validate:"required,max=500"`
    }
    if err := c.Bind(&req); err != nil {
        return echo.NewHTTPError(http.StatusBadRequest, "invalid request")
    }
    if err := c.Validate(req); err != nil {
        return echo.NewHTTPError(http.StatusBadRequest, "validation failed")
    }

    // Fetch only safe, non-sensitive fields from DynamoDB
    item, err := getUserPublicProfile(c.Request().Context(), userID)
    if err != nil {
        return echo.NewHTTPError(http.StatusInternalServerError, "unable to load profile")
    }

    // Build prompt from controlled strings, not raw DynamoDB item
    prompt := fmt.Sprintf("User message: %s\nProfile context: %s", req.Message, item.DisplayName)
    // Pass prompt to LLM endpoint with appropriate safety checks
    response, err := callLLM(prompt)
    if err != nil {
        return echo.NewHTTPError(http.StatusInternalServerError, "LLM error")
    }
    return c.JSON(response)
}

func getUserPublicProfile(ctx context.Context, userID string) (*UserPublic, error) {
    params := &dynamodb.GetItemInput{
        TableName: aws.String("users"),
        Key: map[string]types.AttributeValue{
            "user_id": &types.AttributeValueMemberS{Value: userID},
        },
        ProjectionExpression: aws.String("display_name,locale,country"),
    }
    out, err := svc.GetItem(ctx, params)
    if err != nil {
        return nil, err
    }
    if out.Item == nil {
        return nil, fmt.Errorf("not found")
    }
    return &UserPublic{
        DisplayName: *out.Item["display_name"].(*types.AttributeValueMemberS).Value,
        Locale:      *out.Item["locale"].(*types.AttributeValueMemberS).Value,
        Country:     *out.Item["country"].(*types.AttributeValueMemberS).Value,
    }, nil
}

Apply additional layers of protection by implementing input validation on all user-controlled data before it reaches DynamoDB, and enforce strong authentication and authorization on Echo routes that invoke LLM services. Use middleware to verify scopes or roles, and ensure that LLM endpoints are not unintentionally exposed without authentication. Regularly review scan results from tools like MiddleBrick to identify prompt injection risks, output PII, and missing validation in your API surface.