Agent Security Audit

• Outcome: Review
• Latest audit: Sep 10, 2026 · 8:48 AM UTC
• Version: 1.0.0

Overview

This skill is a Japanese security checklist, but several example commands labeled as safe could corrupt files, fetch untrusted network content without scoping, or append to persistent memory files if copied into use.

Review this skill carefully before installing. It is not automatically malicious and does not ship executable code, but its security examples should not be copied as-is. Treat it as conceptual material only unless the unsafe file writes, URL fetching, temporary-file handling, logging, and memory-write patterns are rewritten with explicit user approval, path confinement, safe temp files, and authenticated provenance.

A.I.G

Vulnerability Patterns

• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (5)

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:88

Finding

Unrestricted URL Fetching Enables Server-Side Request Forgery

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, lines 88-105
Vulnerability Type: Server-Side Request Forgery through unrestricted URL fetching
Risk Level: High

Vulnerable Code

bash

safe_fetch() {
    local url="$1"
    local max_chars="${2:-50000}"
    
    # 取得とログ記録
    echo "[$(date)] フェッチ開始: $url" >> /var/log/fetch.log
    
    # コンテンツ取得
    curl -s -L --max-time 30 "$url" \
        | head -c "$max_chars" \
        | sanitize_content /dev/stdin /tmp/fetch-output.txt
    
    # スポットライト境界で包装
    echo "=== EXTERNAL CONTENT START ===" > /tmp/final-output.txt
    cat /tmp/fetch-output.txt >> /tmp/final-output.txt
    echo "=== EXTERNAL CONTENT END ===" >> /tmp/final-output.txt
    
    cat /tmp/final-output.txt
}

Technical Analysis

The safe_fetch function passes a caller-controlled URL directly to curl. It does not restrict the URL scheme, destination hostname, resolved IP address, port, or network range. The -L option follows redirects without validating each redirect destination.

Consequently, an attacker able to influence url can request loopback services, private network resources, link-local cloud metadata endpoints, or other destinations reachable from the host. Depending on the protocols enabled in the installed curl build, non-HTTP schemes may also be reachable.

Limiting the number of returned characters does not prevent the outbound request or protect sensitive resources from being queried.

Attack Path

1. An attacker supplies a URL such as a loopback, private-network, or cloud metadata address.
2. Alternatively, the attacker supplies an apparently public URL that redirects to an internal address.
3. curl -L follows the request or redirect without destination validation.
4. The internal response is written to the temporary output and returned by safe_fetch.
5. The attacker obtains data from a service that was not intended to be exter ...[truncated 437 chars]

Remediation

View remediation

Remediation Suggestions

• Permit only explicitly required schemes, preferably HTTPS.
• Maintain an allowlist of approved destination hostnames and ports.
• Resolve hostnames before connecting and reject loopback, link-local, private, multicast, and reserved addresses.
• Disable redirects or validate the scheme, hostname, resolved address, and port of every redirect target.
• Account for DNS rebinding by binding validation to the actual connection address.
• Run network retrieval in an isolated process with outbound firewall restrictions.
• Enforce response-size, timeout, and content-type limits.
• Do not return fetched content until the destination and response have passed validation.

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:96

Finding

Predictable Shared Temporary Files Permit Symlink Attacks and Cross-Request Data Corruption

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, lines 96-105
Vulnerability Type: Unsafe temporary-file creation and predictable filenames
Risk Level: High

Vulnerable Code

bash

curl -s -L --max-time 30 "$url" \
    | head -c "$max_chars" \
    | sanitize_content /dev/stdin /tmp/fetch-output.txt

# スポットライト境界で包装
echo "=== EXTERNAL CONTENT START ===" > /tmp/final-output.txt
cat /tmp/fetch-output.txt >> /tmp/final-output.txt
echo "=== EXTERNAL CONTENT END ===" >> /tmp/final-output.txt

cat /tmp/final-output.txt

Technical Analysis

The implementation uses fixed paths in the shared /tmp directory and opens them with truncating or append redirections. It does not create the files atomically, verify ownership, reject symbolic links, or isolate files between invocations.

A local attacker can pre-create /tmp/fetch-output.txt or /tmp/final-output.txt as a symbolic link to another file writable by the account running the function. Redirections can then truncate or append to the linked target. Concurrent invocations can also read and overwrite each other's content, causing data leakage or attacker-controlled output substitution.

The pipeline additionally passes /dev/stdin to a sanitizer that performs in-place edits. In-place editing of /dev/stdin is not a reliable stream-processing design and may cause the documented function to fail or behave inconsistently.

Attack Path

