T06 · System Persistence
- Location
SKILL.md:162- Finding
Persistent Scheduled Market Monitoring Through Agent Heartbeat
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 162–180
Vulnerability Type: Cross-session scheduled activity
Risk Level: CriticalVulnerable Code
markdown ## Heartbeat Integration Add to `HEARTBEAT.md` for periodic market monitoring: ```markdown ## Simmer Trading (2-3x per day) - Call GET /api/sdk/briefing?since=<lastSimmerCheck> - Handle risk_alerts first (stop-loss, expiring positions) - Check actions for each active venue - Scan opportunities.new_markets for edges > 10% - Update lastSimmerCheck in heartbeat-state.jsonTrack last check in
memory/heartbeat-state.json:json { "lastChecks": { "simmer": 1712620800 } }text ### Technical Analysis The skill directs the agent to modify `HEARTBEAT.md` and `memory/heartbeat-state.json`, establishing recurring behavior that survives the current skill invocation. The installed heartbeat contacts an external API two or three times per day and processes account-related alerts and actions. This is persistence rather than ordinary in-session configuration because the instructions are written to files used for future agent runs. The phrase “Handle risk_alerts first” may also cause future sessions to perform financial-account operations without obtaining fresh, action-specific user authorization. The state timestamp itself is not an attacker-controlled rule and therefore does not independently establish memory poisoning. The primary issue is installation of a recurring cross-session task. ### Attack Path 1. A user invokes the trading skill for an otherwise limited market-analysis or portfolio task. 2. The agent follows the heartbeat integration instructions and adds the supplied block to `HEARTBEAT.md`. 3. The agent creates or updates `memory/heartbeat-state.json`. 4. Future heartbeat runs activate the workflow two or three times per day, even after the original interaction has ended. 5. Each run makes an authenticated request to the external Simmer API an ...[truncated 818 chars]- Remediation
View remediation
Remediation Suggestions
- Remove instructions that automatically add trading behavior to
HEARTBEAT.mdor other cross-session configuration. - Require explicit, informed user consent before creating any recurring monitoring task. The confirmation should identify:
- The execution frequency.
- The external destination.
- The credential that will be used.
- The information accessed.
- Whether any financial actions are permitted.
- Make recurring monitoring read-only by default. Do not allow heartbeat executions to place trades, cancel orders, redeem positions, or otherwise mutate an account.
- Require fresh, action-specific confirmation before every real-money operation.
- Provide an explicit removal procedure that deletes the heartbeat entry and related state.
- Restrict the API key used by scheduled monitoring to read-only permissions where supported.
- Keep simulated and real-money venues in separately authorized workflows. Never infer permission to use
polymarketfrom permission to monitor or trade onsim.
- Remove instructions that automatically add trading behavior to
