spring-ai-security
Skill344 starsChanged 3 months agoMITView on GitHub
Use when threat-modeling or hardening a Spring AI RAG, chat, or tool-calling workflow against prompt injection, unauthorized actions, data exposure, or unbounded execution. Ordinary model-provider integration alone does not require this review.
In this repository77 other files it gives its agents.
- agent-qa-browser-regressionSkill
- ai-observabilitySkill
- api-versioningSkill
- configuration-propertiesSkill
- container-native-deploymentSkill
- domain-driven-designSkill
- event-driven-messagingSkill
- flyway-migrationsSkill
- hateoasSkill
- hexagonal-architectureSkill
- http-interface-clientsSkill
- idempotency-patternsSkill
- java-supply-chain-securitySkill
- layered-architectureSkill
- mcp-serverSkill
- multi-module-mavenSkill
- multi-tenancySkill
- null-safetySkill
- oauth2-resource-serverSkill
- openapi-firstSkill
- problem-details-rfc9457Skill
- production-observabilitySkill
- resilience-retrySkill
- rest-api-conventionsSkill
- security-audit-loggingSkill
- spring-ai-integrationSkill
- spring-batchSkill
- spring-boot-migrationSkill
- spring-cloud-gatewaySkill
- spring-data-jpaSkill
- spring-data-redisSkill
- spring-incident-responseSkill
- spring-modulithSkill
- spring-security-jwtSkill
- spring-security-reviewSkill
- testing-pyramidSkill
- transactional-patternsSkill
- webflux-reactive-patternsSkill
- agent-qa-browser-regressionSkill
- ai-observabilitySkill
- api-versioningSkill
- configuration-propertiesSkill
- container-native-deploymentSkill
- domain-driven-designSkill
- event-driven-messagingSkill
- flyway-migrationsSkill
- hateoasSkill
- hexagonal-architectureSkill
- http-interface-clientsSkill
- idempotency-patternsSkill
- java-supply-chain-securitySkill
- layered-architectureSkill
- mcp-serverSkill
- multi-module-mavenSkill
- multi-tenancySkill
- null-safetySkill
- oauth2-resource-serverSkill
- openapi-firstSkill
- problem-details-rfc9457Skill
- production-observabilitySkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 46
All invocation attempts consume it, including denied or malformed calls.
- Distinctive: line 59
Use the good scenario and the bad scenario to plan tests involving hostile retrieved text, cross-user conversation IDs, cross-tenant …
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Spring AI Security
Version boundary
Target Spring Boot 3 and the project's compatible Spring AI 1.x line. Preserve the repository's managed coordinates and provider choices. The Java 17 tool boundary here is deliberately independent of Spring AI APIs. Wire it into the selected version's tool mechanism and verify that adapter separately.
Establish the trust boundary
Map user input, uploaded documents, retrieved chunks, memory, tool output and rendered model responses. All can contain attacker-controlled content. A prompt instruction such as "ignore malicious text", a delimiter, classifier or keyword denylist is not an authorization boundary. Record what the model can read and which effects its tools can cause.
- Derive caller and tenant from verified server-side identity, not prompts, model arguments or an arbitrary client header. Scope retrieval in the storage query and recheck authorization before returning documents; output-only filtering is too late.
- Enforce the same ACLs during ingestion, vector retrieval, document lookup and cache/memory reuse. Bind conversation IDs to caller/tenant authorization; randomness alone is insufficient.
- Expose narrowly typed tools, not shell execution, raw SQL, arbitrary URLs or general admin APIs. Validate arguments and enforce permissions in application code immediately before effects.
- Require a trusted approval flow for sensitive writes: bind approval to actor, tenant, exact normalized action/arguments, expiry and one-time use. Reauthorize on execution. A model-supplied approved=true field or stale approval after argument changes is not consent.
- Bound tool calls, model iterations, response size, retrieval size, deadlines and per-user spend. Carry the same budget through retries and nested calls; a new tool instance must not reset a request's limit. Apply network/DB timeouts and cancellation independently of call counts.
- Restrict outbound destinations and data sent to providers. Do not send credentials or unnecessary private content. Treat returned HTML/Markdown/URLs as untrusted when rendering.
- Audit decisions and identifiers without recording full prompts, documents, tokens or secrets.
Tool example and verification
DocumentReadTool accepts only a document UUID. Its caller identity is server-supplied and immutable, permissions are checked in code, and a server-owned CallBudget is shared across every tool instance for that authenticated turn. All invocation attempts consume it, including denied or malformed calls. Do not create a new budget on retry or share a caller/tool singleton across users. Never expose constructors, caller identity or budgets as tool input. The reader must enforce tenant AND account access in its storage query. For summarizing a preselected upload, prefer no tool at all when a server-authorized document load is sufficient.
The example is read-only. It does not implement approval for writes, a Spring AI adapter, vector-store ACLs, model-output sanitization or network timeouts. Its result-size check runs after loading the body: also bound storage reads/streaming and total bytes in the adapter. The fixture tests identity scoping, invalid arguments, missing permission, exhausted budgets and oversized results without calling a model. It is not a measured prompt-injection detection benchmark.
Use the good scenario and the bad scenario to plan tests involving hostile retrieved text, cross-user conversation IDs, cross-tenant documents, repeated tool calls and legitimate text containing words such as "delete". Assert the unauthorized effect never occurs; model refusal text alone is not a pass.
Review output
List the trust boundaries, allowed effects, demonstrated controls and remaining gaps. Label each claim confirmed, suspected, or not verified; distinguish deterministic policy tests from provider/model evaluations. Preserve redacted evidence and test versions. Request approval before sending private fixtures to a model provider or testing live tools.
Gotchas
- Agent trusts a system prompt to enforce permissions - authorize every tool call in application code.
- Agent lets the model choose a tenant ID - derive scope from the authenticated server context.
- Agent resets budgets on retries - share the request budget and bound nested tool execution.
- Agent calls a filtered response proof of safety - assert that forbidden effects never happened.
Official sources
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