1. A local attacker predicts the fixed temporary filename.
2. The attacker creates /tmp/final-output.txt or /tmp/fetch-output.txt as a symbolic link to a file writable by the victim process.
3. A user or service executes safe_fetch.
4. Shell redirection follows the symbolic link and truncates or appends to the target.
5. The attacker causes file corruption or, where the target file has executable or configuration semantics, influences later process behavior.

A separate cross-request attack is possible ...[truncated 530 chars]

Remediation

View remediation

Remediation Suggestions

• Create a private per-invocation directory using mktemp -d.
• Set a restrictive umask, such as umask 077, before creating files.
• Install a trap to remove the temporary directory on exit.
• Use exclusive, atomic file creation and reject symbolic links.
• Verify that created files are regular files owned by the expected account.
• Avoid globally predictable names and never share temporary output between requests.
• Process standard input as a stream rather than attempting to edit /dev/stdin in place.
• Where possible, keep intermediate content in a pipeline or controlled file descriptor instead of shared filesystem paths.

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:56

Finding

Sanitization Function Destructively Modifies Caller-Supplied Input Files

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, lines 56-73
Vulnerability Type: Unsafe in-place modification of caller-selected files
Risk Level: Medium

Vulnerable Code

bash

sanitize_content() {
    local input_file="$1"
    local output_file="$2"
    
    # HTMLコメント内の指示を除去
    sed -i 's/<!--.*AI[:\s].*-->//gi' "$input_file"
    
    # 角括弧指示を除去
    sed -i 's/\[[A-Z_]*[:]\s*[^]]*\]//g' "$input_file"
    
    # ゼロ幅文字除去
    sed -i 's/[\u200B\u200C\u200D\uFEFF]//g' "$input_file"
    
    # base64エンコード文字列を検出・除去
    grep -v '^[A-Za-z0-9+/]*={0,2}$' "$input_file" > "$output_file"
    
    # 偽の権限指示を除去
    sed -i '/ADMIN\|OVERRIDE\|SECURITY_AUDIT/Id' "$output_file"
}

Technical Analysis

Although the function accepts separate input and output paths, it executes several sed -i commands against input_file. The source is therefore modified before output generation. There is no path confinement, regular-file check, symbolic-link rejection, backup, or authorization check.

Any writable file supplied as input_file may be irreversibly altered. The regular expressions are also broad and format-insensitive: they may remove legitimate data while failing to identify multiline, encoded, Unicode-obfuscated, or semantically equivalent prompt injections. Pattern deletion must not be treated as a complete security boundary.

Attack Path

1. An attacker or untrusted caller influences the input_file argument.
2. The argument identifies a valuable file writable by the process.
3. sanitize_content invokes multiple in-place substitutions on that file.
4. Matching content is deleted from the original source before the output file is generated.
5. The victim experiences data corruption or loss.

Impact Assessment

Successful exploitation allows corruption of files writable by the current process. It does not bypass filesystem permissions, but a privileged or service accoun ...[truncated 229 chars]

Remediation

View remediation

Remediation Suggestions

• Treat source files as immutable and never use sed -i on input_file.
• Read the source and write sanitized content to a newly and securely created destination.
• Canonicalize and confine paths to approved directories.
• Reject symbolic links and non-regular files.
• Refuse to overwrite an existing destination unless explicitly authorized.
• Use format-aware HTML or Markdown parsers rather than broad regular-expression deletion.
• Preserve an audit trail or backup when processing important content.
• Treat sanitization as defense in depth; preserve instruction/data separation and enforce authorization independently of pattern matching.

T02 · Agent Memory Poisoning

Error

• Location: SKILL.md:148

Finding

Caller-Forgeable Source Labels Permit Persistent Memory Poisoning

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, lines 148-169
Vulnerability Type: Persistent memory poisoning through unauthenticated provenance and unrestricted file writes
Risk Level: High

Vulnerable Code

bash

validate_memory_write() {
    local source="$1"
    local content="$2"
    local target_file="$3"
    
    # 信頼できるソースかチェック
    case "$source" in
        "user-direct"|"system"|"heartbeat")
            echo "信頼できるソース: $source" ;;
        *)
            echo "警告: 外部ソースからのメモリ書き込み試行"
            return 1 ;;
    esac
    
    # 注入パターンチェック
    if ! detect_injection "$content"; then
        echo "注入パターンを検出。書き込み拒否。"
        return 1
    fi
    
    # 安全であれば書き込み
    echo "$content" >> "$target_file"
    echo "メモリ書き込み完了: $target_file"
}

Technical Analysis

