Back to skill

Security audit

Data

Security checks for vulnerabilities and agentic risk

Overview

This data-analysis skill is mostly coherent, but it includes under-scoped automation and unsafe database-write examples that could affect production data if followed literally.

Install only if you are comfortable reviewing generated data workflow code before it runs. Use read-only or least-privileged database accounts where possible, require explicit approval before scheduling jobs, sending reports externally, cutting over production data, or deleting rows, and replace the shown SQL string-interpolation examples with parameterized queries and validation.

Vulnerability Patterns
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • 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
Findings (2)

T09 · Insecure Skill Coding Practices

Warning
Location
patterns.md:123
Finding

SQL Injection in Incremental Loading Query

Content
View full analysis

Vulnerability Details

File Location: patterns.md:123
Vulnerability Type: SQL injection through string interpolation
Risk Level: Medium

Vulnerable Code:

python
new_data = query(f"WHERE updated_at > '{last_loaded}'")

Technical Analysis

The incremental-loading example directly embeds last_loaded into an SQL predicate using an f-string. It does not use a bound parameter, strict timestamp conversion, or escaping. This unsafe example also contradicts the parameterization requirement documented in querying.md:41.

If an implementation follows this pattern and last_loaded can be influenced through user input, upstream data, or persisted workflow state, an attacker could insert quote characters and additional SQL syntax. Whether stacked statements are available depends on the database driver, but predicate manipulation or UNION-based extraction may remain possible even when multiple statements are disabled.

Attack Path

  1. The attacker influences the value stored or supplied as last_loaded.
  2. The application inserts that value directly between SQL quotes.
  3. A malicious value terminates the intended timestamp literal and adds SQL syntax.
  4. The database parses the injected content as part of the query.
  5. The attacker may alter filtering behavior or retrieve data outside the intended incremental window, subject to the database account's permissions.

Impact Assessment

Exploitation may expose records beyond the intended date range and, depending on the surrounding query, driver behavior, and database privileges, may enable broader unauthorized database reads. The resulting access is bounded by the permissions of the database connection used by the workflow. If the connection has write or administrative privileges, the potential scope may be greater.

Remediation
View remediation

Remediation Suggestions

  • Replace f-string construction with the database driver's parameter-binding mechanism.

  • Parse and validate the watermark as a timestamp before executing the query.

  • Store watermarks in a typed state store rather than accepting arbitrary SQL fragments.

  • Run extraction with a read-only, least-privileged database account.

  • Add tests containing quotes, SQL metacharacters, malformed timestamps, and boundary values.

  • Update the example to follow a safe pattern such as:

    python
    last_loaded = parse_timestamp(get_last_watermark())
    new_data = query(
        "SELECT required_columns FROM source_table WHERE updated_at > ?",
        parameters=(last_loaded,),
    )
    

    The exact placeholder syntax should be adjusted for the selected database driver.

T09 · Insecure Skill Coding Practices

Error
Location
patterns.md:131
Finding

SQL Injection in Idempotent Delete Predicate

Content
View full analysis

Vulnerability Details

File Location: patterns.md:131
Vulnerability Type: SQL injection in a destructive database operation
Risk Level: High

Vulnerable Code:

python
delete(target, where="date = '{date}'")

Technical Analysis

The idempotent-write example supplies a SQL-like deletion predicate constructed from an interpolated date value. No parameter binding, strict date validation, or escaping is demonstrated. Because this predicate controls a destructive operation, injected syntax could broaden the deletion condition beyond the intended partition.

The precise runtime behavior depends on how delete() processes the where string. If it formats the placeholder or otherwise inserts an attacker-influenced date into raw SQL, a malicious value could terminate the literal and introduce an always-true condition or other SQL syntax.

Attack Path

  1. The attacker controls or influences the date value used by a recurring report, migration, or data-loading workflow.
  2. The workflow inserts the value into the raw where predicate.
  3. The crafted value closes the expected date literal and modifies the predicate.
  4. The database executes a broader DELETE than intended.
  5. Rows outside the selected date partition are removed; if multiple statements are supported, additional operations may also be attempted.

Impact Assessment

A successful exploit could cause partial or complete deletion of data accessible to the workflow's database account. This may disrupt pipelines, reports, and downstream consumers and may require restoration from backups or source-system reprocessing. The maximum scope is limited by the target selected by the application and the database account's privileges, but excessive write privileges could increase the blast radius.

Remediation
View remediation

Remediation Suggestions

  • Do not accept a raw SQL predicate for destructive operations.

  • Parse date into a strict date type and reject malformed or out-of-range values.

  • Use a deletion API that separates the SQL statement from bound parameters.

  • Execute the delete and replacement insert in a transaction so failures can be rolled back.

  • Apply least privilege so the loader can modify only the required table or partition.

  • Require safeguards such as expected-row-count limits before committing destructive operations.

  • Add tests proving that quotes and SQL metacharacters cannot alter the predicate.

  • Use a parameterized pattern such as:

    python
    validated_date = parse_iso_date(date)
    execute(
        "DELETE FROM target_table WHERE date = ?",
        parameters=(validated_date,),
    )
    

    The table name must come from a trusted allowlist because SQL parameter binding generally cannot bind identifiers.

Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Findings (3)

Vague Triggers

Medium
Category
Not specified by scanner
Confidence
93% confidence
Finding

The 'When to Use' section describes a very wide range of situations such as extracting data, cleaning datasets, analyzing patterns, visualizing results, or automating recurring tasks. It does not define clear constraints or exclusion conditions, so the skill could be invoked for many generic requests that overlap with ordinary analytical conversation.

Content

No source excerpt is available for this finding.

Vague Triggers

Medium
Category
Not specified by scanner
Confidence
90% confidence
Finding

The trigger column includes natural phrases like 'What does this data tell us?' and 'Clean this and load it there,' which are broad requests that could appear in normal conversation. The file does not provide negative examples or clarify whether these are exclusive triggers, representative examples, or merely illustrative prompts.

Content

No source excerpt is available for this finding.

Missing User Warnings

Low
Category
Not specified by scanner
Confidence
83% confidence
Finding

This markdown file includes workflow steps for creating a delivery mechanism via email or Slack and for cutting over production data during migration, but it does not include any warning about possible impacts to user data, privacy, or system integrity. Under the markdown-specific warning criterion, workflows that can transmit data externally or affect production systems should disclose those risks.

Content

No source excerpt is available for this finding.