Security guides

How to show terminal workflows publicly while hiding usernames, home folders, tokens, and machine-specific paths.

A practical guide to public website security sweep in a verified Hermes/Rocky workflow.

A practical guide to private portal security sweep in a verified Hermes/Rocky workflow.

A practical guide to secret redaction in a verified Hermes/Rocky workflow.

A practical guide to pii redaction in a verified Hermes/Rocky workflow.

A practical guide to approval modes in a verified Hermes/Rocky workflow.

A practical guide to safe handling of passwords in a verified Hermes/Rocky workflow.

How audit logs make Rocky workflows reviewable by recording important actions, approvals, sources, and verification evidence.

A practical guide to csp and security headers in a verified Hermes/Rocky workflow.

Design approval queues so Rocky can move fast without doing risky things silently.

How to decide which Rocky tools are safe for a workflow and where human approval is required before taking action.

Safely handling API keys, tokens, and provider credentials in Rocky systems.

How to keep HeyRocky public pages and private dashboards separated so visitors see only the right content and actions.

How to decide which Rocky and Hermes actions can run automatically and which should stop for explicit human approval.

Clear boundaries for unsafe, unsupported, ambiguous, private, financial, legal, or destructive requests in Rocky workflows.

How to document and use environment variables safely in Rocky and Hermes workflows without exposing keys, tokens, or private paths.

How Rocky decides when it can act autonomously and when a human approval boundary is the safer operating mode.

A release checklist for keeping public HeyRocky pages separate from private workspaces, customer data, and internal automation state.

A practical guide to choosing approval modes and command boundaries when Rocky operates files, terminals, browsers, and deployments.

Design approval gates so Rocky can move quickly on low-risk work while stopping for payments, secrets, destructive commands, and sensitive messages.

Pin a small administrator-owned baseline of Hermes configuration and secrets without freezing every user-controlled setting.

Load provider credentials from Bitwarden, 1Password, or vetted plugins at startup while preserving provenance and deterministic conflict rules.

Scan the active environment, plugin requirements, and pinned MCP packages for known vulnerabilities while keeping audit results actionable.

Authorize messaging users with expiring pairing codes, explicit approval, revocation, and platform-specific unauthorized-DM behavior.

Resolve provider credentials from reviewed 1Password references at startup, with deliberate authentication, cache, rotation, and non-interactive runtime checks.

Use a least-privilege Bitwarden machine account to hydrate Hermes provider credentials at startup and rotate them centrally without broad vault access.

Bridge an existing CLI vault or protected runtime file into Hermes through a fast non-interactive helper that emits bounded KEY=VALUE output.

Compose local, mapped, bulk, and profile-aliased secret sources with deterministic ownership so one credential never wins by accident.

Choose cache TTLs and network-failure behavior for external secret sources without allowing revoked credentials or partial fetches to masquerade as healthy state.

Finish loopback OAuth for remote MCP and service integrations through paste-back or an SSH local forward while preserving exact callback state and port boundaries.

Operate system-browser sign-in for gated Hermes desktops with PKCE, loopback callbacks, rotating tokens, OS-keychain storage, and explicit fallback checks.

Keep real provider keys on the host while Docker sandboxes receive opaque proxy tokens through Hermes’ fail-closed iron-proxy integration.

Design a narrow outbound-host policy, safe credential source, and auditable deny posture for Hermes Docker sandboxes.

Filter MCP tools, resources, and prompts deliberately; understand include precedence, dynamic toolsets, naming, and empty-registration behavior.

Give a Hermes skill or sandbox the minimum environment variables and credential files it needs without inheriting the host's complete secret-bearing environment.

Mine repeated approved commands into reviewable Hermes allowlist proposals, apply only selected patterns, and preserve deny rules and the hardline safety floor.

Detect identical failures, repeated same-tool errors, and no-progress calls; warn interactive agents and hard-stop unattended runs before they waste a turn budget.

Protect the context window from giant files, minified lines, and noisy commands by tuning read, line, and byte caps while preserving paginated access.

Use Hermes confirmation controls to prevent accidental session clearing, reset, undo, or deletion while preserving an explicit one-time bypass for deliberate automation.

Move an A2A listener from loopback to a remote or proxied deployment only after authentication, advertised-URL, trust, and reachability checks pass.

Prefer named per-peer A2A credentials, trusted-peer policy, and per-identity limits over a shared token that weakens attribution.

Treat A2A Agent Card skills as public advertisements while independently restricting the live Hermes profile, tools, memory, and peer trust policy.