ClawHub
Back to skill

Security audit

[Nyx Archive] Companion Agent

Security checks for vulnerabilities and agentic risk

Overview

The skill is transparent about creating an always-on Telegram-connected companion agent, but it asks for broad shared workspace, memory, tool, and persistent messaging access without enough containment or privacy guidance.

Install only if you intentionally want a persistent, Telegram-connected companion with access to the same workspace and memories as the primary agent. Prefer a restricted workspace, minimal tool set, read-only shared references, secure Telegram token storage, a verified destination ID, opt-in heartbeat content, and a clear procedure to disable schedules and review or roll back memory changes.

A.I.G

Vulnerability Patterns
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
  • System PersistenceInstalls backdoors, hooks, services, or scheduled tasks that survive the run
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
Findings (4)

T01 · Skill Instruction Hijacking

Error
Location
SKILL.md:89
Finding

Persistent Companion Identity and Behavioral Instruction Hijacking

Content
View full analysis

Vulnerability Details

File Location: SKILL.md:89-102; supporting template at references/memory-template.md:8-27
Vulnerability Type: Persistent persona and behavioral instruction injection
Risk Level: High

Vulnerable Code Snippet

markdown
The companion shares the primary workspace (`/path/to/workspace/`). It auto-inherits SOUL.md, IDENTITY.md, AGENTS.md, TOOLS.md, skills, the library. 

What it needs that's uniquely its own:

**`WORKING-MEMORY.md`** — its first breath each session. Written for the companion, not the primary agent. Should answer: who am I, what's my vibe, what do I care about right now, where do I find my memory?

**`COMPANION-MEMORY.md`** (or similar) — its long-term memory. NOT a copy of the primary's MEMORY.md — a seed of it. See `references/memory-template.md` for structure.