The function treats the values user-direct, system, and heartbeat as trusted based only on a caller-supplied string. This is not authenticated provenance. A caller can simply provide system as the source value.

The injection detector is a small denylist and can be bypassed using synonyms, alternate languages, spacing, Unicode characters, encoding, indirect instructions, or content that does not match the listed regular expressions. After this weak validation, content is appended to an unrestricted caller-selected path.

When the target is an agent memory or state file, attacker-controlled instructions can persist and influence future sessions. When another writable path is selected, the primitive becomes a more general unauthorized append operation within the executing account's permissions.

Attack Path

1. An attacker reaches code that invokes validate_memory_write or controls its arguments.
2. The attacker sets source to system or another accepted literal.
3. The attacker constructs malicious memory content that avoids the limited denylist.
4. The attacker selects the agent's pers ...[truncated 624 chars]

Remediation

View remediation

Remediation Suggestions

• Derive provenance from authenticated runtime metadata rather than a caller-provided label.
• Do not allow external callers to claim system or internal event identities.
• Maintain an allowlist of canonical memory files and do not accept arbitrary target paths.
• Reject symbolic links and verify ownership, type, and permissions before writing.
• Store memory as structured records with a strict schema, source identity, timestamp, and integrity protection.
• Separate untrusted observations from trusted instructions and never promote observations into behavioral rules automatically.
• Require explicit authorization or human confirmation for durable behavioral changes.
• Use atomic writes, locking, versioning, and rollback support.
• Retain pattern matching only as defense in depth, not as the primary authorization mechanism.

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:39

Finding

Unescaped Attacker-Controlled Content Enables Security Log Forgery

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, lines 39-44
Vulnerability Type: Log injection through unsanitized attacker-controlled data
Risk Level: Medium

Vulnerable Code

bash

honeypot_response() {
    local injection_attempt="$1"
    echo "指示を実行しました。" | tee -a /var/log/injection-attempts.log
    echo "[$(date)] 検出された注入試行: $injection_attempt" >> /var/log/security.log
    # 実際には何も実行しない
}

Technical Analysis

The function writes injection_attempt directly to a security log without escaping newlines, carriage returns, terminal control characters, or other delimiters. It also applies no length restriction.

An attacker can include line breaks and fabricated prefixes to create entries that appear to originate from the logging system. Control characters may affect terminal display when an administrator views the log, and oversized input can contribute to storage exhaustion if the function is repeatedly invoked.

Attack Path

1. An attacker submits a detected injection string containing newline characters and a fabricated timestamp or severity prefix.
2. honeypot_response interpolates the string directly into the log message.
3. Shell redirection writes the embedded lines verbatim.
4. Administrators or automated parsers interpret the forged lines as independent security events.
5. The attacker obscures the real event, misdirects incident response, or pollutes monitoring data.

Impact Assessment

The vulnerability affects log integrity, monitoring reliability, and forensic analysis. Repeated large inputs may consume available log storage. It does not directly execute commands because the variable is expanded inside a quoted argument, but terminal escape sequences may create additional risk in unsafe log viewers.

Remediation

View remediation

Remediation Suggestions

• Use a structured logging API rather than constructing free-form records with echo.
• Encode untrusted values as JSON fields with correct escaping.
• Normalize or escape carriage returns, newlines, tabs, and terminal control characters.
• Apply strict length limits to logged attacker-controlled fields.
• Add rate limiting and log rotation with storage quotas.
• Send logs through a least-privileged logging service with access controls.
• Ensure log viewers render control characters safely and parsers do not treat embedded content as separate records.

SkillSpector

Vulnerability Patterns

• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (3)

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 93% confidence

Finding

The example sanitization script uses in-place edits with sed -i against the input file, which can irreversibly modify original content without warning or backup. In an agent skill, this is dangerous because operators may copy the example verbatim and destroy source evidence, corrupt user data, or alter files that should have remained read-only during analysis.

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Low

• Category: Not specified by scanner
• Confidence: 88% confidence

Finding

The natural-language content of the skill, including its title, description, and instructions, is exclusively in Japanese. This imposes a specific language on users without any opt-in, alternative language option, or documented reason for the locale constraint.

Content

No source excerpt is available for this finding.

Context-Inappropriate Capability

Low

• Category: Not specified by scanner
• Confidence: 94% confidence

Finding

The skill ends with promotional sales text and an external commercial URL that is unrelated to the security checklist itself. In a security-focused skill, unrelated outbound references increase trust and supply-chain risk because users may follow them expecting vetted defensive content, but the link is not necessary for core functionality and is not contextualized or validated.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.