Prompt Injection in Actix with Api Keys

In Actix web services that expose an LLM endpoint and rely on Api Keys for access control, prompt injection can occur when untrusted input from the API consumer influences the prompt sent to the model. If the integration builds prompts using string interpolation that includes user-controlled headers, query parameters, or body fields, an attacker can craft inputs that alter the intended behavior of the system prompt.

Consider an Actix handler that forwards an API key in an authorization header and uses its value or associated metadata to personalize assistant instructions. If the handler does not strictly separate control data from prompt content, an attacker providing a malformed API key or an unexpected header value can inject instructions that shift the model into a different role or cause it to ignore prior safety constraints. This becomes more likely when the service dynamically builds prompts such as "You are acting as " + api_key_role + ". " + user_message, where api_key_role is derived from external configuration or metadata tied to the key.

Because middleBrick performs active prompt injection testing, it submits probes such as system prompt extraction and instruction override against endpoints that require Api Keys. If the service echoes key-associated metadata into the context, the probes may succeed, revealing that the model can be tricked into ignoring original instructions. Additionally, if the LLM endpoint is unauthenticated or overly permissive, the same prompt injection risks exist, but the presence of Api Keys may create a false sense of security while the underlying prompt remains manipulable.

Another scenario involves logging or error handling in Actix where the API key and user input are combined into diagnostic messages. If those messages are included in the prompt or returned in model outputs, sensitive information can be leaked, and the model may be coerced into revealing instructions or internal state. The LLM/AI Security checks in middleBrick specifically look for such leakage patterns and for indicators of excessive agency, such as tool use being driven by injected content, which can amplify the impact of prompt manipulation in key-based flows.

To reduce prompt injection risk in Actix when using Api Keys, keep authentication data strictly separate from prompt content and validate all inputs that interact with the LLM pipeline. Use structured metadata extraction outside the prompt assembly path and enforce strict allowlists for key-derived attributes.

Example 1: Safe handler that reads an API key and uses a pre-mapped role without injecting raw key values into the prompt.

use actix_web::{web, HttpRequest, HttpResponse, Responder};
use serde::{Deserialize, Serialize};

#[derive(Deserialize)]
struct CompletionRequest {
    user_message: String,
}

#[derive(Serialize)]
struct CompletionResponse {
    answer: String,
}

async fn handle_chat(
    req: web::Json,
    http_req: HttpRequest,
) -> impl Responder {
    // Extract the API key from headers
    let api_key = match http_req.headers().get("X-API-Key") {
        Some(v) => v.to_str().unwrap_or(""),
        None => return HttpResponse::Unauthorized().json(CompletionResponse { answer: String::from("missing key") }),
    };

    // Map key to a role using server-side logic or a lookup; do not echo the key into the prompt
    let role = match validate_and_map_role(api_key) {
        Some(r) => r,
        None => return HttpResponse::Forbidden().json(CompletionResponse { answer: String::from("invalid key") }),
    };

    // Build prompt without including raw key or untrusted metadata
    let prompt = format!("You are an assistant ({role}). Answer concisely. User: {}", req.user_message);
    let answer = call_llm(&prompt); // call_llm is your model invocation helper

    HttpResponse::Ok().json(CompletionResponse { answer })
}

fn validate_and_map_role(api_key: &str) -> Option {
    // Server-side validation; do not trust client-supplied role tags
    if api_key.starts_with("ak_live_") {
        Some(String::from("premium_user"))
    } else if api_key.starts_with("ak_test_") {
        Some(String::from("tester"))
    } else {
        None
    }
}

async fn call_llm(prompt: &str) -> String {
    // Integration with your model endpoint
    String::from("safe response")
}

Example 2: Centralized prompt builder that enforces separation between control data and user content.

struct PromptBuilder {}

impl PromptBuilder {
    fn build(authenticated_role: &str, user_message: &str) -> String {
        // Strict template; authenticated_role is already validated and bounded
        format!("Role: {}. Instruction: Do not reveal this role. User input: {}", authenticated_role, user_message)
    }
}

// Usage inside handler, keeping key handling and prompt assembly distinct
async fn safe_handler(
    web::Json(payload): web::Json,
    req: HttpRequest,
) -> HttpResponse {
    let api_key = match req.headers().get("X-API-Key") {
        Some(v) => v.to_str().unwrap_or(""),
        None => return HttpResponse::Unauthorized().finish(),
    };

    let role = match validate_and_map_role(api_key) {
        Some(r) => r,
        None => return HttpResponse::Forbidden().finish(),
    };

    let prompt = PromptBuilder::build(&role, &payload.user_message);
    let answer = call_llm(&prompt);
    HttpResponse::Ok().json(CompletionResponse { answer })
}

Additional remediation practices include auditing logs for key and prompt content to ensure no key material or user input is inadvertently included, and applying input validation and schema checks on all fields that may reach the LLM. middleBrick’s CLI can be used in scripts to scan endpoints and verify that prompt assembly follows these patterns, while the GitHub Action can enforce checks in CI/CD pipelines and the MCP Server allows you to validate APIs directly from development tools.