Openclaw Pqsafe
SuspiciousAudited by ClawScan on May 10, 2026.
Overview
This looks like a coherent payment-signing integration, but it can create spend authorizations and its API-key/HSM credential story conflicts with code that requires raw signing keys.
Review this carefully before installing. Only use it with explicit human approval for spend-envelope creation and revocation, strict spending/recipient policies, short expirations, and pinned audited dependencies. Do not give an autonomous agent raw production signing keys unless you fully understand and control the payment authority that key grants.
Findings (5)
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.