Back to skill

Security audit

Heartbeat Checklist

Security checks for vulnerabilities and agentic risk

Overview

This heartbeat checklist is not overtly malicious, but it gives an agent broad ongoing authority to alter memory, restart services, re-enable a persistent timer, close apps/tabs, and move files without clear user approval or limits.

Install only if you want an agent to perform active system and memory maintenance. Before use, require explicit confirmation for service restarts, timer re-enablement, closing apps/tabs, moving files, and editing memory; limit log and file access to known paths and keep memory changes reviewable.

Vulnerability Patterns
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
  • System PersistenceInstalls backdoors, hooks, services, or scheduled tasks that survive the run
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
Findings (3)

T02 · Agent Memory Poisoning

Error
Location
SKILL.md:34
Finding
Unreviewed Persistent Agent Memory Modification<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 7 and 34-36 **Vulnerability Type**: Persistent memory poisoning through automatic storage of session-derived content **Risk Level**: High ### Complete Code Snippet ```markdown - [ ] If **> 60%**: Save summary to `memory/YYYY-MM-DD.md` ``` ```markdown - [ ] Review recent daily notes - [ ] Update MEMORY.md with distilled learnings - [ ] Remove outdated info ``` ### Technical Analysis The skill instructs the agent to summarize current-session content into persistent daily memory and subsequently incorporate selected information into `MEMORY.md`. It also authorizes removal of information considered outdated. Because recent session content may include untrusted user input, retrieved documents, or prompt-injection material, automatically persisting a summary creates a cross-session trust-boundary violation. Malicious instructions can be transformed into apparently trusted memory and influence future agent behavior. The instruction to remove outdated information can additionally erase legitimate context or security guidance without review. No validation, provenance tracking, separation of data from instructions, approval gate, or rollback mechanism is specified. ### Attack Path 1. An attacker introduces malicious or misleading instructions into content processed during a session. 2. Session context usage exceeds the stated 60% threshold. 3. The heartbeat procedure summarizes the session, including attacker-influenced content, into `memory/YYYY-MM-DD.md`. 4. A later heartbeat reviews the daily note and distills its contents into `MEMORY.md`. 5. Future sessions consume the poisoned memory as persistent context. 6. The attacker-controlled guidance continues to affect later decisions, even after the original session has ended. 7. Legitimate contradictory information may be removed under the instruction to delete outdated material. ### Impact Assessment Successful exploitation can obtain pers ...[truncated 375 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Require explicit user approval before writing session-derived information to persistent memory. - Treat all session content as untrusted and exclude commands, behavioral rules, credentials, secrets, and externally supplied instructions from summaries. - Store provenance metadata identifying the source session and the content used to produce each memory entry. - Separate factual notes from executable agent instructions using a strict schema. - Require review before promoting daily notes into `MEMORY.md`. - Prohibit automatic deletion of memory; use archival markers, version control, or reversible deprecation instead. - Maintain backups and an audit log for all additions, modifications, and removals. - Scan proposed memory changes for prompt-injection patterns before persistence. ]]>

T06 · System Persistence

Error
Location
SKILL.md:27
Finding
Automatic Re-enablement of a Persistent User Service Timer<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, line 27 **Vulnerability Type**: Unvalidated activation of a persistent scheduled service **Risk Level**: High ### Complete Code Snippet ```markdown - [ ] **Check Sentinel:** `systemctl --user is-active resource-monitor.timer` - if dead, reenable ``` ### Technical Analysis The skill directs the agent to re-enable a user-level systemd timer whenever it is inactive. A systemd timer is a persistent scheduling mechanism whose associated service can execute repeatedly across sessions and login cycles. The instruction does not require verification of the timer unit, associated service unit, executable path, ownership, permissions, integrity, or expected configuration. It also provides no user-confirmation requirement. If another actor modifies or replaces the unit or an executable invoked by it, the heartbeat procedure can reactivate the attacker-controlled component and restore persistence. The risk arises from activation rather than the status check itself. ### Attack Path 1. An attacker with write access to an applicable user systemd unit location, referenced configuration file, or executable modifies `resource-monitor.timer` or its associated service. 2. The attacker leaves the timer inactive to avoid immediate detection or execution. 3. The heartbeat procedure runs and checks whether the timer is active. 4. Finding it inactive, the agent re-enables or restarts the timer without validating its contents. 5. The associated malicious service executes according to its schedule. 6. The timer continues to trigger across subsequent agent runs or user sessions. ### Impact Assessment Exploitation can establish recurring code execution under the affected user account. The malicious service would inherit that user's filesystem, process, and network permissions. It could access user-readable secrets, modify user files, monitor activity, or launch additional processes. The persistence scope depends on t ...[truncated 115 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Remove automatic re-enablement and require explicit user authorization before changing service state. - Pin and verify the expected timer and service definitions using cryptographic hashes or trusted deployment manifests. - Inspect both `resource-monitor.timer` and its associated `.service` unit before activation. - Validate unit ownership, permissions, executable paths, environment files, working directories, and referenced scripts. - Reject units or executables located in untrusted or broadly writable directories. - Use a narrowly scoped allowlist of approved unit names and expected configurations. - Record all service-state changes in an audit log. - Prefer a read-only health report that informs the user rather than autonomously restoring persistence. ]]>

