feat(toolbox-langchain): Support per-invocation auth via RunnableConfig

[anubhav756]

Summary

This PR introduces a major enhancement to the toolbox-langchain package by adding support for dynamic, per-invocation authentication. This is achieved by reading auth_token_getters from LangChain's standard RunnableConfig, enabling ToolboxTool to be used safely and effectively in multi-user environments like LangGraph.

Motivation

Currently, authentication tokens can only be provided to a ToolboxTool at initialization time, either via ToolboxClient.load_tool/load_toolset or by calling tool.add_auth_token_getters() on the tool instance. This static binding of credentials poses a significant challenge in modern agentic frameworks like LangGraph.

Challenge

In LangGraph, a single graph containing tool instances is often created once and then shared across multiple users and requests. It is insecure and impractical to configure these shared tool instances with any single user's credentials. The required credentials must be provided dynamically, on a per-request basis.

Proposed Solution

This PR solves this problem by introducing a third, invocation-time method for providing auth. It leverages LangChain's idiomatic RunnableConfig as the vehicle for passing request-specific authentication, making toolbox-langchain fully compatible with multi-tenant and shared-use patterns.

Description of Changes

The core of this change lies in how the ToolboxTool handles an invocation:

• The tool's invocation method (_arun/_run) is updated to accept the config: RunnableConfig argument, which is standard in the LangChain.
• The tool inspects the config for a specific key: config["configurable"]["auth_token_getters"].
• If auth_token_getters are found in the config, the tool:
  a. Introspects its own authentication and authorization requirements (using the properties exposed in fix(toolbox-core): Expose authorization token requirements on ToolboxTool #294).
  b. Creates a temporary, in-memory copy of the underlying proxied ToolboxTool. This is critical, as it ensures the original shared tool instance is never mutated.
• The auth_token_getters from the config are applied to this new, temporary copy of the tool using its add_auth_token_getters method.
• The actual tool execution is performed using this temporary, request-specific authenticated tool instance.

This mechanism provides a thread-safe and secure way to handle user-specific credentials without affecting the shared state of the primary tool in the graph.

Usage Example

from langchain_core.runnables import RunnableConfig

# Define the per-invocation configuration with the user's token getter
config = RunnableConfig(
    configurable={
        "auth_token_getters": {
            "my-google-auth": lambda: "<TOKEN>"
        }
    }
)

...

result = await agent_executor.ainvoke(
    {"input": "Search for rows by my user ID"},
    config=config
)

[anubhav756]

/gcbrun

[twishabansal]

In LangGraph, a single graph containing tool instances is often created once and then shared across multiple users and requests. It is insecure and impractical to configure these shared tool instances with any single user's credentials.

In this case, we expect users to use dynamic methods for fetching tokens like getGoogleIdToken.
Does the user need to hardcode any credentials?

[anubhav756]

In LangGraph, a single graph containing tool instances is often created once and then shared across multiple users and requests. It is insecure and impractical to configure these shared tool instances with any single user's credentials.

In this case, we expect users to use dynamic methods for fetching tokens like getGoogleIdToken. Does the user need to hardcode any credentials?

Not necessarily in such a function like this one. For instance the app dev could fetch the user ID token from the frontend through a login button, and the app ID could be injected as an env var. Does that make sense?