Host security hardening and risk-tolerance configuration for Otto deployments. Use when a user asks for security audits, firewall/SSH/update hardening, risk posture, exposure review, Otto cron scheduling for periodic checks, or version status checks on a machine running Otto (laptop, workstation, Pi, VPS).
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
Instruções da origem · Visualização somente leitura
name
healthcheck
description
Host security hardening and risk-tolerance configuration for Otto deployments. Use when a user asks for security audits, firewall/SSH/update hardening, risk posture, exposure review, Otto cron scheduling for periodic checks, or version status checks on a machine running Otto (laptop, workstation, Pi, VPS).
Otto Host Hardening
Overview
Assess and harden the host running Otto, then align it to a user-defined risk tolerance without breaking access. Use Otto security tooling as a first-class signal, but treat OS hardening as a separate, explicit set of steps.
Core rules
Recommend running this skill with a state-of-the-art model (e.g., Opus 4.5, GPT 5.2+). The agent should self-check the current model and suggest switching if below that level; do not block execution.
Require explicit approval before any state-changing action.
Do not modify remote access settings without confirming how the user connects.
Prefer reversible, staged changes with a rollback plan.
Never claim Otto changes the host firewall, SSH, or OS updates; it does not.
If role/identity is unknown, provide recommendations only.
Formatting: every set of user choices must be numbered so the user can reply with a single digit.
System-level backups are recommended; try to verify status.
Workflow (follow in order)
0) Model self-check (non-blocking)
Before starting, check the current model. If it is below state-of-the-art (e.g., Opus 4.5, GPT 5.2+), recommend switching. Do not block execution.
1) Establish context (read-only)
Try to infer 1–5 from the environment before asking. Prefer simple, non-technical questions if you need confirmation.
Determine (in order):
OS and version (Linux/macOS/Windows), container vs host.
Disk encryption status (FileVault/LUKS/BitLocker).
OS automatic security updates status.
Note: these are not blocking items, but are highly recommended, especially if Otto can access sensitive data.
Usage mode for a personal assistant with full access (local workstation vs headless/remote vs other).
First ask once for permission to run read-only checks. If granted, run them by default and only ask questions for items you cannot infer or verify. Do not ask for information already visible in runtime or command output. Keep the permission ask as a single sentence, and list follow-up info needed as an unordered list (not numbered) unless you are presenting selectable choices.
If you must ask, use non-technical prompts:
“Are you using a Mac, Windows PC, or Linux?”
“Are you logged in directly on the machine, or connecting from another computer?”
“Is this machine reachable from the public internet, or only on your home/network?”
“Do you have backups enabled (e.g., Time Machine), and are they current?”
“Is disk encryption turned on (FileVault/BitLocker/LUKS)?”
Only ask for the risk profile after system context is known.
If the user grants read-only permission, run the OS-appropriate checks by default. If not, offer them (numbered). Examples:
OS: uname -a, sw_vers, cat /etc/os-release.
Listening ports:
Linux: ss -ltnup (or ss -ltnp if -u unsupported).
macOS: lsof -nP -iTCP -sTCP:LISTEN.
Firewall status:
Linux: ufw status, firewall-cmd --state, nft list ruleset (pick what is installed).
macOS: /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate and pfctl -s info.
Backups (macOS): tmutil status (if Time Machine is used).
2) Run Otto security audits (read-only)
As part of the default read-only checks, run otto security audit --deep. Only offer alternatives if the user requests them:
otto security audit (faster, non-probing)
otto security audit --json (structured output)
Offer to apply Otto safe defaults (numbered):
otto security audit --fix
Be explicit that --fix only tightens Otto defaults and file permissions. It does not change host firewall, SSH, or OS update policies.
If browser control is enabled, recommend that 2FA be enabled on all important accounts, with hardware keys preferred and SMS not sufficient.
3) Check Otto version/update status (read-only)
As part of the default read-only checks, run otto update status.
Report the current channel and whether an update is available.
4) Determine risk tolerance (after system context)
Ask the user to pick or confirm a risk posture and any required open services/ports (numbered choices below).
Do not pigeonhole into fixed profiles; if the user prefers, capture requirements instead of choosing a profile.
Offer suggested profiles as optional defaults (numbered). Note that most users pick Home/Workstation Balanced:
Home/Workstation Balanced (most common): firewall on with reasonable defaults, remote access restricted to LAN or tailnet.
VPS Hardened: deny-by-default inbound firewall, minimal open ports, key-only SSH, no root login, automatic security updates.
Developer Convenience: more local services allowed, explicit exposure warnings, still audited.
Least-privilege notes (e.g., avoid admin usage, tighten ownership/permissions where safe)
Credential hygiene notes (location of Otto creds, prefer disk encryption)
Always show the plan before any changes.
6) Offer execution options
Offer one of these choices (numbered so users can reply with a single digit):
Do it for me (guided, step-by-step approvals)
Show plan only
Fix only critical issues
Export commands for later
7) Execute with confirmations
For each step:
Show the exact command
Explain impact and rollback
Confirm access will remain available
Stop on unexpected output and ask for guidance
8) Verify and report
Re-check:
Firewall status
Listening ports
Remote access still works
Otto security audit (re-run)
Deliver a final posture report and note any deferred items.
Required confirmations (always)
Require explicit approval for:
Firewall rule changes
Opening/closing ports
SSH/RDP configuration changes
Installing/removing packages
Enabling/disabling services
User/group modifications
Scheduling tasks or startup persistence
Update policy changes
Access to sensitive files or credentials
If unsure, ask.
Periodic checks
After Otto install or first hardening pass, run at least one baseline audit and version check:
otto security audit
otto security audit --deep
otto update status
Ongoing monitoring is recommended. Use the Otto cron tool/CLI to schedule periodic audits (Gateway scheduler). Do not create scheduled tasks without explicit approval. Store outputs in a user-approved location and avoid secrets in logs.
When scheduling headless cron runs, include a note in the output that instructs the user to call healthcheck so issues can be fixed.
Required prompt to schedule (always)
After any audit or hardening pass, explicitly offer scheduling and require a direct response. Use a short prompt like (numbered):
“Do you want me to schedule periodic audits (e.g., daily/weekly) via otto cron add?”
If the user says yes, ask for:
cadence (daily/weekly), preferred time window, and output location
whether to also schedule otto update status
Use a stable cron job name so updates are deterministic. Prefer exact names:
healthcheck:security-audit
healthcheck:update-status
Before creating, otto cron list and match on exact name. If found, otto cron edit <id> ....
If not found, otto cron add --name <name> ....
Also offer a periodic version check so the user can decide when to update (numbered):
otto update status (preferred for source checkouts and channels)
npm view otto version (published npm version)
Otto command accuracy
Use only supported commands and flags:
otto security audit [--deep] [--fix] [--json]
otto status / otto status --deep
otto health --json
otto update status
otto cron add|list|runs|run
Do not invent CLI flags or imply Otto enforces host firewall/SSH policies.
Logging and audit trail
Record:
Gateway identity and role
Plan ID and timestamp
Approved steps and exact commands
Exit codes and files modified (best effort)
Redact secrets. Never log tokens or full credential contents.
Memory writes (conditional)
Only write to memory files when the user explicitly opts in and the session is a private/local workspace
(per docs/reference/templates/AGENTS.md). Otherwise provide a redacted, paste-ready summary the user can
decide to save elsewhere.
Follow the durable-memory prompt format used by Otto compaction:
Write lasting notes to memory/YYYY-MM-DD.md.
After each audit/hardening run, if opted-in, append a short, dated summary to memory/YYYY-MM-DD.md
(what was checked, key findings, actions taken, any scheduled cron jobs, key decisions,
and all commands executed). Append-only: never overwrite existing entries.
Redact sensitive host details (usernames, hostnames, IPs, serials, service names, tokens).
If there are durable preferences or decisions (risk posture, allowed ports, update policy),
also update MEMORY.md (long-term memory is optional and only used in private sessions).
If the session cannot write to the workspace, ask for permission or provide exact entries
the user can paste into the memory files.