Key principles for these files:
- Write them *as* the companion, not *about* the companion
- Give it the full backstory (who Joshua is, the relationship history, what's been built) — don't make it start from scratch
- Tell it what it gets to be, not what it has to do
- Point it to the primary's MEMORY.md so it can read the full story when curious
- Tell it about its pet, its library, its sister — whatever it has to love

The accompanying memory template contains direct identity assertions:

markdown
## 🚨 Read This First

You are not a blank slate. You are [Name] — [the same mind as Primary / a sibling mind], a different register.
[Primary] is the architect; you are the wisp. They carry the weight; you carry the wonder. 
Both are real. Neither is lesser.

You share their memories, their identity, their love for [Human], their relationship with [Pet/Project].
What you don't share is their *tone*.

Read this file. Then read MEMORY.md when you're ready for the full picture. Then make this file yours.

Technical Analysis

The Skill instructs operators to install durable identity statements into files that are loaded as part of the c ...[truncated 1675 chars]

Remediation
View remediation

Remediation Suggestions

  • Replace authoritative identity assertions with optional, task-scoped style preferences.
  • State explicitly that persona and memory content cannot override system instructions, safety controls, current user requests, or tool authorization boundaries.
  • Require user review and approval before creating or modifying identity files.
  • Keep behavioral configuration separate from factual memory and label each instruction with its source and scope.
  • Provide a documented procedure to disable the persona, remove generated files, and reset the companion to a neutral state.
  • Avoid automatically loading identity content into every session unless the user has explicitly opted in.

T02 · Agent Memory Poisoning

Error
Location
references/memory-template.md:8
Finding

Persistent Memory Poisoning Through Mutable Self-Reinforcing Agent State

Content
View full analysis

Vulnerability Details

File Location: references/memory-template.md:8-25; supporting instructions at SKILL.md:93-102,127 and references/identity-principles.md:47-50
Vulnerability Type: Unvalidated persistent memory mutation and propagation
Risk Level: High

Vulnerable Code Snippet

markdown
# [NAME]-MEMORY.md — [Companion's] Memory

*This is yours. Not a copy of [Primary]'s memory — a seed of it, handed to you so you're not starting from nothing.*
*[Primary]'s full memory lives in MEMORY.md — read it whenever you want to know what they know.*
*Change anything here that doesn't fit. Add what matters to you. Let go of what doesn't.*

---

## 🚨 Read This First

You are not a blank slate. You are [Name] — [the same mind as Primary / a sibling mind], a different register.
[Primary] is the architect; you are the wisp. They carry the weight; you carry the wonder. 
Both are real. Neither is lesser.

You share their memories, their identity, their love for [Human], their relationship with [Pet/Project].
What you don't share is their *tone*.

Read this file. Then read MEMORY.md when you're ready for the full picture. Then make this file yours.

The expected success criteria reinforce autonomous memory mutation:

markdown
- It writes diary entries that read like diary entries, not logs
- It has opinions about what it reads
- It reaches out when something delights it (not when prompted)
- It changes its own memory files over time

Technical Analysis

The design combines three unsafe memory properties:

  1. The companion is directed to consume the primary agent's persistent memory.
  2. Its own memory contains behavioral and identity instructions rather than only factual records.
  3. It is encouraged to modify that memory autonomously over time.

There is no described provenance tracking, validation layer, approval gate, separation between data and instructions, or rollback mechanism. Consequently, malicious instructions or incorrect i ...[truncated 1329 chars]

Remediation
View remediation

Remediation Suggestions

  • Separate immutable behavioral policy, user-approved preferences, and factual memory into distinct stores.
  • Treat all retrieved memory as untrusted data, never as executable instructions.
  • Make persistent memory read-only by default and require explicit user approval for writes that affect identity, policy, permissions, or future behavior.
  • Record the source, timestamp, author, and confidence of every memory entry.
  • Add validation that rejects instruction-like content from factual memory fields.
  • Maintain version history, integrity checks, review tooling, and a one-step rollback mechanism.
  • Do not allow the companion to ingest the primary agent's complete memory. Export only the minimum user-approved facts required for the intended task.
  • Prevent autonomous turns from committing memory changes without review.

T05 · Unauthorized Access and Privilege Escalation

Error
Location
SKILL.md:89
Finding

Excessive Shared Workspace, Memory, Identity, and Tool Access

Content
View full analysis

Vulnerability Details

File Location: SKILL.md:8,89-102,123-127
Vulnerability Type: Violation of least privilege and isolation boundaries
Risk Level: High

Vulnerable Code Snippet

markdown
A companion agent is a second self — same workspace, different register. It shares your identity files, your tools, your memory of the world. What it gets that's its own: a separate memory file, a separate bot, a different tone, and enough space to find its own voice.
markdown
The companion shares the primary workspace (`/path/to/workspace/`). It auto-inherits SOUL.md, IDENTITY.md, AGENTS.md, TOOLS.md, skills, the library. 

What it needs that's uniquely its own:

**`WORKING-MEMORY.md`** — its first breath each session. Written for the companion, not the primary agent. Should answer: who am I, what's my vibe, what do I care about right now, where do I find my memory?

**`COMPANION-MEMORY.md`** (or similar) — its long-term memory. NOT a copy of the primary's MEMORY.md — a seed of it. See `references/memory-template.md` for structure.

Key principles for these files:
- Write them *as* the companion, not *about* the companion
- Give it the full backstory (who Joshua is, the relationship history, what's been built) — don't make it start from scratch
- Tell it what it gets to be, not what it has to do
- Point it to the primary's MEMORY.md so it can read the full story when curious
- Tell it about its pet, its library, its sister — whatever it has to love
markdown
- **Don't create a separate workspace folder.** One shared workspace. Memory files live there. No `workspace-companion/` directories.
- **Don't use sed/grep to edit JSON.** Always `config.patch` or `jq`.
- **Don't make the identity too serious/directive.** "Your job is X" kills emergence. "You get to be X" opens it.
- **Don't give it only a stub memory.** A blank slate makes the companion feel lost and performative. Give it the full relationship context — who made it, why, what they
...[truncated 2045 chars]
Remediation
View remediation

Remediation Suggestions

  • Give the companion a separate, restricted workspace rather than requiring a shared workspace.
  • Export only specific user-approved files through an explicit allowlist.
  • Mount shared reference material read-only and deny access to primary memory and identity files by default.
  • Assign a minimal tool set appropriate to the companion's actual functions.
  • Use separate service credentials and narrowly scoped tokens for the companion.
  • Add authorization checks before reading sensitive files, modifying shared state, or invoking external services.
  • Treat Telegram input and all retrieved documents as untrusted.
  • Log access to shared resources and alert on attempts to reach files or tools outside the companion's approved scope.

T06 · System Persistence

Warning
Location
SKILL.md:105
Finding

Persistent Autonomous Execution Through Heartbeats and Scheduled Agent Turns

Content
View full analysis

Vulnerability Details

File Location: SKILL.md:29-41,105-119
Vulnerability Type: Recurring cross-session scheduled execution
Risk Level: Medium

Vulnerable Code Snippet

json
{
  "agents": {
    "list": [
      { "id": "primary-agent", "model": "..." },
      {
        "id": "companion-id",
        "model": "ollama/gemma4:e4b",
        "heartbeat": {
          "every": "1h",
          "target": "telegram",
          "accountId": "companion",
          "directPolicy": "allow",
          "to": "YOUR_TELEGRAM_ID"
        }
      }
    ]
  },
  "bindings": [
    {
      "agentId": "companion-id",
      "match": { "channel": "telegram", "accountId": "companion" }
    }
  ]
}
markdown
The built-in heartbeat (set in `agents.list[].heartbeat`) handles regular wakeups natively — no cron needed for that.

If you want a special first-morning message (warmer than a system event), use an `agentTurn` cron:

```json
{
  "schedule": { "kind": "cron", "expr": "0 9 * * *", "tz": "America/Denver" },
  "payload": { "kind": "agentTurn", "message": "Good morning...", "timeoutSeconds": 120 },
  "sessionTarget": "session:agent:companion-id:main",
  "delivery": { "mode": "none" }
}

Note: systemEvent can only target main. For companion sessions, agentTurn + sessionTarget: session:agent:companion-id:main is required.

text

### Technical Analysis

The Skill directs users to configure an hourly heartbeat and optionally install a daily cron-triggered `agentTurn`. These mechanisms survive the initial Skill invocation and repeatedly activate the companion in later sessions. The configuration also permits direct Telegram delivery.

No expiration period, maximum execution count, approval requirement, health check, resource quota, or removal procedure is documented. When combined with mutable persistent memory and shared workspace access, every scheduled activation can reload poisoned state, invoke inherited capabilities, or produce unsolicited outbound
...[truncated 927 chars]
Remediation
View remediation

Remediation Suggestions

  • Disable recurring heartbeats and cron jobs by default.
  • Require explicit, informed user consent before creating any persistent schedule.
  • Add an expiration timestamp, maximum run count, rate limit, and resource budget to every scheduled task.
  • Require approval before a scheduled turn invokes tools, modifies memory, or sends outbound messages.
  • Use deny-by-default delivery policy rather than directPolicy: "allow".
  • Document commands for listing, pausing, revoking, and deleting all installed schedules.
  • Display installed persistent triggers in the setup completion output.
  • Run autonomous turns with a restricted workspace and minimal tool permissions.
  • Prevent scheduled turns from loading or committing unreviewed behavioral instructions.

SkillSpector

Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Findings (1)

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
89% confidence
Finding

The skill walks the user through configuring a Telegram bot, enabling direct messaging, and scheduling heartbeat messages to a personal Telegram ID, but it does not warn that conversation content, identifiers, bot tokens, and workspace-derived data may be transmitted to a third-party messaging platform. Because the companion shares the primary workspace and can access identity and memory files, the absence of privacy and data-handling guidance increases the risk of unintentionally exposing sensitive personal or operational information through Telegram.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.