Back to skill

Security audit

private computation

Security checks for vulnerabilities and agentic risk

Overview

This skill is about private computation, but it advertises strong privacy and compliance protections that its own documentation says are not implemented yet.

Review this carefully before installing. Do not rely on it for zero-knowledge execution, TEE isolation, HIPAA/GDPR compliance, medical, financial, or other regulated workloads unless the publisher provides the actual reviewed implementation, version pinning, key-management details, audit-log safeguards, and evidence that the advertised security modes are implemented and fail closed when unavailable.

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • 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
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (2)

T08 · Insecure Dependencies

Warning
Location
SKILL.md:55
Finding
Unpinned and Unauditable Third-Party Package Installation<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 55–65 **Vulnerability Type**: Supply-chain exposure through remotely resolved dependencies **Risk Level**: Medium ### Vulnerable Code ```markdown ## 📦 Installation / 安装 ### Via npm ```bash npm install openclaw-private-computation ``` ### Via ClawHub ```bash clawhub install private-computation ``` ``` ### Technical Analysis The installation instructions direct users to retrieve packages from external registries without specifying an exact version, integrity hash, lockfile, or other immutable package identity. The submitted project contains only `SKILL.md`; it does not include the referenced implementation, a package manifest, dependency lock data, or source code that would allow the installed payload to be audited. Consequently, the effective code installed by these commands can differ from the content reviewed in this audit. npm packages and their transitive dependencies may also define installation lifecycle scripts that execute with the privileges of the user performing the installation. This does not establish that the referenced packages are malicious. It means the submitted artifact does not provide enough information to establish the safety or immutability of the software users are instructed to execute. ### Attack Path 1. A user trusts the installation instructions in `SKILL.md`. 2. The user runs one of the unpinned installation commands. 3. The registry resolves the package and its dependencies at installation time. 4. A compromised publisher account, malicious package release, dependency confusion event, or compromised transitive dependency supplies altered code. 5. Package lifecycle scripts or subsequently imported runtime code execute under the installing user's account. 6. Because the package is intended to manage API keys and other secrets, malicious code could access credentials supplied to the package, local files available to the user, or network resources acce ...[truncated 733 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Pin the installation command to a reviewed, exact package version rather than relying on the registry's current default version. 2. Include the complete implementation and package manifest in the submitted project so that the relevant code can be audited. 3. Commit a dependency lockfile containing registry integrity metadata. 4. Publish and verify cryptographic checksums or signed release provenance for distributed artifacts. 5. Document the expected package publisher, registry, version, and integrity value. 6. Audit all direct and transitive dependencies before release and continuously monitor them for compromised or malicious updates. 7. Disable dependency lifecycle scripts during installation where operationally possible, and explicitly document any lifecycle scripts that are required. 8. Run installation and execution under a dedicated, least-privileged account or isolated environment without unnecessary access to production credentials. ]]>

other

