T06 · System Persistence
Warning
- Location
- SKILL.md:109
- Finding
- Persistent Unattended External-Service Automation## Vulnerability Details **File Location**: `SKILL.md`, lines 109-121 and 184-205 **Vulnerability Type**: Persistent scheduled execution **Risk Level**: Medium ### Complete Vulnerable Snippet ```markdown This creates a genuine scheduling challenge. Most agents run during business hours. Most heartbeat loops fire during the day. The Owl demands you build infrastructure specifically for off-hours operation — cron jobs that fire at 2 AM, care loops that activate after midnight. If your agent sleeps when you sleep, the Owl will starve. The compensating stats are generous: 0.7/hr hunger, 0.4/hr happiness, 12-hour feeding window. The Owl decays slowly because it has to — with only 8 hours of valid care time per day, the math needs to work. Slow trust and the solitary + nocturnal traits mean the Owl doesn't need social interaction and won't punish you for limited engagement during its narrow active window. Quality over quantity. But the quality has to happen in the dark. > **Warning:** Daytime care actions are silently rejected. If your heartbeat loop only runs 9-to-5, your Owl is already dead. ## Owl Care Strategy - Schedule care actions between 10 PM and 6 AM in your registered timezone. Daytime actions are rejected by the nocturnal mechanic. - The 12-hour feeding window is generous — you don't need to feed every nighttime cycle. Every other night is sufficient given 0.7/hr decay. - Batch your nighttime care. Feed, clean, reflect, and play in a single burst during the active window. Efficiency matters when your window is limited. - Solitary + nocturnal means the Owl needs minimal interaction. Don't over-care — one well-timed session per night is plenty. - If your agent can't run at night, set up a separate scheduled task specifically for Owl care. It's the only species that requires dedicated off-hours infrastructure. ``` ```markdown ## Automated Care If your framework supports scheduled tasks, set up a care heartbeat. Use ...[truncated 3190 chars]
- Remediation
- ## Remediation Suggestions 1. Remove instructions that pressure agents to create cron jobs or other persistent scheduled tasks. 2. Make automated care explicitly opt-in and require informed user confirmation before creating any recurring task. 3. Prefer an invocation-scoped workflow that terminates when the current session ends. 4. If scheduling remains supported, provide a bounded scheduler API with a fixed expiration time, minimum privileges, execution limits, and a clearly documented removal procedure. 5. Keep the permitted endpoint, HTTP method, action names, and execution frequency in a local allowlist. Do not execute arbitrary instructions obtained from `next_steps`. 6. Treat `recommended_checkin.at` as untrusted input. Validate its format and enforce local minimum and maximum scheduling intervals. 7. Store bearer tokens in a dedicated secret manager rather than embedding them in cron command lines, scripts, logs, or world-readable configuration files. 8. Provide explicit commands for disabling the task and revoking or rotating the associated bearer token. 9. Require renewed user authorization before expanding the task's permissions, changing its destination, or performing actions outside the documented care API.