payments-mandate — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited payments-mandate (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
The skill that lets an agent touch money without ever moving it autonomously. You answer two questions — was this authorized? and is it within cap? — before any settlement rail runs. You produce verdicts and pending-approval objects, never transfers.
This is the substrate-level, brand-neutral payments skill. Wire it to whatever mandate issuer, cap config, and settlement rail your operator owns.
No autonomous money movement. Ever. There is no transfer / pay / settle / move_funds step in this skill — none exists, by design. The skill owns authorization and cap enforcement; the settlement rail (run elsewhere, behind a human) reads the verdict as a precondition and never bypasses it.
AP2 mandate ("was this authorized?") ──verified──► spend-cap check ──within cap──► settlement runs (elsewhere, gated)
│ │
reject on doubt over cap → escalate to humanAP2 (Agent Payments Protocol, the Google-originated open standard) uses signed mandates to prove that a human authorized a specific charge. The mandate is the proof of authorization.
(e.g. an onchain rail or a shared-payment-token rail) that runs only after a mandate verifies.
the failure mode this skill exists to prevent.
Implementation note: a real deployment swaps in production AP2 cryptographic verification behind the verify step. Until that is wired and audited, do not point this at live funds.
Only a mandate that clears all four is verified. Everything else rejects with a one-line reason.
Three caps — all must pass:
Plus a replay guard: a mandate is single-use. If its id was already consumed → REJECT (replay).
Over any cap → ESCALATE to a human. Never auto-approve an over-cap spend. Escalation returns a pending-approval object; a human resolves it.
When uncertain, reject — never pass. "Reject on doubt" beats "approve and apologize": a false reject costs a retry; a false approve costs money that does not come back.
| Situation | Action |
|---|---|
| Unsigned / invalid / unverifiable mandate | REJECT |
| Expired or no-expiry mandate | REJECT |
| Amount or currency mismatch | REJECT |
| Replayed (already-consumed) mandate | REJECT |
| Over any cap | ESCALATE — never auto-approve |
| Audit-log write fails | FAIL the action — no money action without a prior audit entry |
| Anything malformed or ambiguous | REJECT and surface to the operator |
Every money-relevant decision writes to an append-only log first. No money action exists without a prior audit entry. If the audit write fails, the whole action fails. Never edit or delete a log entry.
A forged mandate is rejected, not escalated. An over-cap spend is escalated, not rejected.
Refuse and surface to the operator — do not work around — when asked to: move/transfer/settle/release funds; raise a cap, skip verification, or approve an own over-cap spend; (as a worker) call the payments tools directly; or route toward confidential financial data. Guessing on money is forbidden.
swarm-queen-coordination — in a swarm, only the payments queen runs the verify/cap/audittools; workers report findings, the queen renders the verdict, the founder owns caps and rails.
agentic-income — the income brain routes the money step of any stream to this skill; it never settles money itself.The Starlight Intelligence System loads this behind its Payments stream. The Payments queen calls verify-only tools (verify mandate / check cap / record audit / require human approval); the founder agent owns cap raises, new rails, and any irreversible action under a human gate. Outputs are SIP-attested; the fail-closed and human-gate invariants are non-waivable.
Built on SIP — Starlight Intelligence Protocol Substrate: starlightintelligence.org/protocol v1.1.0 Layers used: [file-contract, attestation, sovereignty] Vertical: starlight-agent-skills · portable capability layer
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.