Security audit
Security checks for vulnerabilities and agentic risk
This is a real local memory skill, but enabling its hook can automatically persist sensitive conversation details and expose them through broad multi-user/shared-mode controls.
Install only if you intentionally want long-term local assistant memory. Keep the automatic hook disabled unless broad conversation capture is acceptable, avoid secrets or regulated personal data, verify OPENCLAW_USER_ID is reliably set before multi-user use, keep private mode unless cross-user sharing is intended, and review the Ollama installer and dependency pinning before deployment.
The script analyzes both user_message and assistant_message, but stored records are framed as user memories such as '用户姓名' or '用户提到'. This can cause hallucinated, inferred, or assistant-suggested content to be written as if it were user-provided fact, creating integrity and privacy risks and poisoning long-term memory.
The file defines event-type filters for received and sent messages, but the actual handler never uses them and instead processes any non-command message regardless of event type/action. In a hook context, this can cause unintended capture and forwarding of content from additional event flows, increasing the amount of data sent to the external memory process beyond what the author likely intended.
The private-mode access control logic allows any shared memory with an empty visible_to list to be returned to any user. The comments imply access should be limited to the owner or specifically authorized users, but the implementation treats an empty list as globally readable, which can expose other users' stored memory content across tenants.
The deduplication logic claims to process only memories the user can access, but in private mode it includes all shared memories regardless of whether the requesting user was specifically authorized. Because deduplication can delete duplicates, this can modify or remove other users' shared records based on overly broad access assumptions.
The handler verifies that the requester matches the memory creator, but the final call to delete_memory(memory_id) does not propagate the verified identity or otherwise bind the authorization decision to the deletion action. If the downstream delete_memory function relies on caller-supplied context or performs no ownership check, this creates a time-of-check/time-of-use style authorization gap that can allow unauthorized deletion.
The code claims it forces the real user ID from the environment, but share_memory(memory_id, visible_to) is invoked without the verified requester_id. If share_memory does not independently verify ownership/authorization, an attacker could share another user's memory or alter visibility controls by referencing an arbitrary memory_id.
The skill explicitly states it listens to every user and assistant message and automatically evaluates/stores important information, but provides no user notice, consent flow, retention limits, or handling guidance for sensitive data. In a memory hook that processes all conversations, this creates a real privacy risk because personal, confidential, or regulated data may be captured and persisted without users understanding that behavior.
The README advertises automatic conversation memory storage but does not clearly warn that user conversations may be persisted locally and potentially contain sensitive data. Users may enable the hook without informed consent, causing unintended retention of private prompts, credentials, or personal information.
The shared mode documentation explains that users can switch to a shared memory mode, but it does not present a strong warning that stored memories become visible across users. In a multi-user environment, this can expose private conversation-derived data to unauthorized peers and lead to cross-user data leakage.
The skill documents automatic post-conversation memory capture and persistence, but it does not clearly require informed consent, retention limits, or disclosure of what categories of conversation data may be stored long-term. In a memory skill, this creates a real privacy and data-protection risk because users may unknowingly have sensitive personal, credential, or business information embedded and retained beyond the original session.
The code automatically extracts and persists highly sensitive data categories including personal identity, health, finance, relationships, and location without any visible notice, consent, confirmation, or minimization step. In a memory skill context this is especially dangerous because it creates durable records of sensitive user attributes that may later be surfaced, misused, or leaked across sessions.
The handler forwards raw conversation content to an external Python subprocess for storage/analysis without any visible consent, notice, or minimization. Because user messages may contain secrets, personal data, or regulated information, automatic transfer to another component and likely persistence in a vector database creates a real privacy and data-handling risk.
The code passes real user identifiers both in environment variables and on the command line to a subprocess. Command-line arguments may be exposed via process listings and logs, and duplicating identifiers across channels increases accidental disclosure risk without any user awareness or necessity demonstrated in this file.
The manifest explicitly advertises persistent storage, semantic memory, multi-user/private and shared modes, and deletion/sharing features, but it does not clearly warn users that potentially sensitive content may be retained on disk and exposed across users in shared mode. This creates a real privacy and data-retention risk because users or integrators may enable the skill without understanding that prompts, personal data, or secrets could be stored long-term and later recalled or shared.
Automatically processing every message for storage in a vector database creates a persistent data-retention surface where secrets, personal data, credentials, or sensitive business content can be embedded and later retrieved or exposed. The skill context makes this more dangerous, not less, because it is an always-on hook triggered on both message receipt and send, increasing the chance of broad collection across all conversations.
The scene rules explicitly target extraction of sensitive and personal data such as name, age, residence, relationships, health, finance, work details, habits, and goals for persistent storage. This broad semantic harvesting materially increases privacy risk because the system is designed to retain user profiling data beyond the immediate conversation without clear safeguards.
By processing both user and assistant messages for extraction, the script expands retention from explicit user disclosures to the full conversation, including assistant-generated paraphrases, guesses, or sensitive restatements. In this skill context that makes the memory store easier to poison and more likely to capture information the user never intended to save.
The stated behavior is to automatically evaluate and store important information from every conversation into a vector database. In context, this is not just a comment mismatch—the implementation indeed captures user content automatically, so the natural-language directive reflects a real data-retention design that can collect sensitive information without meaningful user control.
The handler takes essentially all non-command message content and sends it for memory processing, with no sensitivity checks, consent gate, or event scoping. In the context of a memory hook backed by an external script and likely persistence layer, this broad collection materially increases privacy risk and the chance of retaining credentials, personal data, or confidential workspace content.
The documented hook installation enables automatic, persistent processing of future conversations by copying files into the hooks directory and restarting the gateway. This creates session persistence that can continuously capture and store conversation-derived data, increasing privacy and security risk if users do not fully understand the scope of the hook.
# 复制 Hook 文件
mkdir -p ~/.openclaw/hooks/pidan-memory
cp HOOK.md handler.ts ~/.openclaw/hooks/pidan-memory/
cp auto_memory.py ~/.openclaw/workspace/memory/
The dependency is specified with a lower bound only, which allows installation of any newer version, including unexpected major releases or compromised upstream versions. This weakens build reproducibility and supply-chain control, though by itself it is usually a hygiene issue rather than an immediately exploitable flaw.
lancedb>=0.28.0
requests>=2.31.0
pyarrow>=16.0.0
The requests package is unpinned, so installs may resolve to different versions over time, including versions with known security defects or breaking changes. Because requests is commonly used for outbound network access and authentication flows, uncontrolled upgrades or vulnerable resolutions increase exposure.
lancedb>=0.28.0
requests>=2.31.0
pyarrow>=16.0.0
The pyarrow dependency is unpinned, allowing arbitrary newer versions to be installed without review. Given pyarrow's history of serious issues, including unsafe parsing/file-loading risks, lack of pinning increases the chance of introducing a vulnerable or incompatible build.
lancedb>=0.28.0
requests>=2.31.0
pyarrow>=16.0.0
The requirement allows requests versions affected by multiple published advisories, and the current spec does not demonstrate exclusion of vulnerable releases. In an agent skill, HTTP clients often handle remote URLs, redirects, sessions, and credentials, so known requests flaws can lead to credential leakage, request forgery, or TLS/session validation weaknesses depending on usage.
The pyarrow dependency is associated with multiple advisories, including arbitrary code execution when loading malicious data files, and the version spec may permit affected releases. In an agent environment that may ingest external datasets or serialized files, this materially increases risk because crafted input could trigger code execution or compromise the host process.