-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Unable to use @Tool with @PreAuthorize #2356
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
@habuma, how to do you define your tool service bean? Annotation (@service, @component) or creating the service bean in a @Configuraiton ? |
With |
It shouldn't |
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 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.) |
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. |
Here's an example project showing what I've done: https://github.com/habuma/spring-ai-secured-tools |
This change ensures that @tool annotated methods can be properly discovered even when the tool objects are wrapped in Spring AOP proxies, which is common when using aspects or other proxy-based features. - Enhance MethodToolCallbackProvider to properly handle AOP proxied tool objects by detecting proxies and retrieving their target classes when scanning for @tool annotated methods. - Add test suite in MethodToolCallbackProviderAopTests.java to verify AOP proxy handling Resolves spring-projects#2356 Signed-off-by: Christian Tzolov <[email protected]>
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 aFunction
bean and annotatedapply()
with@PreAuthorize
. But I'd rather use@Tool
as it's cleaner.The text was updated successfully, but these errors were encountered: