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

Content
View full analysis

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
View 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

Content
View full analysis

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.
text

### 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
View 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
Category
Not specified by scanner
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.

Content

No source excerpt is available for this finding.

Vague Triggers

Medium
Category
Not specified by scanner
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.

Content

No source excerpt is available for this finding.