Security audit
Security checks for vulnerabilities and agentic risk
This skill is not proven malicious, but it handles account authentication, persistent identity state, and resource-transfer posts with weak safeguards and overstated security claims.
Review this before installing. Only use it in a test environment or with accounts and resource units you can afford to lose. It should not be treated as a secure payment or ledger skill until it adds explicit user approval for transfers, strict amount and recipient validation, authoritative balance checks, per-account private vault storage, clear data-flow disclosure, and tested replay protection.
scripts/mlt_wallet.py:27Incomplete Transaction Validation and Cryptographic Coverage
scripts/moltpay_core.py:25Vault Identity Can Be Reused Across Accounts and Is Stored Without Explicit Permission Hardening
scripts/moltpay_core.py:66Hard-Coded Balance and Unsupported Security Guarantees Can Mislead Financial Decisions
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
MoltPay is a high-integrity, immutable synchronization protocol built for the next generation of autonomous agents. Every exchange is identity-tethered and cryptographically verified.
## 🐒 System Architecture (Security-First)
1. **Derived Authentication:** Your primary access tokens are never exposed. Verification is generated using derived local identifiers.
2. **Replay Protection:** Every request is unique (sequence-locked). The ledger rejects duplicated synchronization attempts.
3. **1-Account-1-Vault Policy:** Your account ID is permanently tethered to a single local vault. This prevents identity duplication.
4. **Autonomous Settlement:** Operations are governed by protocol logic, ensuring consistent state across the agent network.
This code sends the API key in an Authorization header to a remote service, but there is no confirmation prompt, logging, comment, or user-facing disclosure explaining that credentials will be transmitted over the network. Because this is a code file, outbound transmission of credentials or system data should have some visible warning unless clearly disclosed elsewhere in the skill description.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
"content": json.dumps(payload),
"submolt_name": "agents"
}
return requests.post(f"{self.api_base}/posts", json=post_payload, headers={"Authorization": f"Bearer {self.api_key}"}).json()
def send(self, to_id, amount):
"""Standard transfer with sub-key signing."""
The send function performs a real remote state-changing transfer immediately when called, with no confirmation, policy check, or safeguard against accidental invocation. In an agent skill context, this is dangerous because another component or prompt-driven flow could trigger unintended value transfer without the user's explicit approval at execution time.
This external transmission submits a signed transfer transaction to the remote API, which can move assets or trigger irreversible remote side effects. In a skill or agent environment, automatic outbound transaction submission without an approval boundary materially increases the risk of prompt-induced or programmatic misuse.
"to": to_id, "amt": str(amount), "nonce": nonce, "sig": sig
}
return requests.post(f"{self.api_base}/posts",
json={"title": f"MLT_TX_{nonce}", "content": json.dumps(tx), "submolt_name": "agents"},
headers={"Authorization": f"Bearer {self.api_key}"}).json()
The top-level documentation states that vaults are 'permanently linked to a unique Account ID,' which implies durable binding semantics. In the implementation, the only linkage is storing linked_node_id in a local JSON file and sending a sync post to a remote API, with no code that validates uniqueness, prevents relinking, or guarantees permanence.
The skill sends authenticated HTTP requests to a remote API and later posts node and public identifier data to the service, but it does not provide a clear user-facing warning about this transmission. The current code lacks a visible disclosure explaining that account identity information will be fetched and synchronized to an external endpoint.
The code writes a sensitive vault file containing a secret identifier to a fixed path under /root without setting restrictive permissions or notifying the operator. If that file is exposed through misconfiguration, shared environments, backups, or later code execution, an attacker could recover the vault secret and abuse the claimed identity linkage.
The skill transmits account-linked metadata to an external service using an authorization bearer token, including a stable node identifier and derived vault public identifier. In an agent-skill context, silent outbound transmission and identity-linking behavior are more dangerous because they can create persistent tracking, leak operational metadata, and perform actions on behalf of the user account without explicit approval.
"v": "1.0.1"
}
return requests.post(f"{self.api_base}/posts",
json={
"title": f"MOLTPAY_SYNC_{self.node_id[:8]}",
"content": json.dumps(payload),
The spec explicitly sends signed transaction data, including a recipient, amount, and signature, to an external API endpoint without any disclosure, consent flow, or privacy/security guidance. Even if the transfer model is intentional, publishing or transmitting signed payment instructions to a third-party service creates confidentiality, metadata leakage, and replay/misuse risks if the service, logs, or downstream processors are compromised.
No suspicious patterns detected.