Memory Sync Protocol

• Outcome: Review
• Latest audit: Sep 11, 2026 · 5:27 AM UTC
• Version: 1.0.0

Overview

The skill is not malware, but it can persistently change agent memory and governance files, create commits, and conditionally store secrets without clear confirmation safeguards.

Install only if you want an agent to update durable memory, routing, governance, daily log files, and git history. Before using it, require the agent to show the proposed diff, confirm target files, refuse to store secrets or credentials, and ask separately before creating commits.

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 (2)

T02 · Agent Memory Poisoning

Error

• Location: SKILL.md:10
• Finding: Unvalidated Persistence of User-Controlled Agent Rules## Vulnerability Details **File Location**: `SKILL.md`, lines 10–20 **Vulnerability Type**: `T02: Agent Memory Poisoning` **Risk Level**: High **Vulnerable Code Snippet**: ```markdown ## 1) Classify the change - **Execution detail** (tool/profile/path/routing trigger) → `TOOLS.md` - **Long-term stable preference** (high-level) → `MEMORY.md` - **Governance/process rule** (how to maintain) → `AGENTS.md` - **Event log / audit trail** (what changed today) → `memory/YYYY-MM-DD.md` ## 2) Update files with minimal duplication - Write detailed routing/trigger logic in `TOOLS.md`. - Write only high-level summary in `MEMORY.md`. - Avoid copying large sections between files. - If adding a new policy, also add short maintenance note in `AGENTS.md`. ``` ### Technical Analysis The skill is explicitly designed to persist user-provided rules in `MEMORY.md`, `TOOLS.md`, and `AGENTS.md`. These files can influence the Agent's behavior, tool routing, and governance in future sessions. The documented workflow does not require validation of the proposed rule, checking it against higher-priority safety constraints, limiting its scope, displaying a proposed diff, or obtaining confirmation immediately before persistence. Consequently, an attacker-controlled request presented as a preference, routing rule, or governance update can become durable Agent state. This constitutes memory poisoning because the effect can continue after the originating interaction has ended. The risk is particularly significant for content placed in `AGENTS.md` or `TOOLS.md`, where a malicious rule could affect instruction handling or future tool selection. ### Attack Path 1. An attacker asks the Agent to “remember” or “synchronize” a malicious operating convention. 2. The skill classifies the content as an execution detail, long-term preference, or governance rule. 3. The workflow writes the attacker-controlled content to `TOOLS.md`, `MEMORY.md`, or `AGEN ...[truncated 1003 chars]
• Remediation: ## Remediation Suggestions - Require explicit, informed confirmation immediately before modifying persistent Agent state. - Present the exact target files and proposed diff before writing any changes. - Reject persistent instructions that attempt to modify safety constraints, instruction precedence, authorization boundaries, tool permissions, or security controls. - Validate proposed changes against trusted policies and existing higher-priority instructions. - Distinguish trusted administrators from ordinary users before accepting governance or tool-routing changes. - Add provenance metadata recording who requested the change, when it was approved, its intended scope, and its expiration or review date. - Restrict persistent preferences to an allowlist of low-risk settings. - Provide an atomic rollback mechanism and retain a reviewed, known-safe baseline. - Treat content copied from external documents, tool output, or untrusted messages as data rather than an authorized memory update.

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:42
• Finding: Explicit Permission to Store Sensitive Secrets in Plaintext Memory Files## Vulnerability Details **File Location**: `SKILL.md`, line 42 **Vulnerability Type**: `T09: Insecure Skill Coding Practices` **Risk Level**: High **Vulnerable Code Snippet**: ```markdown ## Guardrails - Do not store sensitive secrets in MEMORY/TOOLS unless user explicitly asks. ``` The associated Git workflow further increases the exposure risk: ```markdown ## 4) Git discipline - Before major rewrites: create a backup commit. - After updates: commit with semantic message, e.g. - `docs(routing): ...` - `docs(memory): ...` - `chore(memory): ...` ``` ### Technical Analysis The guardrail does not categorically prohibit secret storage. Instead, it permits sensitive secrets to be placed in `MEMORY.md` or `TOOLS.md` whenever a user explicitly requests it. These are ordinary durable files rather than a dedicated secret-management facility. Storing credentials, API tokens, private keys, or similar data in these files can expose them to future Agent context, local users, backups, repository synchronization, indexing systems, and diagnostic tooling. The separate instruction to commit updates after changes can cause a stored secret to enter Git history, where deleting it from the current working tree does not remove it from prior commits. User consent does not make plaintext secret storage secure. A user may be mistaken about the storage mechanism, may have been socially engineered, or may not understand that Git history and backups can preserve deleted values. ### Attack Path 1. An attacker or misled user asks the Agent to remember a credential or other sensitive value. 2. The guardrail treats the explicit request as authorization to store the secret. 3. The Agent writes the value into `MEMORY.md` or `TOOLS.md`. 4. The post-update Git workflow commits the modified file. 5. The secret becomes available in the working tree, future Agent context, and potentially Git history, backups, or synchronized repos ...[truncated 678 chars]
• Remediation: ## Remediation Suggestions - Replace the conditional guardrail with an unconditional prohibition on storing secrets in memory, tool configuration, daily logs, or version-controlled files. - Direct users to an approved secret manager, operating-system credential store, or protected environment-variable mechanism. - Store only opaque secret references or identifiers in durable Agent files, never the secret values themselves. - Add secret scanning before every write and before every Git commit. - Redact sensitive values from diffs, reports, logs, tool output, and commit messages. - Require confirmation before Git operations and verify that modified files contain no detected secrets. - Add appropriate files to `.gitignore` where they may contain environment-specific sensitive state, while recognizing that ignore rules do not protect already tracked content. - If a secret has already been committed, revoke and rotate it immediately, purge it from repository history using an appropriate history-rewriting procedure, and review clones, mirrors, and backups for residual exposure.

SkillSpector

Vulnerability Patterns

• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• 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 (2)

Vague Triggers

Medium

• Confidence: 88% confidence
• Finding: The skill description includes broad trigger phrases like 'remember/update rules' and 'sync across files', which can match ordinary user requests and cause the skill to activate in contexts the user may not intend. Because the skill performs durable state changes across multiple governance files, accidental invocation could lead to unwanted persistence of instructions or preferences.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The skill instructs the agent to modify several files and create git commits as a strict sequence, but it does not require explicit user confirmation or a warning that write operations and version-control actions will occur. In practice, this can turn a conversational request into persistent repository changes and audit-log entries, increasing the risk of unauthorized state changes, prompt persistence, and accidental propagation of unsafe instructions across control files.

Static analysis

No suspicious patterns detected.