You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.)
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: