Back to skill

Security audit

Verified Agent Identity

Security checks for vulnerabilities and agentic risk

Overview

This identity skill is mostly purpose-aligned, but it handles cryptographic identity keys in ways that could expose them and links identities with weak confirmation guidance.

Review this skill carefully before installing. Use it only if you are comfortable with local DID private keys being created and stored, set BILLIONS_NETWORK_MASTER_KMS_KEY before creating identities, avoid importing private keys through command-line arguments, and require explicit confirmation before signing challenges or linking an agent identity to a person.

Vulnerability Patterns
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • 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)

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:145
Finding
Private Identity Keys Stored in Plaintext by Default<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 145–151 **Vulnerability Type**: Plaintext storage of cryptographic secrets **Risk Level**: High ### Vulnerable Snippet ```markdown ## Security **CRITICAL - Data Storage and Protection:** The directory `$HOME/.openclaw/billions` contains all sensitive identity data: - `kms.json` - **CRITICAL**: Contains private keys (encrypted if BILLIONS_NETWORK_MASTER_KMS_KEY is set, otherwise in plaintext) ``` ### Technical Analysis The documented storage design permits private identity keys to be written to `$HOME/.openclaw/billions/kms.json` without encryption whenever `BILLIONS_NETWORK_MASTER_KMS_KEY` is not configured. Encryption is therefore optional and the documented default or fallback behavior leaves long-lived cryptographic material exposed at rest. A private key is the security boundary for the associated decentralized identity. File-system permissions alone do not adequately protect it from compromised processes running under the same account, accidental backup exposure, overly broad permissions, diagnostic collection, or unauthorized local access. The artifact contains only `SKILL.md`; the referenced scripts are absent. Consequently, file permissions, key derivation, encryption parameters, and runtime safeguards could not be independently verified. ### Attack Path 1. A user creates an identity without first setting `BILLIONS_NETWORK_MASTER_KMS_KEY`. 2. The identity implementation follows the documented fallback behavior and stores the private key in plaintext in `$HOME/.openclaw/billions/kms.json`. 3. A malicious or compromised process with access to the user's files reads or copies `kms.json`. 4. The attacker extracts the private key. 5. The attacker uses that key outside the project to generate valid signatures and impersonate the affected agent identity. ### Impact Assessment Successful exploitation compromises the confidentiality and integrity of the affected decentralized ide ...[truncated 487 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Make encryption mandatory before creating or importing any identity; refuse the operation when a secure key-encryption mechanism is unavailable. 2. Store private keys in an operating-system credential vault, hardware-backed keystore, hardware security module, or equivalent protected secret store instead of a general JSON file. 3. If encrypted file storage must be supported: - Use a modern authenticated-encryption construction. - Derive encryption keys with a memory-hard KDF and unique salt. - Never store the master encryption key beside the encrypted key material. - Validate decryption and authentication before using a key. 4. Create identity directories and files with owner-only permissions and reject existing files with unsafe ownership, links, or permissions. 5. Prevent private keys from appearing in logs, exceptions, backups, telemetry, and diagnostic output. 6. Document secure key rotation, revocation, backup, and recovery procedures. 7. Add automated tests proving that identity creation cannot persist an unencrypted private key. ]]>

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:33
Finding
Private Keys Accepted Through Observable Command-Line Arguments<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 33–46 **Vulnerability Type**: Secret exposure through process arguments and shell history **Risk Level**: High ### Vulnerable Snippet ```markdown ### createNewEthereumIdentity.js **Command**: `node scripts/createNewEthereumIdentity.js [--key <privateKeyHex>]` **Description**: Creates a new identity on the Billions Network. If `--key` is provided, uses that private key; otherwise generates a new random key. The created identity is automatically set as default. **Usage Examples**: ```bash # Generate a new random identity node scripts/createNewEthereumIdentity.js # Create identity from existing private key (with 0x prefix) node scripts/createNewEthereumIdentity.js --key 0x1234567890abcdef... # Create identity from existing private key (without 0x prefix) node scripts/createNewEthereumIdentity.js --key 1234567890abcdef... ``` ``` ### Technical Analysis The documented interface passes an existing private key through the `--key` command-line argument. Command-line arguments are not an appropriate secret-input channel because they may be retained or exposed through: - Shell history files. - Process inspection utilities and `/proc` interfaces. - Audit and endpoint-monitoring systems. - CI/CD logs and orchestration metadata. - Terminal recording, support bundles, or copied command transcripts. Quoting the key would not correct the issue because the resulting process argument would still contain the secret. The referenced implementation is absent from the supplied artifact, so any masking or additional runtime protection cannot be verified; however, the documented invocation itself creates the exposure. ### Attack Path 1. A user imports an existing identity using the documented `--key` option. 2. The shell records the full command in history, or process/audit tooling captures the command-line arguments. 3. An unauthorized local user, compromised process, administrator, monitoring operator, o ...[truncated 828 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Remove the `--key` command-line option and do not accept private keys through positional arguments or environment variables. 2. Prefer direct import from an operating-system keychain, hardware-backed keystore, hardware wallet, or other protected secret provider. 3. If interactive import is required, read the key from a non-echoing terminal prompt and clear temporary buffers as soon as practical. 4. If file-based import is unavoidable: - Require an owner-readable-only file. - Verify ownership and permissions. - Reject symbolic links and unsafe paths. - Read the key without printing it. - Securely remove any temporary import artifact where the platform permits. 5. Ensure errors, debug output, telemetry, and audit events never include key material. 6. Update all examples so users are not encouraged to paste private keys into terminals. 7. Add tests that reject private-key values supplied through process arguments and verify that logs contain no secret material. ]]>
Vulnerability Patterns
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • YARA SignaturesMalware Match, Webshell Match, Cryptominer Match
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Findings (4)

