T09 · Insecure Skill Coding Practices
- Location
SKILL.md:147- Finding
Persistent Storage of Inferred Personal Observations Without Per-Update Consent
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This personalization skill is mostly transparent about local memory use, but it gives broad access to profile files and permits persistent logging of inferred user habits without clear per-update consent.
Install only if you are comfortable with a skill that reads local memory/profile files and writes persistent preference records. Before use, narrow its activation, remove or require confirmation for automatic daily observations, avoid storing contacts/locations/schedules unless explicitly needed, and review the memory files regularly.
SKILL.md:147Persistent Storage of Inferred Personal Observations Without Per-Update Consent
SKILL.md:22Overbroad Access to Identity and Personal Profile Data
The description mixes 'triggered when applying the PAHF loop' with general behavioral guidance, making it unclear whether the skill should activate as an explicit tool or just serve as internal methodology. This ambiguity can lead to inconsistent invocation and accidental use of memory features when the agent should simply answer normally.
The trigger conditions are broad enough to match many ordinary conversations, such as any expression of habits, corrections, or decisions with multiple valid options. That increases the chance of unintended invocation, causing unnecessary memory access, preference inference, and persistent storage in contexts where the user did not expect personalization logic to activate.
The skill explicitly supports cross-session storage and tracking of preferences over time in local files, including data from USER.md and IDENTITY.md. Session persistence is the skill's purpose, but it still creates real privacy and profiling risk if retention scope, user approval, and deletion/review controls are not rigorously enforced.
scope: |
This skill will:
- Read your preference memory files (MEMORY.md, USER.md, etc.)
- Write preference updates to these files
- Track preference changes over time
Your preferences will be stored locally in ~/.openclaw/workspace/memory/
The skill states that user consent is required for persistent preference storage, but the feedback-integration logic then allows some preference writes to occur automatically in daily logs without explicit confirmation. This contradiction can cause personal data to be stored persistently even when the user has not clearly agreed to that specific retention behavior, undermining privacy expectations and informed consent.
Encouraging the agent to 'remember this for future interactions' is a persistence mechanism that can inject user-provided instructions or preferences into future sessions. In a personalization skill this is expected behavior, but it becomes dangerous when combined with broad triggers and inconsistent consent because it can carry forward manipulated, outdated, or unauthorized context.
# Feedback Type Judgment
if user explicitly corrects:
This is an important preference → Update MEMORY.md
Ask: "Should I remember this for future interactions?"
elif user expresses new habit:
This is a variable preference → Update memory/YYYY-MM-DD.md
The instruction to 'Record without asking' authorizes autonomous persistence of inferred user habits into a dated memory log. Because the skill reads and writes personal and identity-related files, this creates a real risk of silently storing behavioral data without meaningful consent or verification.
elif user expresses new habit:
This is a variable preference → Update memory/YYYY-MM-DD.md
Record without asking (daily log)
elif user simply confirms:
Validated preference → Optionally record
The write-confirmation table says some preference updates and observations do not require confirmation, which directly conflicts with the earlier statement that user consent is required for persistent preference storage. In practice, this can normalize silent retention of user behavior and create unauthorized profile building across sessions.
Skill injects content designed to persist in agent memory or context across interactions. Persistent injection can alter agent behavior long after the initial interaction.
User: "From now on, always send reports in PDF format"
PAHF Response:
1. Pre-action: ✓ Clear instruction, no clarification needed
The example operationalizes the same unsafe pattern by instructing the agent to record a preference with 'No confirmation needed.' Examples are often followed as normative guidance, so this increases the likelihood that agents will persist user preferences automatically in routine tasks.
### Example 3: Preference Drift Detection
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
1. **Don't Implicitly Assume**: Ask if uncertain
2. **Don't Over-record**: Recording every detail creates noise
3. **Don't Ignore Changes**: "This time is different" is an important signal
4. **Don't Store Without Consent**: Ask for significant new preferences
---
The document says sensitive data must never be stored, but later defines free-form personal fields such as home, work, frequent places, contacts, and routines that can easily capture health, financial, credential-adjacent, or other sensitive details in practice. This mismatch creates a policy gap where the implementation schema invites exactly the kind of data the privacy guidance claims to forbid.
Restricting language preference to zh or en hard-codes an unjustified limitation that can misrepresent users and force inaccurate storage of identity or communication preferences. While not a classic security exploit, it is a data-handling flaw that can lead to exclusion, incorrect personalization, and unsafe assumptions in multilingual contexts.
The schema explicitly permits storing personal contacts, locations, and schedules, which goes beyond narrow preference personalization and creates a repository of sensitive personal profile data. Even if intended for convenience, these fields increase privacy risk, enable over-collection, and could expose users to tracking or social engineering if memory is misused or leaked.
The design encourages persisting behavior-guiding context across future interactions, which can become a durable prompt/context injection channel if incorrect, manipulated, or adversarially induced preferences are stored. In a personalization framework, this is particularly risky because future agent actions may be silently steered by stale or maliciously planted memory.
- Same feedback appears 3+ times
- Preference persists over 2 weeks
**With confirmation**: Ask "Should I remember this for future interactions?"
### When to Only Update Short-term Memory (memory/YYYY-MM-DD.md)
The schema authorizes automatic logging of daily observations without confirmation, which allows the agent to infer and persist user traits without explicit consent. In the context of a memory system, this increases the risk of covert profiling, inaccurate inferences, and unauthorized accumulation of behavioral data over time.
- Temporary needs
- Patterns under observation
**No confirmation needed**: Daily observations are logged automatically.
### Preference Expiration Handling
No suspicious patterns detected.