Was just trying out a mashup of Spring Security and Tools. Specifically, I have a bean with a couple of @Tool-annotated methods and it works great. But then I annotated one of those methods with @PreAuthorize so that it could only be successfully invoked if the requesting security context has a certain role. Once I do that, it ends up not being invoked as a tool at all, even if the security context has that role. In short, it seems like putting @PreAuthorize on the method negates the @Tool annotation. When both are used together, the tools never make it into the request to the LLM.
What does work, although clumsily, is that I can create two tools classes. One with the actual implementations and whose methods are annotated with @PreAuthorize and another one with @Tool annotated methods that delegates to the other. But then I have to create this weird wrapper class to make it work.
Another option that works is to not use @Tool and instead declare a Function bean and annotated apply() with @PreAuthorize. But I'd rather use @Tool as it's cleaner.
Comment From: tzolov
@habuma, how to do you define your tool service bean? Annotation (@Service, @Component) or creating the service bean in a @Configuraiton ?
Comment From: habuma
With @Component. Would it make a difference if I did it another way?
Comment From: tzolov
It shouldn't
Comment From: habuma
Side-note (and perhaps this needs to be a separate issue): Ideally, it would be best if tools that the current security context is prohibited from invoking would simply not be added to the prompt at all. At prompt-time, a developer could (I suppose) sift through all available tools and make those decisions on whether to add them in a call to tools() (although that would be clumsy and especially difficult for classes that have several @Tool-annotated methods, each of which may have its own @PreAuthorize expression.)
Even more ideally, the framework would somehow make those decisions at request/prompt-creation time. E.g., a developer adds all the tools that could be needed, but Spring AI consults with Spring Security and keeps unauthorized tools out of the prompt under the covers. (I'm not sure how to do this...would need to think on it some. Just saying it would be very helpful.)
Comment From: habuma
Side note: I've found that if a tool throws any exception...including a security exception...then the tool will be invoked again a few times over. How many times it is re-invoked varies, but typically 2-5 times before it gives up. I've not dug enough to know if it's Spring AI's retry that's causing it, the LLM asking for the tool to be reinvoked in hopes it will work better the next time, or a combination of both. But because it varies, I suspect the LLM has some part to play in the retry.
All the more reason to prevent tools from being added to the prompt if permissions won't allow it to succeed (#2385). That way, the LLM will never even attempt to invoke the tool.