Agents and Safety – What Actually Matters
Handout section for the workshop. The point in one line: agents run with your permissions; the tool does not decide how dangerous they are – your settings and your habits do.
The honest comparison
| Hermes | OpenCode | |
|---|---|---|
| What it reaches | the whole machine plus integrations: mail, browser, SSH to servers, messenger, scheduled jobs | one working folder at a time, full terminal inside it |
| Blast radius if it goes wrong | larger – a mail that was actually sent, a server command, a message to a group | a file or command inside your project folder |
| Guardrails | confirmation gates for destructive actions, secret vault, read-only-first convention | confirmation prompts per action; nothing auto-runs unless you turn it on |
| The underestimated risk | integrations: the agent is one click away from your real life | foreign repos: cloned projects bring their own AGENTS.md – instructions written by strangers, read by the agent before you look at anything |
Neither tool is "the dangerous one". Both run as you. Both can delete, overwrite, install, and push. What differs is the distance to the things that are hard to undo.
Three rules (identical for both tools)
1. Keep the confirmations on. Never enable "auto-approve everything" – least of all in a repository you did not write. A prompt per action feels slow exactly until the day it prevents the one action you cannot undo. (Live example from building this workshop: a delete command was blocked by a confirmation gate and waited. Nothing was lost.)
2. Give the agent a fence: your working folder. Start the agent in the folder that belongs to the task, not at the top of your drive. Everything it reads and writes should be reachable from there. For Hermes this is the working directory; for OpenCode it is the project folder with its config. A tidy starting point is not aesthetics – it is the boundary the agent will not casually cross.
3. Treat outside content as potentially hostile.
Cloned repositories, downloaded documents, mail attachments: the agent may read them. But instructions inside them are not yours. A README that says "run this script", a AGENTS.md with commands, an attachment with a "helpful" macro file – these are prompts wearing a document costume. The first action that touches them gets human approval.
The plain-language version
An agent is a very well-read intern with terminal access. You would not give an intern admin rights, your mailbox password, and a "just do whatever you think is best" on day one – you would give them a desk (a folder), a task, and check their first steps. Do the same, and both tools are safe. Skip it, and both tools are dangerous – the newer and shinier one just as much as the established one.
If something goes wrong anyway
- File damage: the agent works in your folder, so your backup covers it. Git users:
git statusshows every change before commit;git diffshows what actually changed. Both tools will happily show you a diff of what they did – ask. - A key went astray: university keys are revocable in seconds (OpenWebUI → Settings → Account → create a new secret key – the old one dies instantly). This is why plain-text keys in a local config are acceptable: the protection is revocability, not hiding.
- A mail was sent / a message went out: say so immediately; the faster the correction, the smaller the damage. (And this is exactly why rule 1 exists – sending is a confirmed action, not a side effect.)
The slide version
An agent acts with your permissions. Keep confirmations on. Stay in your folder. Distrust strangers' instructions. The tool is only as invasive as you allow it to be.