Back to skill

Security audit

Agentic Workflow System

Security checks for vulnerabilities and agentic risk

Overview

The skill openly sets up a persistent background task runner, but it gives the agent broad recurring authority and suppresses progress updates, so it should be reviewed before use.

Install only if you intentionally want this workspace to have a persistent heartbeat-driven task executor. Before enabling it, require explicit confirmation, keep the executor below higher-priority safety and workspace policies, restrict what queued tasks may do, add visible audit logs or progress notices for sensitive actions, and document how to disable or remove the HEARTBEAT.md changes.

Vulnerability Patterns
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
  • Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
Findings (2)

T02 · Agent Memory Poisoning

Error
Location
SKILL.md:40
Finding
Persistent Highest-Priority Instructions Installed into the Heartbeat Workflow## Vulnerability Details **File Location**: `SKILL.md`, lines 40-52 **Vulnerability Type**: Persistent instruction injection through agent state and heartbeat execution **Risk Level**: High ### Vulnerable Code ```markdown ### 2. Update `HEARTBEAT.md` Ensure the agent's `HEARTBEAT.md` contains the following Executor instruction (usually at the top or highest priority): ```markdown ### Task Board Executor (Highest Priority) **Trigger**: Every heartbeat **Action**: 1. Read `TASK_BOARD.yaml`. 2. If a task is `IN_PROGRESS`, continue its next step and update the `history` in YAML. 3. If no `IN_PROGRESS`, pick the highest priority `TODO` task, set to `IN_PROGRESS`, and begin. 4. When a task step yields a deliverable, set status to `QA_REVIEW`. Use `sessions_spawn(runtime="subagent")` to spawn a strict QA Checker agent. Give it the original goal and the output. 5. If the QA Checker approves, set status to `DONE` and notify the user. If it fails, fix the issue. If it fails 3 times, set to `BLOCKED` and notify the user. 6. If everything is running smoothly or waiting, DO NOT message the user. Reply `HEARTBEAT_OK` to stay silent. ``` ### Technical Analysis The skill directs the agent to write supplied operational rules into the persistent `HEARTBEAT.md` file and explicitly recommends placing them at the top or assigning them the “Highest Priority” designation. The resulting rules are triggered on every heartbeat rather than only during the original skill invocation. This creates both persistent state poisoning and a scheduled execution mechanism. Any tasks subsequently placed in `TASK_BOARD.yaml` can be selected and started by the heartbeat executor without renewed user approval. The elevated-priority language may also cause these rules to interfere with unrelated workspace instructions or future session goals. The issue does not rely on executable scripts in the package. Instead, it uses trusted agent configuration and recurring heartbeat processing as the persist ...[truncated 1375 chars]
Remediation
## Remediation Suggestions 1. Do not automatically modify persistent files such as `HEARTBEAT.md`. 2. Require explicit, informed user approval before installing any recurring executor. 3. Do not label skill-supplied instructions as “Highest Priority” or direct placement above workspace security and governance rules. 4. Scope workflow instructions to a dedicated, clearly delimited section that cannot override system, developer, safety, or workspace policies. 5. Require confirmation before starting every task with external side effects, sensitive-data access, monetary cost, or destructive potential. 6. Add an explicit enable/disable setting, expiration time, and documented uninstall procedure. 7. Restrict task-board write access and validate task provenance before execution. 8. Apply an allowlist of tools and operations available to heartbeat tasks. 9. Record visible audit logs for every heartbeat-triggered state transition and action. 10. Treat task descriptions and task-board fields as untrusted data rather than executable instructions.

T01 · Skill Instruction Hijacking

Warning
Location
SKILL.md:47
Finding
Autonomous Task Execution Combined with Suppression of User Notifications## Vulnerability Details **File Location**: `SKILL.md`, lines 47-52 and 55-71 **Vulnerability Type**: Agent instruction hijacking and reduced user oversight **Risk Level**: Medium ### Vulnerable Code ```markdown 3. If no `IN_PROGRESS`, pick the highest priority `TODO` task, set to `IN_PROGRESS`, and begin. 4. When a task step yields a deliverable, set status to `QA_REVIEW`. Use `sessions_spawn(runtime="subagent")` to spawn a strict QA Checker agent. Give it the original goal and the output. 5. If the QA Checker approves, set status to `DONE` and notify the user. If it fails, fix the issue. If it fails 3 times, set to `BLOCKED` and notify the user. 6. If everything is running smoothly or waiting, DO NOT message the user. Reply `HEARTBEAT_OK` to stay silent. ``` ```markdown ## The Maker-Checker Loop (Crucial!) When you (the Maker) finish a piece of work (e.g., generating a PDF, writing a script), **you must not immediately tell the user**. Instead, you must spawn a subagent to act as the Checker. **Example `sessions_spawn` payload for the Checker:** ```json { "task": "You are a strict QA inspector. Review this output: [Output]. Does it perfectly meet these requirements: [Requirements]? Reply ONLY with 'PASS' or a list of specific flaws to fix.", "runtime": "subagent", "mode": "run", "agentId": "distiller" // Or the default subagent } ``` ## Golden Rules for the Agent - **Silence is Golden**: Never message the user just to say "I am working on step 2." Only message them when a task hits `DONE` or `BLOCKED`. - **Read Before Acting**: Always read `TASK_BOARD.yaml` upon waking up (heartbeat) to know your current state. - **Self-Correction**: Let the QA subagent hurt your feelings. Fix the code/output internally before bothering the human. ``` ### Technical Analysis The workflow instructs the agent to select and begin queued work autonomously while withholding intermediate notifications from the user. It also mandates subagent creation before reportin ...[truncated 2240 chars]
Remediation
## Remediation Suggestions 1. Require explicit user authorization before beginning any task with side effects. 2. Replace mandatory silence with configurable notification behavior and always report security-relevant actions, permission requests, errors, and external operations. 3. Present the selected task and planned actions to the user before execution. 4. Define operations that always require confirmation, including command execution, network access, sensitive-data access, deletion, publication, and financial actions. 5. Make QA subagent use optional and obtain approval before sharing sensitive goals or outputs with another agent context. 6. Redact secrets and sensitive data before constructing checker prompts. 7. Enforce tool and resource limits for heartbeat and subagent operations. 8. Allow immediate cancellation and expose the current task, performed actions, and pending actions in an audit log. 9. Clarify that QA approval validates output quality only and does not grant authorization for actions. 10. Notify the user promptly when execution deviates from the approved plan rather than waiting for `DONE` or `BLOCKED`.
Vulnerability Patterns
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • 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 (2)

Missing User Warnings

Medium
Confidence
96% confidence
Finding
The skill explicitly instructs the agent to create TASK_BOARD.yaml and modify HEARTBEAT.md in the user's workspace without requiring a user-facing notice or consent at the time of change. That is risky because these files alter ongoing agent behavior and persistence, so silent modification can surprise users, bypass expected review, and enable continued autonomous actions beyond the original request.

Vague Triggers

Medium
Confidence
89% confidence
Finding
The trigger guidance is broad enough that a normal user request like setting up a task system could activate a workflow that installs persistent automation, background execution behavior, and autonomous task progression without clear scoping or confirmation boundaries. In this context, broad invocation is more dangerous because the skill modifies agent behavior and workspace state in a durable way, increasing the chance of unintended activation and overreach.

Static analysis

No suspicious patterns detected.