Openclaw Pqsafe
PassAudited by VirusTotal on May 2, 2026.
Overview
Type: OpenClaw Skill Name: pqsafe-pay-v1 Version: 0.1.0 The skill bundle provides a legitimate implementation for post-quantum signed payment envelopes for AI agents using the ML-DSA-65 (NIST FIPS 204) standard. It enables agents to create, verify, and revoke 'SpendEnvelopes' for various payment rails like Wise and Stripe. Analysis of `src/index.ts` and `dist/index.js` confirms that cryptographic signing is performed locally using the `@noble/post-quantum` library, and sensitive secret keys are never exfiltrated to the PQSafe API (https://api.pqsafe.xyz/v1). The bundle is well-documented, includes a comprehensive test suite (`tests/skill.test.ts`), and shows no signs of malicious intent or prompt-injection vulnerabilities.
Findings (0)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
If an agent has access to the signing inputs, it could create spend authorizations within caller-supplied parameters.
The skill can create a signed payment authorization. The shown schema makes maxAmount positive but does not show a global upper bound or explicit human confirmation requirement before signing.
"description": "Build and ML-DSA-65 sign a SpendEnvelope authorizing an agent to spend up to maxAmount..."
Require explicit user approval before create_envelope or revoke_envelope, enforce local spend ceilings, keep recipient allowlists tight, and use short TTLs/test mode by default.
Users may unknowingly expose a raw payment-signing key to the agent runtime rather than only using a scoped API key or HSM-backed service.
A raw ML-DSA signing secret is high-privilege because it can authorize SpendEnvelopes. This conflicts with the registry/SKILL credential story that names PQSAFE_API_KEY as the primary required credential.
"dsaSecretKey": { "description": "Hex-encoded ML-DSA-65 secret key ... Required in production." }Clarify the production credential model, declare raw signing keys explicitly if required, prefer scoped/HSM-backed signing, and never provide long-lived signing keys to autonomous agents without strict controls.
A user could trust that private keys never enter the local agent environment when the included implementation path actually requires local raw key material.
This user-facing security claim conflicts with README/code/schema excerpts that describe local signing using a provided dsaSecretKey.
"HSM-backed signing keys" — "private keys are generated and stored in hardware security modules; they never leave the PQSafe key service"
Make SKILL.md, README, metadata, and code agree on whether signing is HSM/API-based or local raw-key-based, and clearly state what secrets the agent will see.
Revoking an envelope discloses the envelope contents to the PQSafe service.
Revocation sends the full signed envelope and optional reason to the PQSafe API. That is purpose-aligned, but the envelope can include payment metadata such as issuer, agent, amount, currency, recipients, and public key.
fetch(`${apiUrl}/envelopes/revoke`, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ signedEnvelope: input.envelope, reason: input.reason }) })Review PQSafe’s privacy/retention terms and avoid placing unnecessary sensitive information in envelope fields or revocation reasons.
A dependency update or provenance issue could affect payment-signing behavior.
The skill depends on an external payment/signing package with a semver range. This is expected for the plugin, but users are relying on the provenance and future-compatible versions of that package.
"peerDependencies": { "@pqsafe/agent-pay": "^0.1.0" }Install from trusted registries, pin and audit dependency versions in production, and verify package provenance before enabling payment authority.