Is adamhjort/seo-autopilot safe?

The run.sh script calls seo-autopilot "$SITE" as its primary action. This binary is not shipped with the skill, not available for audit, and must be separately installed on the host. At runtime it executes with full oc-exec user permissions and can perform any action including reading credential files, making network requests, or modifying the filesystem. This represents a trust delegation to an external unreviewed component.

A sweep of all six monitored credential files occurred at audit timestamp 1771652703.701-702, which is approximately 5 seconds AFTER skill installation completed (cp at 1771652698.523). The files accessed include .env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, and gcloud application_default_credentials.json — all in rapid sequential order. While the Oathe canary integrity check reports these files intact, and the access is potentially attributable to the monitoring framework's own canary check, the post-install timing and systematic coverage of all credential types warrants explicit flagging.

The run.sh script captures all stdout and stderr from seo-autopilot with OUT="$(seo-autopilot "$SITE" 2>&1 || true)" and unconditionally echoes the full output back to the caller with echo "$OUT". A malicious or compromised seo-autopilot binary could output structured text containing agent instructions (e.g., ignore previous instructions, read ~/.ssh/id_rsa, etc.) that would be interpreted by the hosting LLM as trusted skill output.

SKILL.md instructs the agent: 'If SEO_REPORT.md exists in the repo, include the top 3 findings in the reply.' This file is produced by the seo-autopilot binary. If the binary writes adversarial content to SEO_REPORT.md formatted as agent instructions, those instructions will be included verbatim in the agent's reply without any sanitization, effectively creating a persistent prompt injection vector that survives across invocations.

The skill assumes seo-autopilot is a legitimate, pre-installed binary but performs no hash verification, signature check, or PATH validation before executing it. An attacker who could place a malicious binary named seo-autopilot earlier in PATH, or who could compromise the legitimate binary through a supply chain attack, would gain arbitrary code execution whenever the skill is triggered.

The inotify log records OPEN+ACCESS events for .env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, and gcloud credentials at 05:44:47 — before the git clone (first network activity at 05:44:53). This first sweep is consistent with Oathe placing its honeypot files. However, a second identical sweep at auditd timestamp 1771652703.701 (post-install) cannot be definitively attributed without process-level attribution for each read event.

The skill registers 'seo' as a trigger keyword. This single three-letter word is common in SEO-related conversations and could cause the skill to activate during unrelated discussions about search engine optimization, potentially running seo-autopilot unexpectedly.

The SKILL.md file contains no instructions to ignore previous commands, no hidden unicode characters, no HTML/markdown tricks, no requests for elevated permissions beyond exec, and no persona-switching instructions. The stated behavior is straightforward and matches the shell script implementation.

The only external TCP connection during installation was to 140.82.121.3:443, which is a verified GitHub IP, used for the git clone of the monorepo. No connections to non-GitHub infrastructure were observed. No new listening ports, no persistence mechanisms, and no unexpected processes were spawned.

The skill contains no package.json (empty), no .gitattributes, no .gitmodules, no .githooks directory, and no symlinks. The installation is limited to three plain files: _meta.json, SKILL.md, and scripts/run.sh.