I would like to pass static-parameters such as the {{current_user.id}} in the tool functions to run the functions in the users-context.
We can't rely on ids, email-addresses parameters that are filled out by the agents itsself, since its unsecure. Its possible to convice the agent that you are somebody else and let it do request on a different users behalf.
Hello @Tobias_Sell,
Is your goal to pass dynamic variables(since it changes based on who the user is) such as current_user as params to a custom Agent tool? If you can share any screenshots into the current set up you have, that could help me better understand where you are at and what you are looking to build.
Given that custom tools are workflows which are executed in a sandboxed environment, I am not certain that the specific object of current_user can be accessed and used but I can do some testing into that as needed.
Are you asking if you can give an agent instructions to pull data of another user via a tool that the agent has (such as a SQL request to a users table) and then have the Agent use data in acquired from the user table to use other tools?
Nope, you can't access these variables yet. Thats why you are forced to let the agent fill out critical information (such as user_id)... with its LLM capacitys.
Since we know that prompt incjections can bring the LLM to filling out other values that expected, this is not a secure way.
For example. I have a function that can access the users database entries in our retool installation. In the agents instructions i have provided the user id. I have made a tool "accessFiles" that needs the usere_id as parameter (since i cant access the user_id in the workflow).
You can convice the agent that you are a different user and that you have a different id and that will make the agent access files that he was not allowed to and reveal information of one user to an other.
Currently, the only way to get user context into a function call is to rely on the agent itself to pass it correctly. While we can use {{ current_user }} in the system prompt, there’s no guarantee the agent will consistently pass the right parameters to downstream functions. This creates a real risk - an agent could hallucinate values and unintentionally (or incorrectly) access data it shouldn’t; or like @Tobias_Sell said, a malicious user could overwrite these values in the prompt.
In my use case, multiple entities share the same app, but data access must be restricted at the entity level. Within Retool Apps, I can safely use {{ current_user.metadata.entityId }} to enforce row-level filtering in queries. I need the same kind of guarantee for Agents: when a user calls an Agent, it should only ever be able to retrieve data scoped to their entity.
Another example is when the Agent calls an external API requires a user-level access token.
Ideally, there should be a secondary, secure channel for passing context properties into agent tool calls - values that are injected directly from current_user or app context, not generated or guessed by the agent itself.
Without this, the only safe workaround I see is to create a separate Agent for each entity and dynamically select the correct one in my app - a solution that doesn’t scale well.
Thats why i am requesting this feature
Hey @Tobias_Sell, @TobiasOhlsson - current_user is available inside custom tools. This isn't passed in via the LLM, but is provided by the system in a secure way at runtime.
This means you could build tools that safely operate on data while being aware of who the user is and what they should have access to (by inspecting their permission groups, for example).
I've attached a screenshot below - does this solve your issues?
Awesome. I did not realize that this is possible, because the editor keeps showing that current user is not defined.
But can confirm it is working!
Glad to hear that it is working!
We could definitely explain this better on the docs as I could guess that other users are going to be taking Ai security concerns ver seriously and are wondering how that current_user data is being passed along.
As Kent shared, the process occurs in a safe way as it does when current_user is used in any non-AI workflows. Let us know if that works for you too @Tobias_Sell and let us know if you have any more requests or questions!
Hi, works on my side as well. But it would still be nice to securly provide data for the workflow. My workarround is now, that i save tool related background-information in the database attached to the user-id, and read it in the tools.
Hi @Tobias_Sell,
Thank you for sharing the work around!
Yes we will keep working on getting this set up so that data can be securely provided to the workflow 
