feat: Add #[IsGrantedTool] for tool access control

[valtzu]

Resolves #360

[chr-hertel]

Can we use the Symfony one instead? it's basically the same code besides Tool as a subject - but I can't spot where you need that

[valtzu]

It would mean requiring symfony/security-http instead of just symfony/security-core, and that pulls in a lot of dependencies, f.e. symfony/http-foundation and symfony/http-kernel.

Of course since it's an optional dependency, maybe that's ok? And in practice I think most people use this library with the bundle & likely have full Symfony setup anyway so 🤷

---

it's basically the same code besides Tool as a subject

it's about what arguments the Closure gets. If we use the built-in IsGranted, then should we provide Request object to the callback like the typehint says?

Also it could be misleading that an expression in a single #[IsGranted] attribute would get different parameters for evaluation depending on the context:

• symfony http request: ['request' => ...,' 'args' => ...]
• php-llm tool call: ['tool' => ...,' 'args' => ...]

---

Do you have a take on this @OskarStark ?

[chr-hertel]

alright, yea, reusing the "original" one is not a great idea - you're right.
it's just confusing since I compared it to the other one and the controller is also not part of the attribute payload, but if you're sure the tool itself should be part of the payload - fair enough. 👍

[chr-hertel]

well, the controller is part of the request's attributes

[valtzu]

I guess more analogous to Request would be a ToolCall instance, but for some reason I didn't include it in the ToolCallArgumentsResolved event 🤔

EDIT: the reason was that the event already contains the denormalized arguments & tool metadata, and I didn't see a point of including a structure that includes normalized args in addition

[OskarStark]

I would also not reuse it and maybe use a more tailored name like IsGrantedTool ?

[valtzu]

A slight security concern: this library does not depend on symfony/event-dispatcher – so we cannot really create an event dispatcher & attach the listener by default in case no dispatcher provided. This means that someone could be using the #[IsGrantedTool] attribute and think it's doing access control, while in reality it's not doing anything without the event dispatcher that has the listener attached.

[OskarStark]

If the class is not available we can throw an exception, no? "For using.... EventDispatcher is needed, Try running composer require ...." like Symfony is doing it

[valtzu]

I tried adding the check directly to the top of the IsGrantedTool file, but then realized it does not get executed before $attr->newInstance() call in the listener.

Can't think of any place except the toolbox itself where you could check it, and if you do, then it kinda defeats the purpose of using events to decouple logic/domains

[chr-hertel]

We have the same issue with the #[AsEventListener] which only works in context of Symfony's DIC, right?

I feel like this feature is relying quite a lot on the infrastructure the Symfony framework is providing and therefore should go to the bundle instead. WDYT?

[valtzu]

should go to the bundle

Sounds good to me