Sure, if I want my agents to use naked curl on the CLI, they need to know secrets. But that's not how I build my tools.
Sure, if I want my agents to use naked curl on the CLI, they need to know secrets. But that's not how I build my tools.
what i see is that you give it a pass manager, it thinks, "oh, this doesn't work. let me read the password" and of course it sends it off to openai.
The fact that it doesn't see it and cannot access it.
Here is how this works, highly simplified:
def tool_for_privileged_stuff(context:comesfromagent):
creds = _access_secret_storage(framework.config.storagelocation)
response = do_privileged_stuff(context.whatagentneeds, creds)
return response # the agent will get this, which is a string
This, in a much more complex form, runs in my framework. The agent gets told that this tool exists. It gets told that it can do privileged work for it. It gets told how `context` needs to be shaped. (when I say "it gets told", I mean the tool describes itself to the agent, I don't have to write this manually ofc.)The agent never accesses the secrets storage. The tool does. The tool then uses the secret to do whataever privileged work needs doing. The secret never leaves the tool, and is never communicated back to the agent. The agent also doesn't need, or indeed can give the tool a secret to use.
And the "privileged work" the tool CAN invoke, does not include talking to the secrets storage on behalf of the agent.
All the info, and indeed the ability to talk to the secrets storage, belongs to the framework the tool runs in. The agent cannot access it.
Your agent process has access to those secrets, and its subprocesses have access to those secrets. The agent doesn't have to be convinced to read those files. Whatever malicious script it manages to be convinced to run could easily access them, right?