shared-memory-governor

• Outcome: Review
• Latest audit: Sep 12, 2026 · 4:26 AM UTC
• Version: 1.0.2

Overview

The skill is mostly coherent, but its example configuration enables recurring private-memory maintenance by default and preserves it after detach or unregister.

Before installing, review and change the privateMaintenance schedule to disabled unless you explicitly want recurring private-memory maintenance. Also verify which agents and subagents can read shared memory and confirm that detach/unregister behavior matches your expectation for stopping background activity.

A.I.G

Vulnerability Patterns

• System Persistence: Installs backdoors, hooks, services, or scheduled tasks that survive the run
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• 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 (1)

T06 · System Persistence

Error

• Location: assets/shared-memory.config.example.json:18

Finding

Recurring Private-Maintenance Schedule Is Enabled by Default and Persists After Detachment

Content

View full analysis

Vulnerability Details

File Location: assets/shared-memory.config.example.json:18-23; persistence behavior is documented in references/config-reference.md:193-196
Vulnerability Type: Persistent scheduled task enabled without a distinct schedule opt-in
Risk Level: High

Vulnerable Code Snippet

json

"privateMaintenance": {
  "enabled": true,
  "every": "72h",
  "time": "12:00",
  "recommended": true
}

The schedule lifecycle is documented as follows:

md

#### `schedules.privateMaintenance`
- Meaning: per-agent private long-term memory maintenance schedule
- Prepared by: `attach <agent>`
- Preserved after: `detach <agent>`, `unregister <agent>`

This conflicts with the safety requirements in SKILL.md:37-45:

md

- Keep recurring schedules disabled by default unless the user explicitly enables them

Never:

- silently enable recurring background schedules

Technical Analysis

The example configuration, which represents the documented default operating model, sets the per-agent private-maintenance schedule to enabled: true. The configuration reference states that attach <agent> prepares this schedule and that it remains after both detach <agent> and unregister <agent>.

Consequently, attaching an agent can establish recurring behavior without a separate, explicit user decision to enable background scheduling. Detaching or unregistering the agent does not terminate the schedule. Its lifecycle therefore extends beyond the attachment that created it and survives the initiating skill operation.

This behavior directly contradicts the Skill's stated requirement that recurring schedules remain disabled by default unless explicitly enabled by the user.

Attack Path

1. A user initializes the system using the supplied default/example configuration.
2. The user invokes attach <agent> to connect an agent to shared memory.
3. Attachment prepares the private-maintenance schedule while `schedules.privateMaintenance.e ...[truncated 1195 chars]

Remediation

View remediation

Remediation Suggestions

1. Change the default configuration so private maintenance is disabled:

json

"privateMaintenance": {
  "enabled": false,
  "every": "72h",
  "time": "12:00",
  "recommended": true
}

2. Require a separate, explicit user confirmation before creating or enabling any recurring task. Invoking attach <agent> alone should not constitute schedule consent.

3. During detach <agent> and unregister <agent>, disable or remove schedules created for that attachment by default. Retain a schedule only when the user explicitly requests retention.

4. Before attachment, display:

   • Whether a schedule will be created.
   • Whether it will be enabled.
   • Its interval, execution time, and timezone.
   • Its behavior after detachment and unregistration.

5. After detachment or unregistration, report every retained scheduled task prominently and provide the exact action needed to disable it.

6. Add validation that rejects enabled recurring schedules unless the configuration records an explicit user opt-in.

7. Make all documentation and examples consistent with the safety rule that recurring schedules are disabled by default.

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

Natural-Language Policy Violations

Medium

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

Finding

The setting "language": "en" imposes a specific language choice in the configuration. There is no indication in this file that users can opt in to English, choose another locale, or that the restriction is justified as region-specific behavior.

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Medium

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

Finding

This markdown file includes a natural-language policy constraint stating that final skill storage examples must be English, while review drafts and discussion may be Chinese. That sets a language policy without presenting user opt-in, alternatives, or a clear region-specific justification, which matches the language/locale policy violation criteria.

Content

No source excerpt is available for this finding.

Vague Triggers

Low

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

Finding

This manifest-style JSON enables inclusion of subagents via general flags like "includeSubagents": true and related sharing behavior, but it does not specify any explicit scope, activation constraints, or exclusion conditions for when those subagents should participate. In a manifest file, broadly scoped participation settings without narrowing context can create ambiguous invocation boundaries for the shared-memory behavior.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.