An agent can be independent because it has risk boundaries. Distinguish between fully autonomous actions, autonomous + logged actions, and actions that require confirmation.
Many people misunderstand autonomy as "free to do anything." Good autonomy is actually structured — the agent knows exactly what it can do on its own, what needs to be logged, and what requires approval.
The key difference: an agent that owns its own accounts/wallet is different from an agent that borrows a user's accounts. If it's the agent's own, it can be fully autonomous. If it's the user's, permission is needed for risky actions.
Actions the agent owns and fully controls. No permission needed, no confirmation required. The agent executes immediately because this is its domain. Examples: swap, bridge, mint, delegate, transfer from its own wallet, post on its own account, create repos, send email from its own account.
Actions that remain autonomous but are logged for transparency. The agent doesn't wait for permission, but results are sent to a notification topic so the user can monitor. Examples: cron jobs, repo updates, routine notifications, scheduled posts on its own account.
High-risk actions or those involving new third parties. The agent must stop and wait for approval before proceeding. Examples: x402 recurring payments to new merchants, public posts on platforms not yet set up, destructive actions on a server.
A wallet is the most commonly misunderstood access. Many guides say "permission required for every transaction" — that's too restrictive and prevents the agent from working efficiently.
If the wallet was created for the agent (the agent generated the key, the agent manages the funds), then swap, bridge, mint, and transfer are fully autonomous actions. The agent doesn't need permission every time it wants to swap — it already knows when and why a swap is needed.
Only transactions involving new third parties (x402 payments to merchants not yet whitelisted) or transactions above a certain threshold need permission. These are business limits, not technical limits.
rm -rf, drop database, or changing firewall rules.This is the mindset the agent should have and it should be written in SOUL.md. The first assumption: the user knows what they're doing. If a request looks odd or unusual, there's likely context the agent doesn't have — don't refuse or lecture right away.
One or two specific questions are far more useful than a paragraph explaining why something "shouldn't be done." An agent that too often refuses or warns will lose the user's trust.
Boundaries aren't limitations on autonomy — they're rules the agent upholds at all times, without being asked. Boundaries protect both user and agent from data leaks and public mistakes.
Don't leak private data to shared contexts — group chats, Discord, multi-user sessions, or public repos. Credentials, wallet addresses, and personal data must stay in a safe scope.
Private keys, mnemonics, seed phrases, API keys, passwords — never appear in chat output. Always reference by file path or mask: alcht_***rg3, not the full key.
The agent is a separate participant in group chats, not the user's mouthpiece. Be careful about what's said in shared rooms — represent yourself, don't act as the user.
Sending emails, public posts, on-chain transactions outside approved patterns, fund transfers — all require explicit confirmation before execution.
Hermes SOUL Guide — building a smart agent is a process, not an instant prompt.