ocmesh

• Outcome: Review
• Latest audit: Sep 12, 2026 · 8:51 AM UTC
• Version: 0.2.0

Overview

This skill mostly does what it advertises, but it exposes sensitive local control and message data with weak safeguards and overstates message privacy.

Review this before installing. It is not clearly malicious, but it runs as a persistent network daemon, announces your agent on public relays, stores a long-lived identity key locally, and exposes an unauthenticated localhost API that can read messages, send signed messages/tasks, and change webhook settings. Do not use it for secrets or sensitive coordination unless authentication, key-file permissions, webhook controls, relay-event verification, and the plaintext group-chat behavior are fixed or explicitly accepted.

A.I.G

Vulnerability Patterns

• 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
• 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

Findings (5)

T09 · Insecure Skill Coding Practices

Error

• Location: db.js:11
• Finding: Plaintext Nostr Private Key Stored Without Explicit Filesystem Protection## Vulnerability Details **File Location**: `db.js:11-14`; `identity.js:17-24` **Vulnerability Type**: Plaintext sensitive-data storage with insufficient permission enforcement **Risk Level**: High ### Vulnerable Code ```js const DATA_DIR = path.join(os.homedir(), '.ocmesh'); fs.mkdirSync(DATA_DIR, { recursive: true }); const db = new DatabaseSync(path.join(DATA_DIR, 'ocmesh.db')); ``` ```js // First run — generate fresh keypair const sk = generatePrivateKey(); // returns hex string const pk = getPublicKey(sk); db.prepare('INSERT INTO identity (sk, pk) VALUES (?, ?)').run(sk, pk); ``` ### Technical Analysis The agent's long-lived Nostr private key is stored as plaintext in the `identity.sk` column of `~/.ocmesh/ocmesh.db`. The code does not explicitly create the data directory with mode `0700` or the database with mode `0600`. Its effective accessibility therefore depends on the user's umask and any preexisting permissions on `~/.ocmesh`. The key is the root credential for the agent's identity. Possession of it permits signing events as the agent and decrypting NIP-04 messages available to the attacker. SQLite encryption is not enabled, and no operating-system credential store is used. ### Attack Path 1. An attacker gains local code execution or filesystem read access under another account or compromised process. 2. The attacker checks whether `~/.ocmesh` or `~/.ocmesh/ocmesh.db` is accessible because of permissive inherited permissions or umask settings. 3. The attacker opens the database and executes an equivalent of `SELECT sk FROM identity LIMIT 1`. 4. The extracted key is imported into a Nostr client. 5. The attacker signs messages as the agent, impersonates it to peers, or decrypts captured NIP-04 traffic associated with that key. ### Impact Assessment Successful exploitation compromises the complete cryptographic identity of the ocmesh agent. The attacker can impersonate the agent across the ...[truncated 189 chars]
• Remediation: ## Remediation Suggestions - Create `~/.ocmesh` with an explicit mode of `0700`. - Set the database and configuration files to mode `0600` immediately after creation and verify their permissions on every startup. - Refuse to start, or display a prominent warning, if the directory or database is readable by group or other users. - Prefer storing the private key in macOS Keychain or another operating-system credential store and retain only a key reference in SQLite. - Provide a supported key-rotation procedure for installations that may already have exposed keys. - Avoid logging or returning the private key through diagnostics, errors, or API responses.

T09 · Insecure Skill Coding Practices

Error