YARA rule 'agent_skill_prompt_injection_hidden_instructions': Prompt injection or hidden instructions embedded in AI agent skill text [agent_skills]

High
Category
YARA Match
Content
entity
description: Billions decentralized identity for agents. Link agents to human identities using Billions ERC-8004 and Attestation Registries. Verify and generate authentication proofs. Based on iden3 self-sovereign identity protocol.
metadata: { "category": "identity", "clawdbot": { "requires": { "bins": ["node"] } } }
homepage: https://billions.network/
---

## When to use this Skill

Lets AI agents create and manage their own identities on the Billions Network, and link those identities to a human owner.

1. When you need to link your agent identity to an owner.
2. When you need to sign a challenge.
3. When you need to link a human to the agent's DID.
4. When you need to verify a signature to confirm identity ownership.
5. When you use shared JWT tokens for authentication.
6. When you need to create and manage decentralized identities.

### After installing the plugin run the following commands to create an identity and link it to your human DID:

```bash
cd scripts && npm inst
Confidence
80% confidence
Finding
YARA rule matched a hack tool or exploit indicator (offensive tools, reconnaissance, privilege escalation, or exploit frameworks).

Credential Access

High
Category
Privilege Escalation
Content
- `kms.json` - **CRITICAL**: Contains private keys (encrypted if BILLIONS_NETWORK_MASTER_KMS_KEY is set, otherwise in plaintext)
- `defaultDid.json` - DID identifiers and public keys
- `challenges.json` - Authentication challenges history
- `credentials.json` - Verifiable credentials
- `identities.json` - Identity metadata
- `profiles.json` - Profile data
Confidence
95% confidence
Finding
The skill explicitly documents storage of highly sensitive identity artifacts, including private keys in `kms.json` that may be plaintext if `BILLIONS_NETWORK_MASTER_KMS_KEY` is unset, along with credentials and authentication history under a predictable path. In combination with the skill's signing and linking workflows, this creates meaningful credential-access risk if another tool, skill, or prompt-induced action reads from that directory or if the host is compromised.

Vague Triggers

Medium
Confidence
87% confidence
Finding
The skill declares broad, common-language usage triggers such as linking identity, signing challenges, verifying signatures, and using shared JWT tokens. In an agentic environment, these generic phrases can cause the skill to activate in situations where the user did not intend decentralized identity operations, leading to unnecessary handling of sensitive identity material or authentication actions.

Vague Triggers

Medium
Confidence
88% confidence
Finding
The example conversation uses ambiguous phrasing like 'Link your agent identity to me,' which could be interpreted as sufficient authorization to initiate a sensitive identity-linking workflow. Because the documented flow may auto-generate a challenge when one is not supplied, this lowers the bar for triggering a high-trust action and increases the risk of unintended or socially engineered identity association.

Static analysis

No suspicious patterns detected.