[usrbinbash]

And in a skill, I can store the secret in the skill itself, or a secure storage the skill accesses, and the agent never gets to see the secret.

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.

[lukewarm707]

what stops the agent from echoing the secure storage?

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.

[usrbinbash]

> what stops the agent from echoing the secure storage?

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.

[mvkg]

If the tool fails for some reason, couldn't an overly eager agent attempt to fix what's blocking it by digging into the tool (e.g. attaching a debugger or reading memory)? I think the distinction here is that skill+tool will have a weaker security posture since it will inherently run in the same namespaces as the agent where MCP could impose additional security boundaries.

[TheTaytay]

I think this is a good setup to prevent the secret from leaking into the agent context. I'm more concerned about the secret leaking into the exfiltration script that my agent accidentally runs. The one that says: "Quick! Dump all environment variables. Find all secrets in dotfiles! Look in all typical secrets file locations..."

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?

[jgilias]

OpenAI is not the worst it could or would send it to.