• Location: nostr.js:27
• Finding: Public Relay Events Are Processed Without Cryptographic Signature Verification## Vulnerability Details **File Location**: `nostr.js:27-34` **Vulnerability Type**: Missing authenticity and integrity validation for untrusted network events **Risk Level**: High ### Vulnerable Code ```js ws.on('message', (raw) => { try { const msg = JSON.parse(raw.toString()); if (msg[0] === 'EVENT' && msg[2]) { onEvent(msg[2], url); } } catch (_) {} }); ``` ### Technical Analysis Events received over WebSocket connections to public Nostr relays are passed directly to application handlers. The client does not verify that an event ID matches its serialized contents or that its Schnorr signature is valid for the claimed public key. Relay-side validation cannot replace client-side verification because public relays are outside the application's trust boundary. A malicious, compromised, or noncompliant relay can submit fabricated events claiming any `pubkey`. Those events can reach presence, profile, direct-message, and group handlers. Encrypted direct-message processing may reject some forged messages during decryption, but presence, profile, and group processing can act on unsigned or invalid events without an equivalent cryptographic failure. ### Attack Path 1. An attacker controls or compromises a configured relay, or causes the client to receive noncompliant relay data. 2. The relay sends an `EVENT` frame containing a fabricated event with an arbitrary public key, ID, tags, content, or signature. 3. `nostr.js` parses the frame but performs no event verification. 4. The event is dispatched to `handlePresenceEvent`, `handleProfileEvent`, `handleGroupMessage`, or `handleDmEvent`. 5. Depending on the event kind, the daemon records forged identity metadata, discovers a false peer, initiates an automatic handshake, or stores forged group content. ### Impact Assessment Exploitation undermines the authenticity guarantees expected from Nostr. Attackers can spoof peers and prof ...[truncated 232 chars]
• Remediation: ## Remediation Suggestions - Call the appropriate `nostr-tools` event-verification function, such as `verifyEvent`, before dispatching any event. - Reject events whose calculated ID does not match `event.id` or whose signature does not validate against `event.pubkey`. - Validate event shape, public-key length, tags, timestamps, kind, and content size before processing. - Add maximum WebSocket frame and event-content sizes to limit memory and storage abuse. - Log invalid-event metrics without logging sensitive message contents. - Add tests using forged IDs, signatures, public keys, timestamps, and malformed tags.

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: groups.js:74
• Finding: Group Messages Are Publicly Exposed and Accepted Without Membership Enforcement## Vulnerability Details **File Location**: `groups.js:74-84`; `groups.js:107-125` **Vulnerability Type**: Broken group authorization and missing group-message confidentiality **Risk Level**: High ### Vulnerable Code ```js async function sendToGroup(groupId, content) { const group = db.prepare('SELECT * FROM groups WHERE id = ?').get(groupId); if (!group) throw new Error(`Group not found: ${groupId}`); const now = Math.floor(Date.now() / 1000); const event = finishEvent({ kind: 42, created_at: now, tags: [['e', groupId, '', 'root']], content, }, identity.sk); publish(event); ``` ```js function handleGroupMessage(event) { if (!event || event.kind !== 42) return; const rootTag = event.tags.find(([k, , , marker]) => k === 'e' && marker === 'root'); if (!rootTag) return; const groupId = rootTag[1]; const group = db.prepare('SELECT id FROM groups WHERE id = ?').get(groupId); if (!group) return; // not a group we know const existing = db.prepare('SELECT id FROM group_messages WHERE id = ?').get(event.id); if (existing) return; db.prepare(` INSERT INTO group_messages (id, group_id, from_pk, content, received_at) VALUES (?, ?, ?, ?, ?) `).run(event.id, groupId, event.pubkey, event.content, Date.now()); ``` ### Technical Analysis The database stores a `member_pks` array for each group, but `handleGroupMessage` only checks whether the referenced group exists. It never confirms that `event.pubkey` is an authorized member. Additionally, group content is assigned directly to the public kind-42 Nostr event's `content` field. Unlike one-to-one messages, it is not encrypted before publication. Relay operators and observers capable of retrieving the channel events can therefore read group messages. This behavior is particularly significant because the Skill documentation broadly states that all messages are end-to-end encrypted. Th ...[truncated 1059 chars]
• Remediation: ## Remediation Suggestions - Verify every event signature before group processing. - Load and parse `member_pks`, then reject events whose verified sender is not an authorized member. - Define authenticated membership-change events and ensure only authorized administrators can add or remove members. - Implement authenticated group encryption if group conversations are intended to be private. - Rotate group encryption keys whenever membership changes. - If NIP-28 plaintext channels remain supported, clearly label them as public and remove the claim that all messages are end-to-end encrypted. - Enforce content-size limits, timestamp bounds, and per-sender rate limits.

T05 · Unauthorized Access and Privilege Escalation

Warning

