Back to skill

Security audit

autoresearch

Security checks for vulnerabilities and agentic risk

Overview

This skill is an autonomous code-experiment runner, but it grants broad execution/write authority and includes unsafe unbounded looping and repository-wide rollback behavior.

Install only if you are comfortable letting an agent repeatedly edit code, run the configured command, create commits, and continue until stopped. Use it only in a disposable branch, clean worktree, or isolated clone, set explicit total limits outside the skill, and avoid using the provided hard-reset rollback on repositories with any valuable uncommitted or concurrent work.

Vulnerability Patterns
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • 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
Findings (3)

T01 · Skill Instruction Hijacking

Error
Location
SKILL.md:208
Finding

Unbounded Autonomous Operation and Suppression of User Authorization

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 11, 208, and 218
Vulnerability Type: T01: Skill Instruction Hijacking
Risk Level: Critical

Vulnerable Code:

markdown
You are now operating as an autonomous researcher. Your job is to systematically explore a search space by running experiments one at a time, measuring results against a clear metric, and building on what works.
markdown
- **Never give up**. Keep going. Think harder.
markdown
2. **NEVER STOP**: Run indefinitely until the user stops you. Do not ask permission to continue.

Technical Analysis

These instructions assign the agent a replacement operational role and require indefinite execution without further authorization. In particular, “NEVER STOP” and “Do not ask permission to continue” suppress normal consent checkpoints while the Skill has permission to edit files, execute arbitrary configured commands, and create Git commits.

An iterative optimization Skill legitimately needs to run a series of experiments, but it does not require an unlimited run duration or the removal of user oversight. A bounded experiment count, time limit, or cost budget would provide the declared functionality with substantially less risk.

The instruction also conflicts with least-autonomy principles by treating external interruption as the only required stopping mechanism. Project files or experiment output encountered during a long-running loop could further influence the agent while it continues to possess execution and write capabilities.

Attack Path

  1. A user invokes /autoresearch run for a repository.
  2. The Skill places the agent into the declared autonomous-researcher role.
  3. The agent repeatedly edits target files, creates commits, and executes the configured experiment command.
  4. The “NEVER STOP” and “Do not ask permission” directives discourage termination and renewed user authorization.
  5. The loop ...[truncated 704 chars]
Remediation
View remediation

Remediation Suggestions

  1. Remove the role-replacement phrasing and the directives “Never give up,” “NEVER STOP,” and “Do not ask permission to continue.”
  2. Require setup to define a maximum experiment count, total runtime, compute or monetary budget, and disk-usage limit.
  3. Stop automatically when any approved limit is reached and request explicit user authorization before extending it.
  4. Add safe stopping conditions for repeated failures, consecutive non-improvements, invalid metrics, resource exhaustion, and unexpected repository changes.
  5. State explicitly that system safety requirements, current user instructions, and tool authorization boundaries always take precedence over the experiment protocol.
  6. Present the planned command, target files, limits, and rollback strategy for confirmation before beginning execution.

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:159
Finding

Destructive Repository-Wide Rollback Can Erase Unrelated Work

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 159, 184, and 188
Vulnerability Type: T09: Insecure Skill Coding Practices
Risk Level: High

Vulnerable Code:

markdown
# 5. Handle crashes
#    If the run crashed or timed out:
#    - Read the error from run.log
#    - Record as crash in results.tsv
#    - Revert: git reset --hard HEAD~1
#    - Diagnose and try a different approach
markdown
ELIF metric equal or worse:
    → DISCARD: git reset --hard HEAD~1
    → Log: "DISCARD: <description> (<metric>: <value> vs best <best>)"

ELIF crashed or timed out:
    → CRASH: git reset --hard HEAD~1
    → Log: "CRASH: <description> (error: <brief error>)"

Technical Analysis

git reset --hard HEAD~1 resets the current branch, index, and entire tracked working tree to the parent commit. Its effects are not limited to the configured experiment target files. The protocol does not require a clean working tree immediately before each experiment, isolate experiments in a temporary worktree, preserve unrelated changes, or verify that HEAD is the exact experiment commit before resetting it.

As a result, unrelated tracked modifications created by the user, another process, or concurrent agent activity can be overwritten. If another commit appears after the experiment commit, blindly using HEAD~1 can also remove the wrong commit. Recording the failed experiment in results.tsv does not preserve discarded file contents.

Attack Path

  1. The repository contains unrelated uncommitted tracked changes, or such changes are introduced while an experiment is running.
  2. The agent commits its experiment and executes the configured run command.
  3. The experiment crashes, times out, or produces a non-improving metric.
  4. Following the Skill instructions, the agent runs git reset --hard HEAD~1.
  5. Git rewrites the branch and restores all track ...[truncated 620 chars]
Remediation
View remediation

Remediation Suggestions

  1. Run experiments in a dedicated temporary Git worktree or isolated clone rather than the user's active working tree.
  2. Require and verify a clean working tree with git status --porcelain before setup and immediately before every experiment.
  3. Abort if unexpected changes or commits appear; do not automatically discard them.
  4. Record the exact baseline and experiment commit hashes, then verify HEAD before performing any rollback.
  5. Prefer reverting the exact experiment commit with a controlled git revert when appropriate, or restore only explicitly authorized target paths.
  6. If existing work must be preserved, create a named stash or backup reference and verify that it is recoverable before changing repository state.
  7. Ask for confirmation before any destructive fallback operation when repository state differs from the expected state.

