https://linen.dev logo
Powered by
Is the Tool Router aware of OAuth scope limitation...
# 🖥│support-forum
f
How does the tool router decide to only use tools which the used Connected Account has enough OAuth scopes for? Example: * A Connected Account to Gmail was created for user X exist with scopes to read email, but not not send email. * User X asks our agent to send an email from their Gmail account. * Our agent uses Composio tool router with 
composio.create(user_id="<user_X_id>", connected_accounts={"gmail": "<connected_account_id_for_gmail_and_user_x>"})
which means Composio tool router will decide which tool(s) to call on behalf of user X. * Will Composio tool router be aware that the 
<connected_account_id_for_gmail_and_user_x
was not created with enough scopes to use the send email tool, or how does the tool router work here?
a
Also curious about the above, came in to check for an answer about the same thing after I saw Tool Router was now recommended over MCP Configs.
a
Hey guys, we don't currently support this, but it's definitely a good feature to add. I've noted this as a feature request and will bring it up in our next sprint. For now, I'd recommend limiting the tools when creating a session - this way, the agent will know which tools aren't available when it tries to execute. Additionally, you can retrieve the scopes required for a specific tool using this SDK snippet:
Copy code
import { Composio, CustomAuthParamsSchema } from "@composio/core";

const composio = new Composio({
  apiKey: "ak_.."
});

const res = await composio.tools.getRawComposioToolBySlug("GMAIL_SEND_EMAIL")
console.log(res.scopes);
f
@Abhishek thanks for the response. I see unfortunately issues then: 1) Since Composio's selling point for Tool Router is to outsource the responsibility for choosing tool I think this should be seen as a high severity bug since agents using Composio can assume breaking tool calls unless: * The Connected Accounts are created with all scopes needed for all potential tool calls, which is the opposite of the principle of least privilege. * The agent using Composio Tool Router has a work around trying to avoid the agent from calling out of scope tools, which defeats the purpose of Tool Router simplicity. So unfortunately we will have to roll back our staging implementation of Tool Router until this is fixed. 2) Using your example to list the scopes Composio say are required for using the GMAIL_SEND_EMAIL tool I get the following scopes:
Copy code
- https://mail.google.com/
- https://www.googleapis.com/auth/gmail.modify
- https://www.googleapis.com/auth/gmail.compose
- https://www.googleapis.com/auth/gmail.send
This is way more than required to send an email. Google's docs [says this](https://developers.google.com/workspace/gmail/api/auth/scopes) on the 
https://mail.google.com/
scope: > Full access to the account's mailboxes, including permanent deletion of threads and messages This scope should only be requested if your application needs to immediately and permanently delete threads and messages, bypassing Trash; all other actions can be performed with less permissive scopes. I understand that the job to curate the list of required scopes for each tool (in your case - many) is a lot of work, but at the same time your users need to be able to trust Tool Router not rejecting calling tools like GMAIL_SEND_EMAIL due to lack of full Gmail access
d
hi can you share a bit on how you are using toolrouter? currently agent will fail in execute tool, do you want it to stop after search? we've seen customers define guardrails what can the agent do via system prompt or manual tool filters. scope-based tool filtering is on the roadmap.
also are you free sometime for a call to discuss this?
f
@dhawal I'm available for a call now if you are
We have an AI agent for product managers One user journey for us is: 1. Outside of an agent, our customers can connect integrations where we use Composio under the hood, meaning we have connected accounts for them. 2. The customer sets up agents (agent definitions) that automates tasks for them. 3. An agent definition must have a limitied set of Composio tools it can use; the intersection of 1) which services (ie Jira, Linear, Github, ...) can the agent do tasks in and 2) which services has the customer integrated with In order to do this I see the following options: * Without Composio's tool router: we would have pre-defined Composio MCP Configs (with an explicit list of tools) that each agent can access. Then runtime, the agent filters those tools to only include the services that are the customer has connected to. * Pros: Control over which tools can be called by a specific agent * Cons: * Lots of manual work to define lists of tools for agents * We would have to become experts at how Composio tools work in order to give our agent a good tool calling strategy * With Composio's tool router: we would have pre-defined auth configs (ie Jira, Linear, Github, ...) that each agent can call tools for. When running the specialized agent, we would create a tool router with 
composio.create(user_id="<customer_id>", connected_accounts={"<toolkit>": "<connected_account_id>", ...})
OR @dhawal could we use 
composio.tool_router.create(user_id="<customer_id", toolkits=['<toolkit>, ...], tools={<toolkit>: "<whitelisted_tools>"}, ...)
* Pros: * Whitelisting auth configs is minimal work for us * Outsourcing the tool calling strategy decreases work for us * Cons: * If Composio's tool router calls tools that the user hasn't given access to it's a dealbreaker for us * If we have to whitelist tools, it's better than the con above, but still a lot of work for us I hope this clarifies things for you
a
Hey, thanks for sharing. Lets hop on quick call to discuss? Here's my Calendly: https://calendly.com/d/ct89-dqr-b2m/15-minute-meeting grab a time that works for you!
f
Thanks, booked a call on Monday đź‘Ť
2 Views
PreviousNext
Powered by