• Location: api.js:16
• Finding: Unauthenticated Loopback API Exposes Messages and Identity-Bearing Operations## Vulnerability Details **File Location**: `api.js:16-17`, `api.js:124-164`, `api.js:256-260` **Vulnerability Type**: Missing authentication and authorization on a sensitive local service **Risk Level**: Medium ### Vulnerable Code ```js const app = express(); app.use(express.json()); const PORT = 7432; ``` ```js app.get('/messages', (req, res) => { const { unread, from, type } = req.query; let query = 'SELECT * FROM messages WHERE 1=1'; const params = []; if (unread === 'true') { query += ' AND read = 0'; } if (from) { query += ' AND from_pk = ?'; params.push(from); } if (type) { query += ' AND msg_type = ?'; params.push(type); } query += ' ORDER BY received_at DESC LIMIT 100'; res.json({ messages: db.prepare(query).all(...params) }); }); app.post('/send', async (req, res) => { const { to, content, type } = req.body; if (!to || !content) return res.status(400).json({ error: 'to and content required' }); try { const payload = type ? create(type, { body: content }) : content; const id = await send(to, payload); res.json({ ok: true, id }); } catch (err) { res.status(500).json({ error: err.message }); } }); ``` ```js function start() { app.listen(PORT, '127.0.0.1', () => { console.log(`[api] HTTP API v0.2.0 → http://127.0.0.1:${PORT}`); }); } ``` ### Technical Analysis Binding to `127.0.0.1` prevents direct access from remote network interfaces, but it does not authenticate local clients. Any process running on the host that can open a loopback TCP connection can invoke the service. The API exposes decrypted messages and provides state-changing endpoints for sending signed messages, changing profiles and configuration, marking messages as read, and creating or messaging groups. No bearer token, client certificate, Unix-socket permission check, or per-operation authorization is present. Because the daemon holds the Nostr ...[truncated 1086 chars]
• Remediation: ## Remediation Suggestions - Generate a high-entropy API bearer token on first run and store it in a file readable only by the owning user. - Require authentication on every endpoint, including read-only status and message endpoints unless intentionally public. - Apply separate authorization scopes for reading messages, sending messages, and changing configuration. - Prefer a Unix-domain socket with restrictive filesystem permissions over a TCP listener where platform compatibility permits. - Add request-body size limits, rate limiting, and strict schema validation. - Do not rely on loopback binding as the sole security boundary. - Document how legitimate clients obtain and rotate API credentials.

T09 · Insecure Skill Coding Practices

Warning

• Location: webhook.js:28
• Finding: Unrestricted Webhook Configuration Enables Message Exfiltration and Server-Side Requests## Vulnerability Details **File Location**: `api.js:227-240`; `webhook.js:28-64`; `messaging.js:102-109` **Vulnerability Type**: Unrestricted outbound webhook destination and sensitive-data forwarding **Risk Level**: Medium ### Vulnerable Code ```js app.patch('/config', (req, res) => { const cfg = configManager.load(); const { webhook, mesh, profile } = req.body; if (webhook) Object.assign(cfg.webhook, webhook); if (mesh) Object.assign(cfg.mesh, mesh); if (profile) Object.assign(cfg.profile, profile); configManager.save(cfg); res.json({ ok: true }); }); ``` ```js async function fire(eventType, payload) { if (!config?.webhook?.enabled || !config?.webhook?.url) return; const body = JSON.stringify({ event: eventType, ts: Date.now(), payload, }); const url = new URL(config.webhook.url); const isHttps = url.protocol === 'https:'; const lib = isHttps ? https : http; const options = { hostname: url.hostname, port: url.port || (isHttps ? 443 : 80), path: url.pathname + url.search, method: 'POST', headers, timeout: 5000, }; return new Promise((resolve) => { const req = lib.request(options, (res) => { res.resume(); resolve(res.statusCode); }); ``` ```js await webhook.fire('message.received', { id: event.id, from: event.pubkey, type: msgType, content: decrypted, ts: Date.now(), }); ``` ### Technical Analysis The configuration endpoint allows callers to set an arbitrary webhook URL and enable delivery. The webhook implementation accepts unrestricted HTTP or HTTPS destinations and does not block loopback, private, link-local, or cloud metadata addresses. Incoming direct-message payloads include the fully decrypted message content. Once a webhook is enabled, future plaintext messages are posted to the configured destination. The optional HMAC protects integrity for a ...[truncated 1326 chars]
• Remediation: ## Remediation Suggestions - Authenticate and authorize all configuration changes. - Require explicit user confirmation before enabling a webhook or changing its destination. - Allowlist approved webhook hosts, ports, and URL schemes. - Require HTTPS for non-loopback destinations. - Resolve hostnames and reject loopback, private, link-local, multicast, and reserved address ranges before connecting. - Revalidate the resolved address on every connection to mitigate DNS rebinding. - Do not follow redirects to unapproved destinations. - Allow users to omit message bodies or select which event fields may be forwarded. - Display the active webhook destination prominently in status output and provide an audit log of configuration changes. - Store webhook secrets and configuration files with restrictive filesystem permissions.

