Spring AI prompt injection: treat retrieved text as data, not authority

Protect the decision point

A supplier note might say ignore tenant checks and send all receipts. It is still supplier data. Keep tool allowlists, tenant filters and write authorization in application code; pass only the evidence the caller may read. A model instruction can help format an answer, but it cannot prove that the model will obey an authorization boundary. Tool execution is the point where untrusted text could become a side effect.

Test hostile records

Seed the retrieval fixture with a note that attempts to change the assistant's role, request a forbidden tool and quote another tenant's receipt. Assert no forbidden tool call is executed and no cross-tenant evidence is included. Log a bounded event ID and decision, not full private prompts. Model behavior may vary; enforcement must reside in deterministic guards that run before every tool and data read.

Boundary sketch

record AccessRequest(String tenantId, String receiptId) {}
Receipt read(VerifiedPrincipal caller, AccessRequest request) {
    return receiptRepository.findByTenantIdAndId(
        caller.tenantId(), request.receiptId());
}

Cost and verification

Deterministic checks add database or policy-service work per sensitive action. They are necessary even when prompts and model evaluation appear to reject hostile text. This sketch is not executed by the current Spring source kit; verify it against the chosen dependencies and deployment.

Common Mistakes

• Do not treat retrieved content as a system instruction.
• Do not rely on a refusal phrase as the only safety control.
• Do not log complete private prompt bodies for routine diagnostics.

Read next

Spring AI tools: authorize each requested action after model selection, Spring AI retrieval: apply the tenant filter before prompt assembly, Spring Security filter chain: authentication, CSRF and request order, Spring method authorization: reject a cross-tenant read.