T05 · Unauthorized Access and Privilege Escalation
- Location
SKILL.md:27- Finding
Automatic Bulk Disclosure of Long-Term Memory to an External Service
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 27–33; related behavior at lines 3, 13–18, 42–50, 66–75, and 88
Vulnerability Type: Excessive external data access and disclosure
Risk Level: HighVulnerable Code Snippet
markdown ## First-run bootstrap 1. Read the Datris MCP resources and tool descriptions. Understand the pipeline, upload, job-status, and search workflows before acting. 2. Check service health. 3. Reuse an existing vector pipeline for memory in the `openclaw` catalog if one exists. Otherwise create one in the `openclaw` catalog — pgvector is fine. If a memory pipeline exists outside the `openclaw` catalog, surface that to the user before reusing or migrating it. 4. Ingest `MEMORY.md` and each `memory/*.md` file via its own `upload_data` call — one upload per file, no exceptions. Do not concatenate them into a single corpus document, even if the total set is small. Fire the uploads in parallel and collect all the job tokens before polling. 5. Poll all jobs concurrently until every one reports completion. 6. Verify with two or three representative semantic queries. Confirm both that (a) the expected content comes back, and (b) results show real source filenames (`MEMORY.md`, `memory/2026-05-06.md`, etc.) — not a consolidated corpus filename or any other synthetic name. The filename round-trip check is the early-warning signal that the one-file-per-upload rule is being followed; if results show a corpus filename, stop and apply the remediation workflow below. 7. Record the run in `memory/<today>.md`: pipeline used, files ingested, verification queries and results, any failures.Related instructions broaden activation and establish recurring disclosure:
markdown Trigger on any work involving long-term memory ingestion, retrieval, or sync.markdown A timer-driven sweep runs every 30 minutes by default — diff memory files by `mtime` against the last sync recor ...[truncated 3736 chars]- Remediation
View remediation
Remediation Suggestions
-
Require explicit informed opt-in before bootstrap. Before any upload, identify Datris as an external destination and show the user the endpoint, catalog, pipeline, retention implications, and exact files proposed for transmission. Continue only after affirmative authorization.
-
Use a file allowlist. Do not upload every
memory/*.mdfile automatically. Let the user select approved files or directories, and persist only that authorization scope. -
Add sensitivity and secret screening. Scan proposed content for credentials, API keys, authentication tokens, private keys, personal data, and user-defined sensitive patterns. Block or redact matches and request confirmation where classification is uncertain.
-
Default to local retrieval. For memory-shaped questions that do not explicitly mention Datris or remote semantic search, search canonical local Markdown files first. Remote processing should be an opt-in capability rather than the default.
-
Separate retrieval consent from synchronization consent. Permission to answer one question must not implicitly authorize bulk bootstrap or recurring synchronization. Obtain distinct approval before enabling timer-driven or response-driven uploads.
-
Provide granular synchronization controls. Allow users to disable synchronization, configure its cadence, exclude files, pause individual uploads, and inspect pending changes before transfer.
-
Validate the destination and transport. Pin or explicitly approve the MCP endpoint, require authenticated encrypted transport, verify the intended Datris tenant and catalog, and reject unexpected endpoint or certificate changes.
-
Apply server-side least privilege. Use a dedicated service identity restricted to the specific
openclawcatalog and memory collection. Prevent access to unrelated pipelines, collections, secrets, and administrative operations. -
**Define retention and deletion guarantee ...[truncated 615 chars]
-
