Valiron

Intercept and authorize outgoing machine-to-machine payments (x402 or similar) using @valiron/sdk trust decisions on the counterparty agent before payment ex...

Security Scan

The skill's code, instructions, and declared credential needs align with a payment-interceptor/trust-gate purpose; I found no requests or installs that are disproportionate or unrelated to that purpose.

Purpose & Capability

Name/description (payment interception using Valiron trust decisions) match the included source and runtime instructions. The primary credential (VALIRON_API_KEY) and references to @valiron/sdk and payment rail libraries are appropriate for this functionality. The SKILL.md also documents optional env vars (VALIRON_BASE_URL, VALIRON_TIMEOUT_MS), which are reasonable though not listed under required env vars in the registry metadata.

Instruction Scope

SKILL.md confines runtime actions to extracting counterparty identity, calling the Valiron SDK (checkAgent/getWalletProfile), applying a policy, and enforcing spend controls; it does not instruct broad system scans, exfiltration, or access to unrelated secrets. The included policy validator enforces sane path rules (no absolute paths, no path traversal) and file size limits. Logging/audit guidance includes redaction guidance.

Install Mechanism

No install spec or remote downloads are present (instruction-only plus two local code files). There are no URLs or archive extraction steps. Dependencies referenced (e.g., @valiron/sdk) are typical npm packages for this use case; the skill does not attempt to fetch arbitrary code at runtime.

Credentials

Only VALIRON_API_KEY is declared as the primary credential; SKILL.md explains that the API key is optional in some deployments and lists additional optional env vars for configuring endpoint and timeouts. No unrelated credentials or broad secrets are requested.

Persistence & Privilege

always is false and the skill does not request persistent system-wide privileges or attempt to modify other skills. It instructs normal startup validation and policy checks but does not assert elevated platform presence.

Assessment

This skill appears coherent and focused on adding a trust gate before outgoing payments. Before installing: (1) verify the provenance of the @valiron/sdk npm package and review its upstream source; (2) store VALIRON_API_KEY and other secrets in a secrets manager (do not hardcode); (3) review and test your decision policy JSON and the provided validator locally to ensure it enforces your intended limits; (4) pick conservative fallback modes (fail-closed) for high-value flows and test fail-open behavior in a sandbox; (5) confirm logging/audit configuration redacts secrets as recommended. If you need higher assurance, review the actual @valiron/sdk runtime behavior (network endpoints, telemetry) and run the validator on representative policy files.

Valiron Payment Interceptor

Add a trust gate in front of outgoing agent payments.

Runtime requirements

Declare and validate runtime prerequisites before enabling the interceptor:

• Node.js runtime compatible with your app and @valiron/sdk.
• Installed dependencies:
  • @valiron/sdk
  • Your payment rail package(s) (x402 or equivalent) used by the host app.
• Configuration/credentials (via secret manager or env vars):
  • VALIRON_API_KEY (optional today; reserved for authenticated deployments)
  • VALIRON_BASE_URL (if using non-default endpoint)
  • VALIRON_TIMEOUT_MS (optional, with safe default)
• Policy/config inputs:
  • Decision policy JSON (route-to-action matrix)
  • Spend limit defaults and per-route overrides

Fail startup (or fail closed for payment endpoints) when required policy/config inputs are missing. If your deployment enforces SDK auth, treat VALIRON_API_KEY as required.

Workflow

1. Extract counterparty identity from the payment request.
   • Prefer counterpartyAgentId.
   • Support wallet fallback with getWalletProfile(wallet).
2. Evaluate trust with Valiron.
   • Fast path: checkAgent(agentId).
   • Full path: getAgentProfile(agentId) when you need reasons/signals, pricing, or audit details.
3. Apply deterministic decision policy from references/decision-policy.md.
4. Enforce spend controls from references/spend-controls.md.
5. If allowed, continue to payment initiation (x402 challenge creation or equivalent flow).
6. If blocked/restricted, return explicit denial/degrade reason.
7. Log outcome using references/audit-events.md.

Decision model

Map route decisions to payment actions:

• prod: allow payment under normal limits.
• prod_throttled: allow with reduced caps/rate limits.
• sandbox: allow only test/sandbox payment rail (or deny prod transfer).
• sandbox_only: deny outgoing payment.

Never authorize payment using free-form model output alone.

x402-specific sequencing

For x402-protected purchases or settlement-like flows:

1. Trust-check counterparty identity.
2. Evaluate route + spend policy.
3. If denied, abort before creating payment commitment.
4. If allowed, generate/send x402 payment payload.
5. Record authorization decision + amount + result.

Outage and fallback

Use endpoint-class fallback from references/fallback-modes.md:

• High-risk payment actions: fail-closed.
• Low-risk/test actions: optional fail-open-guarded with strict caps.

Keep fallback mode explicit and versioned.

Use bundled resources

• Runtime + credential checklist: references/runtime-requirements.md
• Decision matrix: references/decision-policy.md
• Spend/risk controls: references/spend-controls.md
• Fallback guidance: references/fallback-modes.md
• Audit schema: references/audit-events.md
• Error handling: references/error-handling.md
• Interceptor template: assets/payment-interceptor.ts
• Policy validator: scripts/validate-payment-policy.mjs