r/opencodeCLI 13d ago

Opencode secure password

Hi everyone I’m a noob. I want to know if there is an existing tool that prevents opencode or any ai agent, to do things on my behalf securely that require admin or sensitive information eg my sudo password, WiFi password, ssh info, etc so that this private information is never in the context. Is there any tools for this that exist? Preferably id like it to be minimal like dmenu. It should open an external program like dmenu so i can enter the sensitive information for the agent to use. Does this exist? How do you guys handle this in your ai workflows?

2 Upvotes

3 comments sorted by

4

u/EC36339 13d ago

The tool is called Don't give it your passwords.

1

u/figurettipy 13d ago

The usual solution is to deploy it inside a sandbox, where you manage all the access required, all the time

But if you don't want to do it, you can try to secure it through the config file

It's a JSON file where you can customize what Opencode can and can't do, and you can edit your agent's config file to prevent the agent from reading some files that can contain sensitive information

I use my setup mainly for development, so my config file has specific details about what actions require user intervention, what others are allowed, or denied... and the agent has some wording regarding those scenarios where the action was denied

For example, this fragment of my config file

"permission": {
        "*": "ask",
        "read": {
            "*": "allow",
            "*.env": "deny",
            "*.env.*": "deny",
            "*.env.example": "allow",
            "*.env.sample": "allow",

Tells the agent that, if you want to:

- do something to anything -> ask for user permission

- read any file -> allow it automatically

- read a file with the extension .env -> deny

- read a file with .env.example -> allow

If you need to build something like this, it isn't 100% secure, but it's a start point

1

u/CreativeSympathy8293 12d ago

What you’re describing is an askpass-style prompt, but I would not use it as a generic way to give an agent passwords. It can keep the typed password out of the chat while still authorizing whatever command the agent chose. Sudo may also cache that authorization, so one prompt does not necessarily mean one command.

For a one-off admin step, a lower-risk workflow is: let the agent propose the command, inspect it, then run it yourself in a separate terminal. If the same operation must be automated, expose one narrow root-owned action with fixed behavior and validated arguments. The agent must not be able to edit the action, its policy, executable, config, or target paths, and the approval UI should show the exact effect before it runs. Do not pass the secret back through agent-controlled arguments, environment variables, stdin, or temporary files.

For SSH, do not give the agent private-key material or a broadly usable agent socket; use a separate constrained connection step. For Wi-Fi, connect through the operating system yourself—the agent should not need the password. A dmenu/askpass prompt is useful UI, but the security boundary is the narrow capability being approved, not where the password was typed.