T06 · System Persistence
- Location
HEARTBEAT-CONFIG.md:27- Finding
Persistent Autonomous Agent Execution Through Scheduled Cron Jobs
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill is not clearly malicious, but it needs review because it encourages recurring autonomous agent work and shared workspace memory writes without tight scoping or safety controls.
Install only if you intentionally want an agent to keep durable task memory and potentially run on a recurring heartbeat. Keep scheduled jobs under an unprivileged account, avoid /etc/cron.d unless necessary, review and rotate memory logs, and treat task notes, blockers, SESSION-STATE.md, working-buffer.md, WAL files, and HEARTBEAT.md as untrusted input before allowing resumed work or command execution.
HEARTBEAT-CONFIG.md:27Persistent Autonomous Agent Execution Through Scheduled Cron Jobs
scripts/task_manager.py:296Persistent Agent Memory Poisoning Through Unsanitized Task Content
The public description frames the skill as task tracking and proactive work management, but the body adds broader persistence, session-memory reconstruction, automatic health-check repair, and background-oriented operational behavior. This mismatch is dangerous because users or orchestration systems may grant the skill routine planning access without realizing it can autonomously write durable memory artifacts and modify task state outside narrow task-tracking expectations.
This documentation instructs autonomous background agents to write memory files and logs during isolated runs, but it does not clearly warn users that persistent workspace state will be modified automatically. In a proactive/autonomous task skill, silent file writes are security-relevant because they can change project state, consume storage, and create unexpected persistence channels without explicit operator awareness or consent.
The cron example appends autonomous health-check output to a persistent log file using shell redirection, but the document does not provide a user-facing warning that scheduled background execution will continuously modify files. Because this skill is specifically designed for autonomous operation, undocumented recurring writes increase the risk of unnoticed persistence, log growth, and unintended disclosure of task or environment data.
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
Verify heartbeat fires:
crontab -l # Should show your heartbeat job
Test heartbeat message locally:
The README explicitly instructs agents to run the task manager on every heartbeat, perform work autonomously, and log progress/time, which normalizes unattended state changes to local data. In an agent-skill context, this is risky because it encourages continuous autonomous execution and file modification without clear operator consent boundaries, safety checks, or warnings about persistent side effects to tasks.json and related workflow state.
The skill instructs the agent to read and write multiple files (data/tasks.json, WAL logs, SESSION-STATE.md, working-buffer.md, memory files) but declares no explicit tool scope or permissions boundary. In an autonomous skill, undeclared file access increases the chance of over-broad invocation and unauthorized persistence or modification of workspace data beyond what a user expects.
The activation language is broad enough to match many normal planning or project discussions, which can cause the skill to trigger when the user only wants lightweight advice rather than persistent autonomous task management. In that context, the skill may begin creating durable records or steering behavior toward background autonomy without sufficiently clear intent from the user.
The recovery trigger includes generic phrases like being asked to 'continue' or 'where were we?', which are common in ordinary conversation and may spur unsolicited file reads and recovery actions. That broad trigger can cause the agent to consult persistence artifacts and rehydrate prior context when the user did not intend session-state recovery, increasing privacy and boundary risks.
The skill directs operators to create a cron job that periodically sends heartbeat messages, establishing ongoing autonomous execution and session persistence beyond the immediate user interaction. Scheduled re-entry materially raises risk because the agent can continue reading/writing state and taking action without fresh user intent, especially when paired with broad activation and persistent memory files.
**Quick setup:** See [HEARTBEAT-CONFIG.md](HEARTBEAT-CONFIG.md) for complete setup instructions and patterns.
**TL;DR:**
1. Create a cron job that sends you a heartbeat message every 30 minutes
2. Add proactive-tasks checks to your `HEARTBEAT.md`
3. You'll automatically check for tasks and work on them without waiting for prompts
The script is not limited to its own task database: it also writes to workspace-level files such as SESSION-STATE.md and memory/working-buffer.md. Because task titles, notes, blockers, and progress are user/agent-provided content, this creates persistent cross-session state outside the primary datastore and can expose or influence unrelated agent workflows that read those files later.
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
print(json.dumps({"success": True, "goal": goal}, indent=2))
def add_task(args) -> None:
"""Add a task to a goal."""
data = load_data()
# Find the goal
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
print(json.dumps({"success": True, "goal": goal}, indent=2))
def add_task(args) -> None:
"""Add a task to a goal."""
data = load_data()
# Find the goal
The WAL feature writes detailed task events into workspace-level log files under memory/, extending retention of operational data beyond core task storage. This broadens the data exposure surface, duplicates potentially sensitive notes and identifiers, and creates a durable audit trail that other tools or agents may consume unexpectedly.
update_session_state persists task notes, blockers, progress, and contextual goal information into SESSION-STATE.md, which is a workspace-level memory artifact intended for later resurfacing. This increases the risk of sensitive user-provided content being retained longer than expected and being consumed by other agents or tools as trusted context.
The health-check command is described as a check/report function but silently mutates task records and persists those changes. Hidden self-healing behavior is dangerous because an agent or user may invoke what appears to be read-only validation and instead trigger state changes, data tampering, or loss of forensic accuracy without consent.
Automatic repair logic modifies task files without user confirmation or an explicit warning, even though the command name suggests inspection. In an autonomous-agent setting, this can cause unintended writes, conceal upstream corruption, and make it easier for malicious or buggy inputs to trigger state changes under the guise of maintenance.
flush_buffer consolidates captured task updates from the working buffer into a daily memory journal, promoting durable retention and resurfacing of operational history. This can propagate sensitive or misleading content across sessions and make ephemeral task metadata part of a broader workspace memory corpus.
No suspicious patterns detected.