Skip to content

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

Closed
habuma opened this issue Mar 2, 2025 · 6 comments · Fixed by #2472
Closed

Unable to use @Tool with @PreAuthorize #2356

habuma opened this issue Mar 2, 2025 · 6 comments · Fixed by #2472
Assignees
Milestone

Comments

@habuma
Copy link
Member

habuma commented Mar 2, 2025

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.

@tzolov
Copy link
Contributor

tzolov commented Mar 2, 2025

@habuma, how to do you define your tool service bean? Annotation (@service, @component) or creating the service bean in a @Configuraiton ?

@tzolov tzolov added this to the 1.0.0-M7 milestone Mar 2, 2025
@habuma
Copy link
Member Author

habuma commented Mar 2, 2025

With @Component. Would it make a difference if I did it another way?

@tzolov
Copy link
Contributor

tzolov commented Mar 3, 2025

It shouldn't

@habuma
Copy link
Member Author

habuma commented Mar 3, 2025

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.)

@habuma
Copy link
Member Author

habuma commented Mar 7, 2025

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.

@tzolov tzolov self-assigned this Mar 10, 2025
@habuma
Copy link
Member Author

habuma commented Mar 12, 2025

Here's an example project showing what I've done: https://github.com/habuma/spring-ai-secured-tools

leijendary pushed a commit to leijendary/spring-ai that referenced this issue Mar 28, 2025
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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants