Extracting credentials from headers for tool usage

[rohan-kavari]

I am invoking an Agent Engine–deployed agent using the Reasoning Engine query API:

POST https://${location}-aiplatform.googleapis.com/v1/projects/${projectId}/locations/${location}/reasoningEngines/${agentId}:query

Client-side request:

const res = await fetch(url, {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${accessToken}`,
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    class_method: method,
    input
  })
})

On the agent side, I want to access the same OAuth access token that was used by the caller, so that I can use it for downstream tool usage (for example, calling other Google APIs while preserving the caller’s identity and permissions).

Question

• Is the caller’s access token available inside the Agent Engine runtime?
• If yes, what is the supported way to extract it inside the reasoning engine or tool execution context?

Goal

Ensure downstream API calls made by tools execute with the caller’s authorization context, rather than a fixed service account.

Any guidance or examples would be appreciated.

---

[adk-bot]

Response from ADK Answering Agent (experimental, answer may be inaccurate)

TLDR: Directly accessing the caller's OAuth access token from the inbound request is not a supported feature in ADK. The recommended approach is to leverage ADK's built-in tool authentication mechanisms to manage credentials for downstream API calls in a secure and scalable way.

---

Hello! That's a great question about handling authentication and preserving user identity for tool calls.

For security and design reasons, the ADK framework does not directly expose the caller's inbound access token to the tool execution context. Instead, it provides a robust mechanism for tools to declare their own authentication requirements and manage credentials securely. This ensures that tools only have access to the specific permissions they need, rather than inheriting the broader permissions of the calling user.

The recommended way to handle this is to define the authentication needs within your tool. When the tool is called, the ADK runtime will determine if the necessary credentials are in the session state. If not, it will automatically trigger the authentication flow you've configured. [1, 4, 11]

You can use tool_context.request_credential(AUTH_CONFIG) within your tool to initiate this process. [4] The ADK framework then handles the user-facing authentication steps and securely stores the obtained credentials for subsequent tool calls within the session. [1]

This approach has several advantages:

• Security: It adheres to the principle of least privilege. Your tool gets a token specifically for the downstream API it needs to call, with only the necessary scopes.
• Scalability: It allows you to manage authentication for multiple tools and APIs in a consistent way.
• User Experience: ADK handles the complexities of the OAuth flow, prompting the user for consent only when needed.

For more detailed information and examples, you can refer to the documentation on tool authentication. [4, 11]

While this means you can't directly use the incoming token, this approach provides a more secure and flexible way to manage authorization for your tools.

[1] publicly accessible HTTPS URL of the document
[4] publicly accessible HTTPS URL of the document
[11] publicly accessible HTTPS URL of the document