Prompt Injection in Actix with Jwt Tokens

When an Actix web service uses JWT tokens for authorization and also exposes an endpoint that forwards user-controlled input to an LLM, the combination can enable prompt injection. A JWT typically carries claims such as sub, role, or scopes in its payload, and servers often parse and trust those claims to make authorization decisions. If the application then includes information derived from the JWT (for example, the user role or permissions) in the prompt sent to an LLM, an attacker who can influence the request or token can manipulate the effective system or user prompt.

Consider an Actix endpoint that accepts an Authorization bearer token, validates its signature, extracts claims, and builds an LLM request that includes the user role to tailor behavior. An attacker who can influence the token’s payload (e.g., via a weak iss/aud validation, token confusion, or a misconfigured public key) can change the role claim to administrator. If the server embeds that role directly into the prompt, the LLM may treat the injected role as authoritative, overriding intended instructions. This is a form of prompt injection because the attacker’s influence propagates into the LLM prompt, potentially causing the model to reveal system instructions, change behavior, or perform unintended actions.

In a black-box scan, middleBrick’s LLM/AI Security checks detect this risk by submitting probes that include manipulated JWT claims and observing whether the LLM response reflects the injected instructions. For example, a probe might modify the role claim to admin and check whether the output changes to reveal elevated privileges or system prompts. Because JWTs are often used for identity, an unchecked trust in the token’s content can turn identity-derived data into a vector for prompt injection, especially when that data is passed into the LLM context without strict sanitization and separation.

Another scenario involves unauthenticated LLM endpoints where the server incorrectly derives prompts from JWT-related metadata present in the request, such as scopes or custom headers. Even without a valid signature, an attacker can supply crafted headers that influence the prompt. middleBrick’s unauthenticated LLM endpoint detection and active prompt injection probes (system prompt extraction, instruction override, DAN jailbreak, data exfiltration, cost exploitation) are designed to surface these risks by attempting to leak instructions or force unwanted behavior through manipulated inputs that may include token-derived fields.

Because middleBrick scans the unauthenticated attack surface and runs checks in parallel, it can identify whether prompt injection is possible via manipulated JWT-derived inputs without requiring credentials. The scanner does not fix or block; it reports findings with severity and remediation guidance, helping teams understand how trust boundaries between identity and LLM prompting can lead to injection.

Remediation focuses on strict validation of JWTs, minimizing the data forwarded to the LLM, and ensuring that LLM prompts are constructed from a trusted, non-user-influenced context. Below are concrete Actix patterns that reduce the risk of prompt injection via JWT tokens.

1. Validate and parse the JWT strictly, and do not use claims directly in prompts. Verify the signature, issuer, audience, and required claims. Use a dedicated JWT library and keep validation logic separate from prompt construction.

use actix_web::{web, HttpResponse, Result};
use jsonwebtoken::{decode, Algorithm, DecodingKey, Validation, TokenData};
use serde::{Deserialize, Serialize};

#[derive(Debug, Serialize, Deserialize)]
struct Claims {
    sub: String,
    role: String,
    exp: usize,
    iss: String,
    aud: String,
}

async fn validate_jwt(token: &str) -> Result, jsonwebtoken::errors::Error> {
    let decoding_key = DecodingKey::from_rsa_pem(include_bytes!("public_key.pem"))?;
    let mut validation = Validation::new(Algorithm::RS256);
    validation.set_audience(&["my-api-audience"]);
    validation.set_issuer(&["trusted-issuer"]);
    validation.required_spec_claims = true;
    decode::(
        token,
        &decoding_key,
        &validation,
    )
}

async fn handle_request(auth: web::Header<actix_web::http::header::Authorization>) -> Result {
    let token = match auth.into_inner().to_str() {
        Ok(t) => t.trim_start_matches("Bearer "),
        Err(_) => return Ok(HttpResponse::Unauthorized().finish()),
    };

    let data = match validate_jwt(token).await {
        Ok(d) => d,
        Err(_) => return Ok(HttpResponse::Unauthorized().finish()),
    };

    // Use only verified, minimal claims for audit/logging, not for LLM prompts
    let user_id = data.claims.sub;
    let _role = data.claims.role; // Do not embed directly into LLM prompts

    // Build a safe, static system prompt; do not include user claims
    let system_prompt = "You are a helpful assistant.";
    let user_message = format!("User ID: {}", user_id);

    // Call LLM with trusted system prompt and user-controlled message only
    // llm::chat(&system_prompt, &user_message).await

    Ok(HttpResponse::Ok().body("Request processed"))
}

2. Use a strict allowlist for claims and avoid passing role- or permission-derived values into the LLM. If the LLM needs context, provide it from a server-side configuration rather than from the token.

3. Enforce token binding and scope checks before any LLM invocation. Ensure the token is intended for this audience and issuer, and that it has the necessary scopes without overprivileged roles being used to shape prompts.

4. Consider isolating identity handling from AI request building by using separate layers or services: validate and store identity in request extensions, then construct prompts from non-identity context. This reduces accidental leakage of attacker-influenced data into prompts.

These practices align with the principle that identity tokens should control access, not LLM behavior. By keeping prompts deterministic and free of user-influenced fields, you mitigate prompt injection risks even when JWTs are present.