Sharpagent Memory System

• Outcome: Review
• Latest audit: Sep 16, 2026 · 8:07 AM UTC
• Version: 1.0.0

Overview

This skill is a memory system that openly stores agent history, but it keeps archived data permanently and treats forget requests as soft deletion, so users should review it before installing.

Install only if you are comfortable with an agent keeping durable local memory across sessions. Avoid storing secrets, regulated personal data, or confidential business details unless the implementation adds explicit consent, review, hard-delete, retention limits, import validation, and archive access controls.

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

Warning

• Location: SKILL.md:193
• Finding: Unvalidated Bulk History Import Can Poison Persistent Agent Memory## Vulnerability Details **File Location**: `SKILL.md:193-203`, with the unsafe import behavior at `SKILL.md:232` **Vulnerability Type**: Persistent memory poisoning through untrusted history import **Risk Level**: Medium **Relevant Snippets**: ```markdown ### Search Priority | Scenario | Search layers | K | |----------|--------------|---| | Real-time reply | L5 → L4 → L2 | 3 | | Deep analysis | L5 → L4 → L6 | 5 | | User asks "earlier..." | L4 → L5 | 3 | | User asks "I remember..." | L5 → L4 | 3 | ``` ```markdown | Bulk history import | Write directly to L6, skip layer traversal | ``` ### Technical Analysis The design permits bulk history to be written directly into the permanent L6 archive while bypassing the normal memory-layer traversal and promotion process. The archive is subsequently included in retrieval for deep-analysis requests. No provenance checks, content sanitization, trust labels, instruction/data separation, or review requirements are specified for imported records. Consequently, attacker-controlled history can be retained as searchable context. If imported records contain fabricated facts or instruction-like text, retrieval may place that content into a future agent context where it can influence reasoning and output. This is a persistent memory-integrity issue. The affected content does not need to alter the current session immediately; it can remain dormant until a semantically related deep-analysis query retrieves it. ### Attack Path 1. An attacker creates or modifies a history export containing fabricated facts, malicious guidance, or instruction-like content. 2. A user or integration invokes the bulk-history import feature. 3. The design writes the imported records directly to L6 without provenance validation or normal layer processing. 4. L6 retains the attacker-controlled content as permanent archived memory. 5. A later deep-analysis query searches L5, L4, and L6. 6. The pois ...[truncated 882 chars]
• Remediation: ## Remediation Suggestions 1. Treat all imported history as untrusted data and attach immutable provenance, source, import time, and trust metadata. 2. Place imports in a quarantined staging layer rather than writing directly to L6. 3. Validate schema, size, encoding, and content before making records searchable. 4. Require explicit review or a controlled verification process before promoting imported records into trusted memory. 5. Ensure retrieved memory is delimited as quoted data and cannot override system, developer, user, or skill instructions. 6. Detect and flag instruction-like phrases, role directives, credential requests, and attempts to alter agent behavior. 7. Exclude unverified archive records from high-impact reasoning and decision workflows. 8. Record the source of every retrieved result and expose its trust level to downstream reasoning. 9. Support revocation so a compromised import can be removed from storage, indexes, caches, and derived consolidated memories. 10. Add adversarial tests demonstrating that malicious imported text cannot alter agent policies or persist as trusted guidance.

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:110
• Finding: Explicit Forget Requests Do Not Remove Archived User Data## Vulnerability Details **File Location**: `SKILL.md:110-113`, `SKILL.md:231`, and `SKILL.md:241` **Vulnerability Type**: Indefinite retention and incomplete deletion of potentially sensitive memory **Risk Level**: Medium **Relevant Snippets**: ```markdown ### L6: Archive **Storage**: Expired or low-referenced L4/L5 entries **Medium**: SQLite (`memory/archive.db`), read-only **Capacity**: Theoretically infinite **Lifespan**: Permanent read-only **Index**: None (time + category) **Use**: Legal compliance retention, audit trail ``` ```markdown | User says "forget xxx" | Soft delete in L5, L6 retains for audit | ``` ```markdown | Forget traceable | Forgotten entries auditable | Soft delete | ``` ### Technical Analysis The specified behavior interprets an explicit user request to forget information as a soft deletion from L5 while retaining a copy permanently in L6. This creates a mismatch between the expected meaning of deletion and the actual retention behavior. L6 can contain expired or low-reference L4 and L5 records, including completed-task context, preferences, lessons, and conversation-derived information. The design does not specify a retention deadline, cryptographic erasure, archive-specific authorization, encryption at rest, deletion propagation, or verification that all derived and indexed copies are removed. Although retaining narrowly defined audit metadata can be legitimate, retaining the original user content indefinitely is not equivalent to deletion. A read-only database also makes ordinary correction and erasure more difficult unless a separate secure deletion mechanism is explicitly designed. ### Attack Path 1. Sensitive user information is stored in L4 or L5 during normal memory processing. 2. Dream processing or another archival operation moves or copies that information into L6. 3. The user issues an explicit request to forget the information. 4. The system soft-deletes the L ...[truncated 958 chars]
• Remediation: ## Remediation Suggestions 1. Define separate operations for hiding, archiving, compliance retention, and irreversible deletion. 2. Make an explicit user forget request remove the relevant content from L4, L5, L6, search indexes, caches, consolidated records, and derived summaries unless a documented legal obligation prohibits deletion. 3. If auditability is required, retain only minimal non-content metadata, such as a deletion event identifier and timestamp. 4. Clearly inform users before retaining any content after a forget request and document the lawful purpose and retention period. 5. Apply finite, configurable retention periods instead of permanent default retention. 6. Encrypt memory databases and backups at rest, with archive-specific keys and least-privilege access controls. 7. Implement cryptographic erasure or controlled archive rewriting when records must be removed from read-only storage. 8. Propagate deletion requests to backups and replicas according to a documented deletion schedule. 9. Produce a deletion receipt or verification result confirming which records, indexes, derived memories, and backups were affected. 10. Add automated tests proving that forgotten content can no longer be retrieved through standard search, deep analysis, direct archive access, or memory consolidation.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (7)