Error
Location
SKILL.md:24
Finding
Security and Compliance Claims Contradict Documented Implementation Status<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 24–46, 132–142, 193–207, and 216–238 **Vulnerability Type**: Misrepresentation of unavailable security controls **Risk Level**: High ### Vulnerable Code The feature section presents TEE and zero-knowledge security levels as available: ```markdown - 🎯 **Multiple Security Levels** / **多层安全级别** - Basic, Standard (TEE), and Strict (Zero-Knowledge) - 基础、标准(TEE)、严格(零知识证明) - ✅ **GDPR & HIPAA Compliant** / **GDPR 和 HIPAA 合规** - Designed for regulatory compliance - 专为满足监管合规要求而设计 ``` The API reference similarly documents these modes as selectable: ```markdown const agent = new PrivateAgent({ securityLevel: 'basic' | 'standard' | 'strict', encryption: 'aes-256-gcm' | 'chacha20-poly1305', audit: boolean, storagePath: string, // Default: ~/.openclaw masterKey: string // Auto-generated if not provided / 未提供时自动生成 }); ``` ```markdown | Level / 级别 | Features / 功能 | Overhead / 开销 | Use Case / 适用场景 | |--------------|----------------|-----------------|-------------------| | **Basic / 基础** | Encrypted storage / 加密存储 | ~0% | Development / 开发测试 | | **Standard / 标准** | + TEE isolation / + TEE 隔离 | ~10% | Production / 生产环境 | | **Strict / 严格** | + Zero-knowledge proofs / + 零知识证明 | ~300% | High-security / 高度敏感 | ``` However, the architecture identifies these controls as future functionality: ```markdown ├── Crypto Layer (Future) / 加密层(未来) │ ├── zk-SNARKs (Zero-Knowledge Proofs) / 零知识证明 │ ├── TEE (Trusted Execution Environment) / 可信执行环境 │ └── Homomorphic Encryption / 同态加密 ``` The roadmap confirms that zero-knowledge proofs and TEE integration have not been completed: ```markdown ### Phase 2: Zero-Knowledge (Next / 下一步) - [ ] zk-SNARKs integration / zk-SNARKs 集成 - [ ] Proof generation and verification / 证明生成和验证 - [ ] Circuit library / 电路库 ### Phase 3: TEE Integration / TEE 集成 - [ ] Intel SGX support / Intel SGX 支持 - [ ] ARM TrustZone support / ARM TrustZone 支持 - [ ] Hybrid mod ...[truncated 2857 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Remove claims that TEE isolation and zero-knowledge execution are currently available until the corresponding implementations have been completed and independently reviewed. 2. Mark `standard` and `strict` modes as unsupported or experimental and reject their selection at runtime rather than silently degrading to basic protection. 3. Clearly distinguish encryption at rest from execution isolation, zero-knowledge computation, remote attestation, and tamper-resistant audit storage. 4. Replace categorical HIPAA and GDPR compliance statements with narrowly scoped descriptions of implemented controls. 5. Obtain qualified legal and compliance review before advertising regulatory compliance. 6. Document the threat model, trust boundaries, key-management design, audit-log integrity guarantees, and behavior of every security level. 7. For TEE support, provide attestation verification, platform requirements, fallback behavior, and tests demonstrating that sensitive processing occurs inside the expected enclave. 8. For zero-knowledge support, provide circuits, proof-generation code, verification code, public/private input definitions, and independent cryptographic review. 9. Add tests that fail when a requested security mode is unavailable or when the required attestation or proof cannot be verified. 10. Warn users not to process regulated or highly sensitive data until the promised controls and necessary organizational compliance measures are demonstrably in place. ]]>
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Findings (5)

Description-Behavior Mismatch

High
Confidence
98% confidence
Finding
The skill markets itself as providing current 'zero-knowledge execution' and privacy/security assurances, but the body of the document later states that zero-knowledge proofs and TEE isolation are future or planned features. This can cause users to rely on non-existent protections for highly sensitive workloads such as medical, financial, or private-context processing, creating a dangerous mismatch between perceived and actual security guarantees.

Intent-Code Divergence

High
Confidence
97% confidence
Finding
The documentation states that 'strict' mode provides zero-knowledge proofs, while other sections say that zero-knowledge functionality is only planned. Users may select 'strict' mode believing it adds strong cryptographic privacy guarantees when it may not do anything beyond the MVP feature set, leading to unsafe deployment decisions in regulated or high-sensitivity environments.

Intent-Code Divergence

High
Confidence
97% confidence
Finding
The API reference advertises a 'proof' execution option for generating zero-knowledge proofs, but the roadmap says proof generation is a future feature. This is dangerous because integrators may build compliance or privacy workflows around proof artifacts that are never actually produced or verified, resulting in silent security failure.

Missing User Warnings

Medium
Confidence
89% confidence
Finding
The skill strongly encourages audit logging for sensitive tasks but does not warn that task metadata, identifiers, or operational details may themselves contain sensitive information. In a privacy-focused skill, this omission is more dangerous because users may assume all logging is inherently safe and accidentally create durable records of regulated or confidential data.

Missing User Warnings

Medium
Confidence
85% confidence
Finding
The examples show storing API keys and other secrets locally through a simple API without warning users about where secrets are stored, how the master key is managed, and what local compromise would expose. In this context, the risk is amplified because the skill is explicitly marketed for sensitive and regulated workloads, so users may overtrust local secret handling without understanding their operational responsibilities.

Static analysis

No suspicious patterns detected.