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
@@ -186,6 +192,87 @@ result = tools[0].invoke({"name": "Alice", "age": 30})
186
192
This is useful for testing tools or when you need precise control over tool
187
193
execution outside of an agent framework.
188
194
195
+
## Client to Server Authentication
196
+
197
+
This section describes how to authenticate the ToolboxClient itself when
198
+
connecting to a Toolbox server instance that requires authentication. This is
199
+
crucial for securing your Toolbox server endpoint, especially when deployed on
200
+
platforms like Cloud Run, GKE, or any environment where unauthenticated access is restricted.
201
+
202
+
This client-to-server authentication ensures that the Toolbox server can verify the identity of the client making the request before any tool is loaded or called. It is different from [Authenticating Tools](#authenticating-tools), which deals with providing credentials for specific tools within an already connected Toolbox session.
203
+
204
+
### When is Client-to-Server Authentication Needed?
205
+
206
+
You'll need this type of authentication if your Toolbox server is configured to deny unauthenticated requests. For example:
207
+
208
+
- Your Toolbox server is deployed on Cloud Run and configured to "Require authentication."
209
+
- Your server is behind an Identity-Aware Proxy (IAP) or a similar authentication layer.
210
+
- You have custom authentication middleware on your self-hosted Toolbox server.
211
+
212
+
Without proper client authentication in these scenarios, attempts to connect or
213
+
make calls (like `load_tool`) will likely fail with `Unauthorized` errors.
214
+
215
+
### How it works
216
+
217
+
The `ToolboxClient` (and `ToolboxSyncClient`) allows you to specify functions (or coroutines for the async client) that dynamically generate HTTP headers for every request sent to the Toolbox server. The most common use case is to add an Authorization header with a bearer token (e.g., a Google ID token).
218
+
219
+
These header-generating functions are called just before each request, ensuring
220
+
that fresh credentials or header values can be used.
221
+
222
+
### Configuration
223
+
224
+
You can configure these dynamic headers in two ways:
1. **Configure Permissions**: [Grant](https://cloud.google.com/run/docs/securing/managing-access#service-add-principals) the `roles/run.invoker` IAM role on the Cloud
252
+
Run service to the principal. This could be your `user account email`or a
0 commit comments