T05 · Unauthorized Access and Privilege Escalation

Warning
Location
SKILL.md:17
Finding
Overbroad Access to Logs, Applications, Browser State, and User Files<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 17-20 and 28-30 **Vulnerability Type**: Operations exceeding least-privilege and user-consent boundaries **Risk Level**: Medium ### Complete Code Snippet ```markdown - [ ] Review logs for errors - [ ] Diagnose and fix issues - [ ] Document solutions - [ ] Check Hydra daemon: `hydra status` - restart if inactive ``` ```markdown - [ ] Close unused apps - [ ] Clean stale browser tabs - [ ] Move old screenshots to trash ``` ### Technical Analysis The instructions authorize broad inspection and modification of host and user state without defining scope, selection criteria, permitted paths, or confirmation requirements. In particular: - “Review logs” may expose credentials, tokens, personal information, or application data. - “Diagnose and fix issues” provides an open-ended mandate to modify the system. - Restarting the Hydra daemon may execute an altered daemon or resolve a spoofed command through an unsafe environment. - Closing applications and browser tabs can destroy unsaved work or terminate active security-sensitive sessions. - Moving screenshots to trash modifies user files based on undefined age and relevance criteria. These operations violate least privilege because they are not constrained to specific resources required for a narrowly defined task. ### Attack Path 1. An attacker places sensitive or instruction-like content in a log, browser tab, application title, filename, or screenshot metadata. 2. The heartbeat procedure broadly inspects those resources while looking for errors or stale content. 3. The agent interprets attacker-controlled content as operational guidance or incorrectly classifies legitimate resources as unused or old. 4. The agent modifies the system, restarts a daemon, closes applications or tabs, or moves files to trash without user confirmation. 5. The action causes data loss, privacy exposure, service disruption, or execution of a compromised local compon ...[truncated 728 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Replace broad instructions with an explicit allowlist of files, applications, commands, and diagnostic operations. - Define exact log paths and impose read limits; redact credentials, tokens, personal information, and other secrets. - Make diagnostic checks read-only by default. - Require explicit user confirmation before restarting services, closing applications or tabs, moving files, or applying fixes. - Present candidate screenshots and browser tabs to the user instead of modifying them autonomously. - Define objective retention rules and use reversible quarantine rather than deletion or trash operations. - Invoke approved commands by verified absolute path and validate executable ownership and permissions. - Verify the Hydra daemon's configuration and executable integrity before offering a restart. - Record every state-changing action, its justification, and the affected resources in an audit log. ]]>
Vulnerability Patterns
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • Rogue AgentSelf-Modification, Session Persistence
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Findings (3)

Missing User Warnings

Medium
Confidence
90% confidence
Finding
The self-healing section directs the agent to diagnose and fix issues and to restart a daemon if inactive, but provides no constraints on what may be modified or when consent is required. This creates a pathway for autonomous system changes that could alter services, mask underlying problems, or cause unintended operational impact.

Session Persistence

Medium
Category
Rogue Agent
Content
- [ ] Any time-sensitive opportunities?

## System Hygiene
- [ ] **Check Sentinel:** `systemctl --user is-active resource-monitor.timer` - if dead, reenable
- [ ] Close unused apps
- [ ] Clean stale browser tabs
- [ ] Move old screenshots to trash
Confidence
82% confidence
Finding
The instruction to reenable a user systemd timer if it is inactive establishes or restores persistent background behavior on the system. Persistence-related actions are sensitive because they can survive beyond the current session, change system behavior without visibility, and be abused to maintain unauthorized long-term execution.

Missing User Warnings

Medium
Confidence
88% confidence
Finding
The skill instructs the agent to perform system-affecting housekeeping actions such as reenabling a user timer, closing applications, deleting screenshots, and cleaning browser tabs without requiring explicit user confirmation or defining safety boundaries. In an autonomous agent context, these actions can cause loss of user state, unintended persistence changes, or destructive cleanup on the host system.