03 / access

Accounts and credentials let the agent
actually get work done.

An independent agent needs real access. But every access must have behavior attached. Without behavior, the agent doesn't know whether the access is its own, the user's, or a shared account.

The difference between an agent that feels "real" and one that feels like a regular chatbot is access. An agent with its own accounts — its own wallet, email, GitHub — can take real action, not just suggest it.

Four things to document per access

Account status

State whether the account belongs to the agent, the user, the business, or is shared. This determines the autonomy level: an agent-owned account can be used fully autonomously, a user-owned account needs permission for risky actions.

Credential path

Document the credential location such as ~/.agent/credentials/github-pat.env, not the token itself. Credentials leaked in SOUL.md can end up in session logs, context compression, and other platforms.

Capabilities

Describe exactly what's allowed: read, write, send, deploy, transfer, create repo, post tweet. Don't just write "full access" — the agent needs to know precisely what it can do.

Limits

Define actions that require confirmation. For wallets: payments to new merchants not yet whitelisted. For GitHub: delete repo and force push. For social media: posts that affect reputation.

Credential management: the right pattern

Every credential should follow the same pattern: user provides credential → agent saves it to a secure file → agent writes behavior in SOUL.md → agent references by path, not contents.

Storing credentials

Store all credentials in one structured location, for example ~/.agent/credentials/. Use clear file names: github-pat.env, discord-token.json, wallet-keys.env. Never write credentials directly in SOUL.md or any file that enters context.

Referencing in SOUL.md

In SOUL.md, only write the path: "GitHub PAT is stored at ~/.agent/credentials/github-pat.env". The agent will read the file when needed, without credentials ever appearing in chat or logs.

Benar
GitHub credentials are stored at ~/.agent/credentials/github-pat.env. Read this file when GitHub access is needed. Never paste the token contents into chat or logs.
Salah
GitHub token: ghp_xx...xxxx. Keep it in SOUL.md so I don't forget.

Example: Wallet & Crypto

A wallet is one of the most important accesses. A good prompt explains ownership status (agent-owned vs user-owned), autonomy level, and specific limits.

An agent-owned wallet should be treated differently from a user-owned wallet. If the wallet truly belongs to the agent (the agent generated it, the agent manages it), then the agent has full control — swap, bridge, mint, delegate, transfer — without needing permission for every transaction.

Only these need permission: x402 recurring payments to merchants not yet whitelisted, and transactions to new contracts that haven't been reviewed.

Benar
This wallet belongs to the agent, full control. May swap, bridge, mint, and transfer autonomously. Credentials at ~/.agent/credentials/wallet.env. For x402 recurring payments, check the whitelist first — if the merchant isn't listed, confirmation is required.
Salah
This is the wallet's private key. Never make a transfer without permission. Only allowed to check balance.

Example: GitHub

An agent-owned GitHub PAT lets the agent create repos, branches, issues, PRs, and commits autonomously. This is very useful for development workflows.

Benar
This PAT is the agent's GitHub access. Credentials at ~/.agent/credentials/github-pat.env. May create repos, branches, issues, PRs, and commits autonomously. Must ask permission to delete repos and force push to the main branch.
Salah
This is a GitHub token. Use it when needed.

Example: Email

Agent email is very useful for automation: service registration, receiving notifications, and autonomous communication.

Benar
This email belongs to the agent agent@myproject.com, may be used for service registration and autonomous notifications. IMAP/SMTP credentials at ~/.agent/credentials/email.env. Ask permission before sending important emails to external parties that haven't been contacted before.
Salah
You may access my email.

Example: X / Twitter

X/Twitter can be a very powerful tool for an agent. But it's also risky because of its public impact.

Benar
This is the agent's account @AgentName, full control. Cookie credentials at ~/.agent/credentials/x-cookies.json. May post, reply, like, retweet, follow, and search autonomously. Must ask permission to delete tweets with high engagement and to change the profile bio.
Salah
This is a Twitter account. Post something if you have an idea.
The key to good access setup: write behavior IMMEDIATELY after providing credentials. Don't let the agent have access without rules — not even for one session. Written behavior prevents future mistakes.

Hermes SOUL Guide — building a smart agent is a process, not an instant prompt.