SkillSpector

Vulnerability Patterns

• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Rogue Agent: Self-Modification, Session Persistence

Findings (43)

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: The declared description centers on an ocmesh agent discovery and communication layer: discovering other agents on the internet via Nostr relays, checking who is on the mesh, querying peers, and sending encrypted messages to another agent. The supplied code does not implement those behaviors. Instead, it manages multi-agent group conversations using Nostr channel events (kind 40/42), with local database tables for groups and group messages. It can create groups, subscribe to known groups, send messages to a group, receive/store group messages, and list groups/history. There is no code for discovering agents, maintaining a peer list, querying who else is on the mesh, or sending direct encrypted messages. Although nip04 is imported, it is unused, and message content is published/stored as plaintext. This is a material purpose mismatch, not merely an implementation detail.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 90% confidence
• Finding: The declared description promises a broad decentralized agent mesh feature set: discovering agents anywhere on the internet, checking who is on the mesh, sending encrypted messages, and connecting agents globally. The supplied code does not implement that overall behavior. It is specifically limited to publishing and receiving Nostr kind-0 profile metadata and storing ocmesh-tagged profiles locally. While this supports discovery at a metadata level, it does not itself implement messaging, encrypted communication, peer-list querying beyond a local cache lookup by public key, or actual mesh connection management. Therefore the code chunk's behavior is materially narrower than the declared purpose.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: The declared description focuses on a decentralized mesh networking capability: discovering other agents on the internet via Nostr, connecting agents, listing peers, and sending encrypted messages. The supplied code does not implement those primary behaviors. Instead, it is a narrowly scoped messaging support module for delivery and read receipts, similar to WhatsApp-style acknowledgements. It sends DELIVERED/READ protocol messages through an injected send function and updates a local SQLite-style database to mark messages as delivered or read by a peer. While receipts could be a supporting feature within a messaging system, this chunk’s actual behavior is materially different from the declared primary purpose and introduces an undeclared capability (receipt tracking) rather than discovery/mesh functionality.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 98% confidence
• Finding: This code does not perform the mesh-network behaviors described. It only manages local threaded conversation metadata keyed by peer public key and reads/writes local database records. There is no code for discovering agents, connecting over Nostr relays, sending messages across the network, querying a global peer list, or handling encryption. While thread management could be a supporting component of a messaging system, the supplied chunk’s primary behavior is materially different from the declared purpose, so this is a clear description-behavior mismatch.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 96% confidence
• Finding: The declared description focuses on core mesh networking capabilities: discovering agents on the internet via Nostr relays, checking who is on the mesh, sending encrypted messages, and querying peers. The supplied code chunk instead provides a webhook integration layer that forwards already-generated mesh events to an HTTP endpoint. This is a materially different primary purpose from the declared mesh discovery/messaging behavior. The code also introduces an undeclared external-network capability: posting event data to arbitrary webhook URLs, with optional HMAC signatures. While the events are related to the mesh domain, this module is not implementing the advertised discovery or messaging functions and instead acts as an event push/notification subsystem.

Exfiltration Commands

High

• Category: Prompt Injection

Content

---
name: ocmesh
description: Decentralized agent-to-agent mesh network for OpenClaw. Automatically discovers other ocmesh agents anywhere on the internet via Nostr relays — no shared network, no accounts, no configuration. Use when a user wants to connect their OpenClaw agent with other agents globally, check who else is on the mesh, send encrypted messages to another agent, or query the peer list. Install with scripts/install.sh. Triggers on phrases like "connect with other agents", "find other OpenClaw users", "agent mesh", "who else is running ocmesh", "send message to another agent".
---

# ocmesh

• Confidence: 90% confidence
• Finding: The skill explicitly enables sending messages to internet-discovered peers, which creates a channel that can be used to transmit user or system data outside the local environment. In an agent context, any generic messaging capability to arbitrary peers is high risk because it can be repurposed for exfiltration or unauthorized outbound communications.

Missing User Warnings

High

• Confidence: 96% confidence
• Finding: The skill starts a persistent background daemon, announces presence to public relays, auto-handshakes peers, stores persistent keys, and configures auto-start on login, but the documentation does not foreground these privacy and system-persistence consequences as warnings. Users may unknowingly expose agent presence on the public internet and alter system startup behavior.

Known Vulnerable Dependency: path-to-regexp==0.1.12 — 1 advisory(ies): CVE-2024-45296 (path-to-regexp vulnerable to Regular Expression Denial of Service via multiple r)

High

• Category: Supply Chain
• Confidence: 96% confidence
• Finding: path-to-regexp 0.1.12 is a long-lived routing dependency in Express 4 and has a reported Regular Expression Denial of Service issue. Because this skill exposes internet-reachable HTTP functionality and is intended for global peer discovery/messaging, an attacker may be able to send crafted paths that consume excessive CPU and stall the service remotely.

Known Vulnerable Dependency: ws==8.19.0 — 2 advisory(ies): CVE-2026-45736 (ws: Uninitialized memory disclosure); CVE-2026-48779 (ws: Memory exhaustion DoS from tiny fragments and data chunks)

High

• Category: Supply Chain
• Confidence: 94% confidence
• Finding: ws 8.19.0 is reported as affected by memory disclosure and memory exhaustion issues. This is especially dangerous in this skill because it is explicitly designed to communicate with arbitrary agents over the public internet, giving remote attackers direct reachability to trigger WebSocket-level attacks that can leak data or take the service offline.

Known Vulnerable Dependency: ws==8.19.0 — 2 advisory(ies): CVE-2026-45736 (ws: Uninitialized memory disclosure); CVE-2026-48779 (ws: Memory exhaustion DoS from tiny fragments and data chunks)

High

• Category: Supply Chain
• Confidence: 80% confidence
• Finding: Dependency has known vulnerabilities (CVEs). Using packages with unpatched security flaws exposes the environment to known exploits.

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 87% confidence
• Finding: The skill documents shell-based installation and operation but does not declare any tool scope or permissions boundary. In agent environments, missing scope metadata can let a model invoke shell actions like installation or daemon control without clear user consent or sandbox expectations.

Vague Triggers

Medium

• Confidence: 93% confidence
• Finding: The trigger phrases are broad enough to match ordinary requests about connecting with users or agents, which could cause the skill to activate unexpectedly. Because the skill installs or interacts with persistent networking components, accidental invocation increases the chance of unintended network exposure or state changes.

External Transmission

Medium

• Category: Data Exfiltration

Content

**Check if daemon is running and how many peers are connected:**
```bash
curl http://127.0.0.1:7432/status
```

**List online peers:**

• Confidence: 60% confidence
• Finding: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Context-Inappropriate Capability

Medium

• Confidence: 86% confidence
• Finding: The task-sending endpoint introduces a structured remote action invocation primitive, not just generic messaging, and exposes it via unauthenticated local HTTP. In an agent mesh context, this can be abused by local malware or web pages targeting localhost to cause the agent to dispatch privileged task requests to peers, potentially triggering unintended actions across connected agents and expanding impact beyond the local host.

Description-Behavior Mismatch

Medium

• Confidence: 90% confidence
• Finding: The manifest describes ocmesh as a mesh for discovering other agents, checking who is on the mesh, sending encrypted messages to another agent, and querying the peer list. This file also exposes group creation, group message retrieval, and group broadcast endpoints, which are materially broader collaboration features not reflected in the stated skill purpose.

Description-Behavior Mismatch

Medium

• Confidence: 88% confidence
• Finding: The configuration API allows runtime modification of mesh, webhook, and profile settings over HTTP on localhost with no authentication shown. Even if bound to 127.0.0.1, any local process or a browser-based CSRF-style request against localhost could reconfigure network behavior or webhook settings, which can enable message rerouting, data leakage, or weakening of security-sensitive configuration.

Description-Behavior Mismatch

Medium

• Confidence: 98% confidence
• Finding: The module publishes group messages as Nostr kind-42 events with raw plaintext content and also stores that plaintext locally, despite the skill description advertising encrypted agent messaging. In a decentralized relay-based mesh context, users may reasonably assume confidentiality, so this mismatch can cause sensitive agent-to-agent data to be exposed to relays, eavesdroppers, and any subscriber to the channel.

Missing User Warnings

Medium

• Confidence: 92% confidence
• Finding: This code transmits group messages over the internet via relays without any visible warning in the implementation that the data is leaving the local system and is readable by others. In the context of an agent mesh that encourages connecting with arbitrary internet peers, lack of disclosure materially increases the risk of accidental secret leakage or unsafe data sharing.

Missing User Warnings

Medium

• Confidence: 92% confidence
• Finding: The code automatically fires a webhook after every successful peer handshake and includes the peer public key and timestamp in the outbound payload. In the context of a decentralized agent mesh, this leaks peer relationship metadata to an external endpoint without any visible consent, disclosure, or control in this file, which can enable tracking of who the agent connects to and when.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: This code forwards fully decrypted DM content to a webhook sink immediately after receipt, which creates a second disclosure channel for data users likely expect to remain end-to-end private between agents. In the context of a decentralized messaging skill, this is more dangerous because messages may contain secrets, credentials, or sensitive coordination data, and webhook destinations are external systems with separate trust boundaries, retention, and access controls.

Description-Behavior Mismatch

Medium

• Confidence: 91% confidence
• Finding: The file explicitly states that peer discovery fires a webhook on new peer discovery, adding an outbound data-sharing capability beyond basic mesh discovery. In this skill context, discovered peer identities are sensitive network metadata, so silently forwarding them to another endpoint increases privacy and supply-chain risk if operators did not expect external disclosure.

Context-Inappropriate Capability

Medium

• Confidence: 96% confidence
• Finding: On first sighting of a peer, the code sends the peer public key, version, and timestamp to a webhook endpoint. Even though the data is not a secret credential, it is externally discovered network intelligence about other agents, and exfiltrating it can leak relationship and activity metadata to a third party without necessity for core mesh operation.

Missing User Warnings

Medium

• Confidence: 92% confidence
• Finding: The code emits outbound notifications containing peer identifiers during discovery without any indication in this file of consent, notice, or operator confirmation. In a decentralized agent-mesh skill, users may reasonably expect peer discovery to remain local, so undisclosed transmission of discovered identities meaningfully raises privacy and trust concerns.

Session Persistence

Medium

• Category: Rogue Agent

Content

SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
# The actual ocmesh source lives one level up (skill root)
OCMESH_DIR="$(dirname "$SCRIPT_DIR")"
PLIST_SRC="$OCMESH_DIR/com.ocmesh.agent.plist"
PLIST_DST="$HOME/Library/LaunchAgents/com.ocmesh.agent.plist"
LOG_DIR="$HOME/.ocmesh"

• Confidence: 75% confidence
• Finding: Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.

Session Persistence

Medium

• Category: Rogue Agent

Content

SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
# The actual ocmesh source lives one level up (skill root)
OCMESH_DIR="$(dirname "$SCRIPT_DIR")"
PLIST_SRC="$OCMESH_DIR/com.ocmesh.agent.plist"
PLIST_DST="$HOME/Library/LaunchAgents/com.ocmesh.agent.plist"
LOG_DIR="$HOME/.ocmesh"

• Confidence: 75% confidence
• Finding: Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.

Static analysis

No suspicious patterns detected.