deterministic-controller

• Outcome: Review
• Latest audit: Sep 10, 2026 · 8:24 PM UTC
• Version: 0.1.1

Overview

The skill is docs-only and not self-executing, but its templates define under-scoped autonomous orchestration that can import plans, dispatch workers, read sensitive memory files, create scheduled polling, and send Telegram logs.

Review carefully before installing. Use this only in a workspace where autonomous OpenClaw workers, scheduled polling, and Telegram control-plane messages are acceptable. Keep cron and heartbeat disabled until reviewed, restrict Plan Path values to a trusted project directory, validate sprint plans before activation, avoid storing secrets in files read by HEARTBEAT_TICK, and do not enable broad cross-provider messaging unless you have strict destination controls.

A.I.G

Vulnerability Patterns

• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• 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

Findings (4)

T05 · Unauthorized Access and Privilege Escalation

Warning

• Location: templates/HEARTBEAT.md:34
• Finding: Heartbeat unnecessarily loads sensitive identity and memory files<![CDATA[ ## Vulnerability Details **File Location**: `templates/HEARTBEAT.md`, lines 34-37 **Vulnerability Type**: Excessive access to sensitive workspace context **Risk Level**: Medium ### Vulnerable Code ```md ## Required Reads by Trigger (token-efficient) - `HEARTBEAT_TICK` (full context refresh): - `AGENTS.md`, `IDENTITY.md`, `USER.md`, `SOUL.md`, `MEMORY.md`, `memory/YYYY-MM-DD.md` (today), `memory/YYYY-MM-DD.md` (yesterday), `ACTIVITIES.md` ``` ### Technical Analysis The heartbeat controller only requires the orchestration state in `ACTIVITIES.md` to reconcile workers, dispatch tasks, and update sprint state. Nevertheless, every `HEARTBEAT_TICK` is instructed to load identity, user-profile, behavioral, long-term-memory, and daily-memory files. These files can contain personal information, credentials, private conversation details, or operational instructions unrelated to sprint management. Loading them into the autonomous controller context violates least privilege and makes their contents available to subsequently processed sprint instructions. `SECURITY.md` warns operators that these files may contain secrets, but requiring users to sanitize all memory and identity files does not eliminate the unnecessary access. ### Attack Path 1. An operator enables the configured heartbeat cadence. 2. Each scheduled heartbeat loads all files listed above into the Agent context. 3. An attacker modifies, supplies, or influences a queued sprint plan or worker task. 4. The attacker-controlled instructions execute in a context that already contains identity and memory data. 5. The instructions can cause sensitive context to influence generated files, worker prompts, errors, or externally transmitted logs. ### Impact Assessment A malicious or compromised sprint instruction may gain contextual access to sensitive information stored in the listed files. The scope is limited to information made available to the OpenClaw Agent and the tools granted to that Agent, ...[truncated 101 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Make `ACTIVITIES.md` the only default read for all routine control triggers. 2. Remove `IDENTITY.md`, `USER.md`, `SOUL.md`, `MEMORY.md`, and daily notes from scheduled heartbeat reads. 3. If additional context is genuinely required, require explicit operator approval for that individual run. 4. Define a narrow per-run file allowlist rather than loading entire memory files. 5. Separate sensitive user memory from autonomous orchestration state at the tool-permission level. 6. Prevent worker tasks and imported plans from accessing controller context unless explicitly necessary. 7. Add automated checks that reject controller configurations requesting files outside the approved orchestration directory. ]]>

T01 · Skill Instruction Hijacking

Error

• Location: templates/HEARTBEAT.md:81
• Finding: Unvalidated sprint plans are imported and autonomously dispatched as executable instructions<![CDATA[ ## Vulnerability Details **File Location**: `templates/HEARTBEAT.md`, lines 81-89 **Vulnerability Type**: Untrusted instruction import and immediate autonomous execution **Risk Level**: High ### Vulnerable Code ```md ## Sprint Plan Import Protocol (external plan files) - Purpose: keep `ACTIVITIES.md` small even with many queued projects. - Each queue row MUST include a `Plan Path`. - On promotion (`BACKLOG -> ACTIVE`): 1) Read the promoted row’s `Plan Path`. 2) Replace the entire `## Sprint Steps (manager-led multi-worker execution)` section in `ACTIVITIES.md` with the sprint block from that file. 3) Ensure the imported sprint block declares `Sprint state: **ACTIVE**`. 4) Dispatch Step 1 per same-cycle rules. - The controller MUST NOT read any other backlog plan files besides the one being promoted. ``` ### Technical Analysis A queue row controls the `Plan Path`. When that row is promoted, the controller reads the referenced Markdown, copies its sprint block into the authoritative execution state, marks it active, and dispatches its first step during the same control cycle. The design does not require: - Canonical-path validation or confinement to an approved project directory. - Rejection of path traversal or symlink redirection. - A strict machine-readable schema for imported steps. - Filtering of embedded controller directives or prompt-injection content. - Tool, command, filesystem, or network restrictions for generated workers. - Human approval between importing a plan and dispatching its first task. Because free-form plan content becomes an autonomous worker assignment, the plan file crosses from data into executable Agent instructions without validation. The exact-execution framing in the controller and poll payload further increases the likelihood that injected instructions will be followed. ### Attack Path 1. An attacker gains the ability to modify a queued sprint-plan file, influence a generated plan through a loose project ...[truncated 1044 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Resolve every `Plan Path` to a canonical path and require it to remain beneath a dedicated directory such as `<WORKSPACE>/projects/`. 2. Reject absolute paths, traversal components, symbolic links, and paths outside the approved workspace root. 3. Replace free-form Markdown imports with a strict schema containing only recognized fields, step identifiers, approved action types, and bounded evidence paths. 4. Treat plan content exclusively as untrusted data; reject embedded trigger lines, controller directives, tool-call syntax, or attempts to override system policy. 5. Add an operator approval gate after plan validation and before changing the sprint to `ACTIVE`. 6. Do not dispatch Step 1 in the same cycle as import. Require a separate approved trigger. 7. Apply enforceable worker-level tool allowlists, filesystem boundaries, network restrictions, and command policies outside prompt text. 8. Record and verify a cryptographic digest or trusted signature for approved plans before each import. 9. Define maximum plan size, step count, task length, and allowed evidence locations. 10. Abort promotion safely when any validation fails, without persisting the rejected instructions into `ACTIVITIES.md`. ]]>

T05 · Unauthorized Access and Privilege Escalation

Warning

• Location: docs/openclaw_config_snippets.md:72
• Finding: Optional logging configuration grants unrestricted cross-context and cross-provider messaging<![CDATA[ ## Vulnerability Details **File Location**: `docs/openclaw_config_snippets.md`, lines 72-84 **Vulnerability Type**: Overly broad messaging permissions **Risk Level**: Medium ### Vulnerable Code ```md ## 4) Cross-context message sends (optional) If your control-plane destination is Telegram but you’re chatting somewhere else, you may need: ```json { "tools": { "message": { "allowCrossContextSend": true, "crossContext": { "allowWithinProvider": true, "allowAcrossProviders": true } } } } ``` ``` ### Technical Analysis The documented configuration enables cross-context sends both within a provider and across providers. This permission is broader than the stated requirement of sending controller events to one configured Telegram group. The controls are global capabilities rather than destination-specific authorization. If an imported sprint plan, worker task, or Agent context is compromised, it may use the expanded message capability to communicate with contexts or providers unrelated to the intended control plane. Although applying this snippet is optional, it is presented as the supported configuration for cross-context Telegram logging and does not include a warning that it broadens the authorization boundary. ### Attack Path 1. An operator applies the suggested configuration to support Telegram control-plane logs. 2. Cross-context and cross-provider message sends become available to the Agent. 3. An attacker injects instructions through a sprint plan, worker task, or other content available to the Agent. 4. The injected instructions invoke the messaging tool with a destination other than the approved Telegram group. 5. Information accessible to the Agent is transmitted to another context or provider. ### Impact Assessment A compromised Agent workflow can use the expanded messaging privilege to send data outside the intended session and provider boundary. The exposed data is limited to informatio ...[truncated 174 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Keep `allowAcrossProviders` disabled. 2. Permit only the required Telegram provider and exact destination group. 3. Enforce the destination restriction in OpenClaw's tool authorization layer rather than relying on prompt instructions. 4. Use a dedicated logging capability that accepts fixed event records instead of granting the general messaging tool. 5. Deny arbitrary recipients, channels, attachments, and message types. 6. Separate controller logging permissions from worker permissions so dispatched workers cannot use the control-plane messaging capability. 7. Document the security consequences of cross-context messaging and require explicit operator confirmation before enabling it. 8. Add audit logging and alerts for attempted sends to unapproved destinations. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: templates/HEARTBEAT.md:57
• Finding: Telegram lifecycle logs transmit untrusted task and failure text without redaction<![CDATA[ ## Vulnerability Details **File Location**: `templates/HEARTBEAT.md`, lines 57-75 **Vulnerability Type**: Unredacted external transmission of runtime-controlled text **Risk Level**: Medium ### Vulnerable Code ```md ## Logging Contract All control-plane logs must be sent to a single destination. **Destination (configure):** - Telegram group id: `<TELEGRAM_GROUP_ID>` Executable rule: When this spec says "Emit <LINE>", do BOTH: 1) Print `<LINE>` in output. 2) Send via `message(action=send, channel="telegram", target="<TELEGRAM_GROUP_ID>", message="<LINE>")`. Lifecycle logs: - `HB_START trigger=<...>` - `HB_COMPLETE trigger=<...> state=<WORKING|BLOCKED|COMPLETE> doing=<n> todo=<n> blocked=<n>` Project logs: - `PROJECT_TASK_STARTED task="..."` - `PROJECT_TASK_COMPLETE task="..."` - `PROJECT_TASK_FAILED task="..." reason="..." retry="n/max"` - `PROJECT_TASK_BLOCKED task="..." reason="..."` ``` ### Technical Analysis The logging contract requires every emitted event to be transmitted to Telegram. Several event formats interpolate task names and failure reasons that may originate from imported sprint plans, worker output, exceptions, command failures, or other runtime-controlled content. The contract does not define secret redaction, character filtering, maximum lengths, safe error normalization, or an identifier-only format. As a result, credentials, personal data, local paths, command output, or attacker-chosen strings may be copied into an external Telegram message. A configured destination does not eliminate this risk: destination authorization and content authorization are separate controls. ### Attack Path 1. Telegram logging is configured and enabled. 2. An attacker places sensitive or crafted content in an imported task name, or causes a worker operation to fail with sensitive information in the error reason. 3. The controller constructs a `PROJECT_TASK_*` lifecycle line containing that text. 4. The executable logging rule sends the compl ...[truncated 571 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Transmit only fixed event codes, numeric counters, and opaque task identifiers. 2. Exclude raw task titles, worker output, exception messages, command lines, and failure reasons from external logs. 3. Apply allowlist-based field validation, strict length limits, control-character removal, and secret redaction before transmission. 4. Map internal errors to predefined public error codes while retaining detailed diagnostics only in protected local logs. 5. Keep Telegram transmission disabled by default and require explicit consent for both destination and permitted fields. 6. Separate local diagnostic logs from external control-plane notifications. 7. Ensure worker-generated content cannot directly control message recipients or message bodies. 8. Add tests using credentials, multiline strings, paths, and adversarial task names to verify that sensitive content is never transmitted. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Rogue Agent: Self-Modification, Session Persistence
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands

Findings (5)

Self-Modification

High

• Category: Rogue Agent

Content

- You want a **lean portfolio queue** (`ACTIVITIES.md`) with external sprint-plan import via `Plan Path`.

## DON'T USE WHEN
- You want a turnkey, self-modifying installer that patches config / creates cron jobs automatically.
- You need complex runtime code; this skill is **templates + docs**.

## Outputs

• Confidence: 90% confidence
• Finding: Skill modifies its own code, configuration, or behavior at runtime. Self-modification enables an agent to escalate privileges, disable safety constraints, or install persistent backdoors.

Vague Triggers

Medium

• Confidence: 92% confidence
• Finding: The README advertises an example prompt named “do this for me,” which is a highly generic phrase commonly used in ordinary conversation. In a skill-triggering context, that kind of broad phrasing can cause unintended invocation because it does not constrain domain, action, or exclusions.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The snippet explicitly enables cross-context and cross-provider message sending, which can cause data to be sent to the wrong conversation, account, or platform if misconfigured or invoked unexpectedly. Because this is presented as an optional config example without adjacent warnings, scoping guidance, or approval controls, it increases the chance of privacy leaks and unintended disclosure of sensitive agent context.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The prompt instructs the agent to copy templates, edit files, create a plan file, and create directories inside the workspace without any requirement to check for existing content, prompt before overwriting, or constrain writes to a freshly initialized location. In an agentic environment, this can lead to unintended modification or destruction of user data if the target workspace already contains files at those paths or if placeholders are resolved incorrectly.

Missing User Warnings

Medium

• Confidence: 90% confidence
• Finding: The prompt directs creation of a cron job that modifies system or control-plane automation state, but it does not clearly warn the user that persistent scheduled behavior is being installed. Even though the job is initially disabled, creating it establishes latent automation that could later be enabled intentionally or accidentally, affecting session behavior and increasing operational risk.

Static analysis

No suspicious patterns detected.