Description
At present, the safety and security documentation suggests using a tool to run as a user - ie in the tool, make an oauth call to authenticate, then query data with permissions consistent with the user role as opposed to the agent/service account role.
However, I believe this is impractical in most production scenarios. Before I call the tool, I need to securely know who the user is in order to look them up against oauth.
In most production scenarios, the user identity is contained in the http request - ie header, jwt cookie etc. While I can add application wide http middleware to get this information, at present there is no way for me to pass this onto some immutable key in a tool context.
I would like a way for me to take information from a request header and/or cookie and immutably set that into the state for a given agent run.
I could get round this by adding sessions service onto app.state and then in custom middleware putting this information in sessions for relevant routes.
That feels gnarly though and I think this use case is very important... In my opinion, it should be easy to make sure the agent runs only with the permissions of the caller as defined in the incoming http request.
I think the simplest way to solve this would be to pass through request headers and cookies to the invocation context.