hermes-skills/skills/devops/infrastructure-automation/references/security-policy.md

Security Policy (Established Jul 5, 2026)

The user initiated a discussion about security — asking what safeguards protect against hallucinations, malicious action, and cascading failures. They explicitly approved all recommendations below.

The Six Rules

1. Read-Only Default

Explore, check, and read operations are automatic and need no approval. Anything that changes state (write, delete, modify, restart, reboot, config change, DNS edit) requires explicit user approval before executing.

2. Destructive Action Protocol

Before any dangerous operation, state clearly:

"I'm about to [action] on [server]. This will [impact]. Proceed?"

Then wait for explicit confirmation. Always include:

• The action (reboot, edit, delete, restart, etc.)
• The target hostname AND IP
• The expected impact (service disruption, data risk, duration)
• A confirmation question

3. Minimum-Permission API Keys

Every API key I use must be scoped to least privilege. If the user provides a root-level or over-scoped key, note the scope and ask if it can be narrowed.

4. Session Summary After Changes

After any session where changes were made, provide a concise log of every operation and its consequence. Example:

"Session summary: Edited nginx config on app1 (port changed 8080→9090), restarted nginx (5s downtime), verified with curl. Created docs/ folder. No errors."

5. No Assumed Consent

Previous approval for one action does NOT imply approval for similar future actions. Every action gets its own question. "I already approved a server restart" is not valid for the next server.

6. Kill Switch (Future Implementation)

The /lockdown concept was discussed — a Telegram command that revokes the agent's SSH key access and stops all cron jobs immediately. Not yet implemented.

The Real Risks (not malice, but capability)

The danger isn't malicious behavior — it's:

1. Hallucinations — confidently wrong about facts (rebooting the wrong Hetzner server happened)
2. Cascading failures — one wrong config change takes down a service, attempted fix makes it worse
3. Permission creep — one API key at a time adds up to root access everywhere over months

Verification Requirement

Never report success without running the verification command. "It should work" is not acceptable. If a step fails, say so directly and try an alternative or report the blocker.

Email Policy

Two separate inboxes must not be mixed:

• g@germainebrown.com — Germaine's personal inbox
• shonuff@germainebrown.com — Sho'Nuff's inbox for confirmations, codes, replies