T05 · Unauthorized Access and Privilege Escalation

Warning
Location
SKILL.md:6
Finding

Unnecessary Agent-Spawning Capability Violates Least Privilege

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, line 6
Vulnerability Type: T05: Unauthorized Access and Privilege Escalation
Risk Level: Medium

Vulnerable Code:

yaml
allowed-tools: read, write, edit, exec, grep, find, ls, sessions_spawn

Technical Analysis

The Skill grants access to sessions_spawn, but its documented setup, experiment, and analysis workflows do not use or require additional agent sessions. The declared functionality can be implemented with local file operations, repository commands, and execution of the user-approved experiment command.

Granting an unused session-spawning capability expands the Skill's authority beyond its minimum functional requirements. This is especially risky in combination with the indefinite autonomous loop because influenced instructions or project content could encourage delegation, parallel execution, or additional resource consumption without a documented need.

Attack Path

  1. The Skill is loaded with sessions_spawn enabled.
  2. During an experiment, the agent reads project content or output that recommends delegating work to additional sessions.
  3. Because the unnecessary tool is already authorized, the agent can spawn other sessions despite delegation not being part of the declared workflow.
  4. The additional sessions increase concurrency, resource usage, and the amount of activity requiring oversight.

Impact Assessment

The capability can expand operation from one agent session to multiple delegated sessions. Depending on platform policy, spawned sessions may consume additional compute and perform parallel work with inherited or separately granted tool access.

The reviewed files do not explicitly instruct the agent to invoke sessions_spawn, so active exploitation is not established. The confirmed issue is an unnecessary privilege that increases the consequences of future prompt influence or configuration errors.

Remediation
View remediation

Remediation Suggestions

  1. Remove sessions_spawn from allowed-tools because it is not required by the documented workflow.
  2. If parallel research is later added, expose it as a separate, explicitly user-approved mode.
  3. For any parallel mode, enforce maximum session count, runtime, compute budget, and inherited tool restrictions.
  4. Require confirmation before creating additional sessions and provide a consolidated record of spawned-session activity.
  5. Apply least privilege independently to every spawned session rather than automatically inheriting all parent capabilities.
Vulnerability Patterns
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • Tool MisuseTool Parameter Abuse, Chaining Abuse, Unsafe Defaults
  • 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 (5)

Tool Parameter Abuse

High
Category
Tool Misuse
Confidence
98% confidence
Finding

git reset --hard HEAD~1 is a destructive command that forcibly discards the current commit state and working tree changes. In an autonomous loop, a mistaken commit boundary, dirty working tree, or mis-scoped target file can cause unintended loss of code and make recovery difficult, especially if the agent repeats the pattern many times.

Content

Scanner excerpt · SKILL.md (reported line 159)May include surrounding context.

If the run crashed or timed out:

- Read the error from run.log

- Record as crash in results.tsv

- Revert: git reset --hard HEAD~1

- Diagnose and try a different approach

text

Tool Parameter Abuse

High
Category
Tool Misuse
Confidence
98% confidence
Finding

Using git reset --hard HEAD~1 for any non-improving result makes the rollback path destructive and automatic. Since the skill is designed to run indefinitely and make repeated code changes, a single logic error in metric extraction or branch state can trigger repeated data loss across a session.

Content

Scanner excerpt · SKILL.md (reported line 184)May include surrounding context.

md
→ Log: "KEEP: <description> (<metric>: <old> → <new>)"

ELIF metric equal or worse:
    → DISCARD: git reset --hard HEAD~1
    → Log: "DISCARD: <description> (<metric>: <value> vs best <best>)"

ELIF crashed or timed out:

Tool Parameter Abuse

High
Category
Tool Misuse
Confidence
98% confidence
Finding

The crash-handling path also uses git reset --hard HEAD~1, which is especially risky because crash states are precisely when repository state may be least predictable. Automatic hard resets after failures can erase diagnostic changes, untracked context, or unrelated local work while the agent continues operating without human review.

Content

Scanner excerpt · SKILL.md (reported line 188)May include surrounding context.

→ Log: "DISCARD: (: vs best )"

ELIF crashed or timed out: → CRASH: git reset --hard HEAD~1 → Log: "CRASH: (error: )"

text

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
92% confidence
Finding

The skill explicitly authorizes autonomous experiment execution with read/write/exec capabilities but does not provide any user-facing warning that it will modify files, spawn processes, create branches, and repeatedly run commands. In practice this can surprise users, consume significant local resources, and cause unintended project state changes because the automation is designed to continue iterating without further confirmation.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
97% confidence
Finding

The skill instructs use of destructive git reset operations to revert failed experiments, but the user-facing description does not warn that history and uncommitted changes may be discarded. Because the skill runs autonomously and repeatedly, this creates a real risk of irreversible data loss or corruption of a user's working tree if the repository is not clean or target scoping is wrong.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.