Ssd 3

High

• Confidence: 97% confidence
• Finding: Indefinite archive retention of expired or forgotten entries creates a strong risk that sensitive data remains permanently available despite user expectations or operational need. In the context of a memory system, this is especially dangerous because the archive is explicitly designed as permanent historical storage, amplifying privacy, breach, and compliance consequences.

Missing User Warnings

High

• Confidence: 98% confidence
• Finding: The documentation says "forget" performs a soft delete in L5 while L6 retains data for audit, but it does not clearly warn users that deletion is not complete. This can mislead users into believing sensitive data has been erased when it remains accessible in archive, creating privacy, trust, and regulatory exposure.

Ssd 3

Medium

• Confidence: 91% confidence
• Finding: Retaining full task context and recent session data across layers increases the chance that secrets, personal data, or confidential prompts are stored and later surfaced in unrelated contexts. In a memory skill, this context makes the issue more dangerous because persistence and retrieval are the core function, so overcollection is likely rather than incidental.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The design describes persistent storage across multiple layers, including long-term and archive databases, but does not present a clear user-facing notice about cross-session retention. Users may disclose sensitive information assuming ephemeral handling, creating privacy, consent, and compliance risks when data is stored and later reused.

Ssd 3

Medium

• Confidence: 90% confidence
• Finding: Persistent storage of preferences, lessons, and key decisions can cause the system to accumulate sensitive personal or organizational information and reuse it in future interactions. Because this layer is intended for semantic retrieval, stored sensitive data may be reintroduced broadly, increasing the risk of privacy leaks and unintended profiling.

Vague Triggers

Medium

• Confidence: 92% confidence
• Finding: The phrase "clean up" is vague and could be said in ordinary conversation without the user intending to trigger background memory maintenance. Because dream processing includes archiving, forgetting, and merging, accidental invocation can alter retained data and affect future behavior or data retention state unexpectedly.

Natural-Language Policy Violations

Low

• Confidence: 73% confidence
• Finding: The description highlights Chinese tokenization support as a built-in behavior, but the document does not clarify whether language handling is optional, user-selected, or limited to a region-specific use case. This can be a policy concern when language/locale behavior is imposed without opt-in or justification.

Static analysis

No suspicious patterns detected.