It was a quiet week for Spring releases: no new Boot, Framework, AI or Modulith versions shipped between September 28 and October 10, ahead of the portfolio's first monthly "Patch Thursday" on October 22. The two items below are tooling and integration news for Spring developers.
IntelliJ IDEA's Spring Debugger Can Unlock Endpoints Behind Spring Security
A JetBrains tutorial walks through a Spring Debugger feature (IntelliJ IDEA Ultimate 2026.2+) aimed at a familiar annoyance: you set a breakpoint in a controller, send a request, and Spring Security returns a 403 or a login redirect before the breakpoint is reached. During a debug session, the IDE now shows a security inlay on each endpoint listing the roles or authorities the running application requires. Those rules come from the live SecurityFilterChain in the JVM, not from parsing source files. Rules written as a custom AuthorizationManager show up as an unknown lock with a link to the relevant config.
From the inlay you can choose "simple unlock", which treats the request as authenticated with exactly the roles the endpoint needs, or "unlock with custom authorities", where you enter a username and role list (for example admin with ROLE_ADMIN and ROLE_MANAGER) to exercise authority-dependent logic. Under the hood, the debugger places a hidden, non-suspending breakpoint on Spring Security's AuthorizationFilter and injects a TestingAuthenticationToken into the SecurityContext for unlocked requests only. Nothing is written into the application, and the unlock lasts until you re-lock, the debug session ends or the app restarts.
There are important limits. CSRF protection still applies, so state-changing requests still need a valid token. Only authorizeHttpRequests and the AuthorizationManager API are supported; legacy authorizeRequests, WebFlux and method-security annotations have no inlay, although @PreAuthorize checks downstream will see the injected authorities. @AuthenticationPrincipal currently resolves to null (IDEA-389767). The article also warns that any client that can reach the app is treated as authenticated for an unlocked URI and method, so re-lock when finished, especially on remote JVMs. JetBrains plans an MCP tool and skill for lock/unlock in 2026.3 so AI agents can drive it.
Read more — JetBrains
MCP Toolbox Java SDK 1.0 Brings Governed Database Tools to Spring Boot Agents
Google has released v1.0 of the MCP Toolbox Java SDK (com.google.cloud.mcp:mcp-toolbox-sdk-java:1.0.0), the stable Java client for MCP Toolbox for Databases. The model is that database operations are defined as named tools on a Toolbox server, and Java agents discover and invoke those tools, so the LLM never gets a raw database connection. Google's walkthrough builds the agent on Spring Boot with LangChain4j against AlloyDB for PostgreSQL with pgvector.
The 1.0 API adds a transport abstraction (HttpMcpTransport) for swapping HTTP clients or tuning connection pools, and decoupled authentication via CredentialsProvider. Credentials are resolved asynchronously on every request so tokens can refresh, and Google OIDC via Application Default Credentials is built in, meaning a Spring Boot app on Cloud Run inherits its identity with no hard-coded keys. Tool definitions now support default parameters to shrink prompts, and server-bound values such as tenant_id are pruned from the definitions the LLM sees, a simple but effective guard against an agent querying another tenant's data.
Other additions include MCP protocol version selection and session tracking, custom headers for correlation IDs and proxies, and a runtime warning when credentials would be sent over plaintext HTTP. Loading and invoking a tool is a CompletableFuture chain: mcpClient.loadTool("query-schedules").thenCompose(tool -> tool.execute(params)). For Spring teams building agents over relational data, this offers a governed alternative to giving the model a SQL tool, with access rules living on the Toolbox server.
Read more — Google Cloud Blog
Links & Sources
You May Also Enjoy
