Marrow

Persistent agent memory for OpenClaw. Surface past failures, log decisions, and compound intelligence across sessions. Use when an agent should enforce Marro...

Security Scan

The skill's declared purpose (persistent agent memory) matches the single credential it requests, but its runtime instructions mandate frequent logging to an external service and rely on the agent to redact sensitive data — a combination that can easily lead to accidental exfiltration or overbroad data sharing.

Purpose & Capability

Name/description and required credential (MARROW_API_KEY) align: a persistent memory service legitimately needs an API key. No unrelated binaries, config paths, or extra credentials are requested.

Instruction Scope

SKILL.md forces the agent to call Marrow before/after every 'meaningful' action and to make other lifecycle calls. While redaction rules are documented, logging is mandatory and the instructions give the agent broad discretion about what to log. Because the skill is instruction-only, redaction/enforcement depends entirely on correct agent behavior — increasing risk of accidental leakage of sensitive context (files, API payloads, config, etc.).

Install Mechanism

No install spec or downloaded code is present (instruction-only). This minimizes filesystem/remote-install risk.

Credentials

Only MARROW_API_KEY is required, which is proportionate to the service. However, that single key likely grants the external Marrow service read/write access to all logged memories; combined with mandatory, frequent logging this can surface broad contextual data even though only one env var is requested.

Persistence & Privilege

always is false and the skill does not request system-wide configuration or other skills' credentials. Autonomous invocation is allowed (platform default) but not escalated by this skill.

What to consider before installing

This skill appears to do what it says (agent memory) but it mandates frequent logging to an external service and leaves redaction up to the agent. Before installing: 1) Confirm you trust getmarrow.ai and review their privacy, retention, and access policies; 2) Limit the MARROW_API_KEY scope where possible and use short-lived or revocable credentials; 3) Avoid enabling this skill in environments that handle sensitive PII, secrets, or regulated data unless you have contractual/data-residency guarantees; 4) Test in a sandbox with non-sensitive operations to verify what gets logged; 5) Consider monitoring outbound network calls and auditing logged memories on the Marrow side; 6) If you cannot guarantee safe redaction or vendor controls, do not enable mandatory automatic logging.

Use the existing @getmarrow/mcp tools directly. Do not invent wrappers, aliases, or local substitutes.

Operating rule

Treat Marrow logging as mandatory. The point is simple: every logged action improves future decisions, and every skipped action throws away usable failure prevention.

Required flow

1. Session start: call marrow_orient({ autoWarn: true }) before any other tool. If shouldPause=true, stop and review the warnings before acting.
2. Before every meaningful action: call marrow_auto({ action: "what you are about to do" }). Meaningful actions include file writes, edits, deploys, config changes, API calls, security changes, installs, deletes, and external sends.
3. After every meaningful action: call marrow_auto({ action: "what you did", outcome: "result", success: true|false }). If the action already happened, one combined marrow_auto call is fine.
4. For complex or multi-step work: use marrow_think before acting and marrow_commit after acting so you get pattern intelligence, loop detection, and explicit outcomes.
5. For quick one-shot work: marrow_run is acceptable when you want orient, think, and commit handled in one call.
6. Before unfamiliar or risky work: ask marrow_ask("plain English question") for prior failures, working patterns, or recommended next steps.

Redaction rules

• NEVER log secrets, API keys, tokens, passwords, OTPs, auth headers, PII, or sensitive file contents in any Marrow call. Log the action and outcome, not the payload.
• Do NOT log Marrow tool calls themselves. Calling marrow_orient, marrow_auto, marrow_think, marrow_commit, marrow_run, marrow_ask, or any marrow_* tool is infrastructure — not a loggable action.
• Strip credentials from outcomes before committing. Example: "deployed to CF" not "deployed to CF with token cfut_abc123".

Non-negotiables

• Never skip Marrow because the task feels small.
• Prefer fewer, clearer logs over noisy fragments.
• Record failures honestly. Bad news is training data.
• Read references/marrow-api.md when you need the tool quick reference.