Celiums Cognition

Security checks across malware telemetry and agentic risk

Overview

This appears to be a legitimate but very powerful memory plugin with disclosed heavy infrastructure, but some data-isolation and security-claim gaps need review before installation.

Install only on a dedicated OpenClaw host where you are comfortable with automatic Docker services, local database persistence, prompt/memory journaling, and optional external LLM/search endpoints. Review and fix ownership checks for project/research/write data and do not rely on the advertised hosted-profile signature validation or database row-level security until those are implemented.

SkillSpector

By NVIDIA

Vulnerability Patterns

Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access

Findings (271)

Intent-Code Divergence

Medium

Confidence: 95% confidence
Finding: The comments in the full-pipeline section state the engine is a "RADAR, not a JAIL" and "never blocks user expression," but the same module explicitly supports `gate` mode, computes `enforcementBlocked`, forces `passed = false` on catastrophic hits, and adds blocked violations from Layers A/B/C/K. This is an active contradiction between the documented intent and the implemented behavior, not merely incomplete documentation.

Context-Inappropriate Capability

High

Confidence: 96% confidence
Finding: The skill presents itself as manuscript/project management tools for a user's writing projects, but several handlers fetch or modify records solely by projectId or sceneId without checking ctx.userId or project ownership. This gives the skill a capability to read or alter other users' manuscripts if IDs are known, which is not justified by the apparent writing-assistant purpose.

Context-Inappropriate Capability

Medium

Confidence: 88% confidence
Finding: With no manifest available, there is no declared purpose that would justify persisting user content and updating user interaction metadata. The `remember` path stores content in a memory engine and also updates profile activity data, which is a materially broader capability than simple retrieval or indexing helpers elsewhere in the file.

Context-Inappropriate Capability

Medium

Confidence: 84% confidence
Finding: `touchInteraction` updates `user_profiles.last_interaction`, increments `interaction_count`, and modifies hourly activity history, while `remember` later retrieves limbic and circadian telemetry. In the absence of a manifest or documented purpose, this user-state tracking and behavioral telemetry access is not justified by any declared skill scope.

Intent-Code Divergence

Low

Confidence: 84% confidence
Finding: The top-level documentation says "Tools covered: forage, absorb, sense, map_network, remember" and then immediately notes that `recall` lives in another file. This creates a documentation-level inconsistency about what this file actually implements, even though the contradiction is minor and not directly security-impacting.

Intent-Code Divergence

Low

Confidence: 77% confidence
Finding: The comment in the atlas library says atlas_chat multi-turn state is carried by the `messages` array and that the facade type was updated to match, but the exported `AtlasChatInput` type only includes `messages`, `max_tokens`, and `system`, omitting documented handler-supported fields like `prompt`, `model`, and `temperature`. This is not just incomplete documentation; it asserts a type alignment that the code does not actually provide.

Intent-Code Divergence

Medium

Confidence: 94% confidence
Finding: The MCP tool definition for `atlas_recommend` requires `task_description` and returns a ranked recommendation list with costs, but the exported library facade defines input as `{ task_type, budget? }` and output as `{ recommended_model, alternatives, reasoning }`. This actively misrepresents both what callers must send and what the underlying tool returns.

Intent-Code Divergence

Medium

Confidence: 90% confidence
Finding: The exported `AtlasListModelsOutput` interface claims the tool returns structured data as `models: Array<{ id, family, tier }>`, but the actual handler formats the model list into Markdown text lines and returns plain text content. This is a direct intent/code mismatch between the library contract and the implemented behavior.

Intent-Code Divergence

Medium

Confidence: 88% confidence
Finding: The InMemoryMemoryStore docstring says the store uses 'no PostgreSQL, no Qdrant, no Valkey — everything in process memory' and emphasizes zero-dependency local behavior. However, its embed() method conditionally calls fetch() to an external embeddingEndpoint when configured, which contradicts the stated all-in-process/no-external-services behavior rather than merely omitting detail.

Intent-Code Divergence

Low

Confidence: 80% confidence
Finding: The PgModuleStore docstring states it implements the 'EXACT surface' exposed by RemoteModuleStore, implying behavioral/API equivalence. But PgModuleStore includes an additional searchHybrid() method and hybrid vector-search behavior not present as a real equivalent in the remote backend, so the documentation overstates parity.

Intent-Code Divergence

High

Confidence: 95% confidence
Finding: In the autonomy engine source embedded at L1, the start() method comments say the executor 'already did it' and that the engine is 'just log[ging]' execution, yet the documented API says the engine allows the AI to work independently and 'execute tasks'. The actual loop only asks the executor for the next action descriptor and then records a synthetic success entry with output 'Executed', so the implementation contradicts the stated execution semantics and can mislead users and auditors about what really happened.

Intent-Code Divergence

Medium

Confidence: 71% confidence
Finding: The autonomy engine documentation in L1 states the ethics guard is 'ALWAYS first, cannot be removed' and that law enforcement is immutable, but the class exposes addGuard(), which mutates the guard chain at runtime without any integrity mechanism or freezing. While addGuard does not directly remove the ethics guard, the code contradicts the stronger documentation claim of an immutable guard chain and may create a false assurance about the security model.

Context-Inappropriate Capability

Medium

Confidence: 83% confidence
Finding: With no manifest available, the skill's purpose is unknown, so capabilities should be limited to what is clearly necessary from the code's own function. Reading process.env.CELIUMS_AGENT_ID introduces environment access that is not obviously required for writing a journal entry, especially since agent_id can also be supplied via input or context.

Intent-Code Divergence

Medium

Confidence: 95% confidence
Finding: The research_synthesize description explicitly states that the managed corpus is consulted only when augmentCorpus=true and SEARCH_URL is configured. However, the implementation falls back to searchHybrid whenever both local project chunks and corpusDocs are empty and SEARCH_URL is set, even without any augment flag, causing network-backed corpus search contrary to the documented behavior.

Intent-Code Divergence

Medium

Confidence: 96% confidence
Finding: The comment above the source-handling section states 'All local to the user's Postgres. Zero-knowledge: nothing leaves the box.' However, the same module's synthesis flow conditionally calls llmSynthesize with project documents, and the LLM request includes serialized evidence chunks sent to the configured external endpoint when CELIUMS_RESEARCH_ALLOW_EXTERNAL_LLM=true. This is an active contradiction between documentation and code behavior, even though other nearby comments describe the newer opt-in model correctly.

Intent-Code Divergence

Low

Confidence: 89% confidence
Finding: The library docstring says 'Research library — typed facades over the 8 research_* tools,' but the exported RESEARCH_TOOLS registry in the same file includes project_create/list/continue, search, synthesize, finding_add, gap_add, export, source_add, source_list, and source_delete. This is a direct intent/documentation mismatch about the skill's exposed scope.

Context-Inappropriate Capability

Medium

Confidence: 91% confidence
Finding: With no manifest available, the code itself indicates a skill centered on memory recall/search: it validates a query, calls engine.recall, and returns found memories. However, it also updates user_profiles.last_interaction and interaction_count in the database as a side effect, which is not an obvious requirement of a recall operation and introduces an additional state-changing capability beyond retrieval.

Intent-Code Divergence

Medium

Confidence: 95% confidence
Finding: The description frames recall as retrieving persistent memory, but the same docstring explicitly states a side effect: bumping last_interaction, incrementing interaction_count, and updating activity history. That is an intent-level contradiction because a retrieval tool is documented as having hidden state mutation beyond the core retrieval purpose.

Context-Inappropriate Capability

High

Confidence: 87% confidence
Finding: With no manifest available, the baseline purpose is unknown; most of the file implements knowledge and memory tools, then adds a distinct ethics_trace tool that runs a multi-layer evaluation pipeline, consults recall and external ethics knowledge, may invoke an LLM, and exposes detailed decision traces. This is a materially separate capability that is not justified by any declared skill purpose in the provided context.

Intent-Code Divergence

Medium

Confidence: 95% confidence
Finding: The top-level docblock states that the first six tools have no external deps and separately describes ethics_trace as optionally using a configured LLM endpoint. However, the same module exports OPENCORE_TOOLS and then appends ethics_trace into that exported tool set, so the file's 'simple surface' and dependency framing understates that this module's effective tool registry includes optional network-backed behavior.

Intent-Code Divergence

Medium

Confidence: 90% confidence
Finding: The adapter advertises `rowLevelSecurity: true`, yet the schema creation SQL only creates tables and indexes and contains no row-level security policies, and subsequent queries rely on caller-supplied tenant/user filters rather than database-enforced isolation. This is an intent-level contradiction because the code metadata explicitly represents a security property that the implementation does not actually establish.

Intent-Code Divergence

Low

Confidence: 80% confidence
Finding: The doc comment frames the module as a Postgres+Qdrant storage adapter focused on memories, journal entries, and vector consistency, while later code adds audit log write/query behavior against `security_audit_log`. This is not merely omitted detail in a single function docstring; the top-level documentation describes the adapter surface in a way that understates the actual operational scope.

Context-Inappropriate Capability

Medium

Confidence: 86% confidence
Finding: With no manifest available, the file must be judged against only its own apparent role as setup/bootstrap code. It goes beyond simple local initialization by attempting to change a kernel parameter via `sysctl` and by launching a multi-service Docker Compose stack, which are powerful host-management capabilities not justified by any stated purpose in the provided context.

Intent-Code Divergence

High

Confidence: 98% confidence
Finding: The surrounding code and exported error types indicate hosted profiles are expected to undergo real signature validation before use: load() checks verifySignatureV1(profile) and defines ProfileSignatureInvalid/ProfileInvalid paths for bad signatures. However, verifySignatureV1 at L332-L333 always returns true, which contradicts that documented/security-signaling intent and means remotely fetched profiles are accepted without actual signature verification.

Intent-Code Divergence

Medium

Confidence: 94% confidence
Finding: The source comments state that `ProfileSignatureInvalid` is thrown when a profile fails signature verification for v2+ and that profile signatures are verified before use, but the implemented `verifySignatureV1` function unconditionally returns true and `HostedProfileLoader.load` relies on that result. This is an active contradiction between the documented security intent and the actual code behavior for signature handling in this file.

VirusTotal

62/62 vendors flagged this plugin as clean.

View on VirusTotal