尚未偵測到更新。GitHub 發布版本後會顯示在這裡。
個人 GitHub 帳號下公開儲存庫的擁有者可以登入並驗證所有權,自行管理介紹,無需管理員核准。
登入並產生驗證檔案,在 30 分鐘內將其提交至此儲存庫的預設分支。其他分支或分叉儲存庫中的檔案無效。然後在下方檢查檔案,即可無需管理員核准直接管理專案。請保留檔案以維持管理權限。
如需登入,將前往登入頁面。登入後請回到此處,再次點擊所選的驗證按鈕。
在專案資料夾中執行 /nomorevibe verify,即可驗證所有權並自行管理介紹。
一分鐘完成驗證Local-first spend controls for AI agents. Deterministic. No custody.
翻譯準備中
正在載入完整 README。
檢視完整 README ↗Spend controls for AI agents.
Shotoku lets AI agents spend money safely — budgets, human approvals, and a tamper-evident audit trail, enforced deterministically on your machine before the payment happens. No cloud. No custody. Never holds funds or keys.
The same engine authorizes any agent action — the request model is rail-agnostic (x402, MCP, API, code). Spending is where the pain is sharpest today, so that's where it starts.
Works with x402 and PayPal. Designed for any rail.
pending_approval. Small refunds go through; a big one waits for you.npm install -g shotoku-cli
No setup, nothing real happens:
shotoku demo
Four simulated decisions: two purchases approved, a third denied when the daily budget runs out, and an unknown vendor held for human approval.
An AI support agent can issue PayPal refunds through PayPal's own MCP server. A customer writes that two orders arrived broken, an $89 lamp and a $480 chair. Shotoku sits in front of PayPal's server:
agent → paypal__create_refund $89 ✓ APPROVED refunded by PayPal
agent → paypal__create_refund $480 ◷ PENDING over the $100 limit, sent to your phone
you → tap Approve or Deny
agent → retries the exact same call ✓ refunded, or ✗ blocked
The agent acts on what customers tell it and cannot tell a true claim from a false one. Shotoku does not try to: it decides how far the agent can go without you.
It runs against the PayPal sandbox in a few minutes, with a scripted agent or a real one. See examples/paypal.
# Initialize in your project directory
shotoku init
# Evaluate a spend
shotoku authorize --actor my-agent --action purchase --resource openai.com --amount 5
✓ APPROVED dec_063a20380ba7
• openai.com matched rule
• Amount $5 is within per-transaction limit of $50
• Daily budget remaining: $195
Recorded at 14:05:22
shotoku status # pending approvals + last decision
shotoku history --since 24h # decision history
shotoku decision dec_063a20380ba7 # full detail for one decision
shotoku approve dec_063a20380ba7 # approve a pending decision
shotoku ui # local dashboard: approvals, budgets, history
shotoku telegram # approve or deny from your phone
See the Quickstart guide for the full five-minute tour.
shotoku init creates three local files:
policy.yaml — the rules for what agents can do.shotoku.config.json — where Shotoku finds the policy and ledger.data/decisions.jsonl — the local audit log, created when decisions are recorded.A policy is just a checklist. Shotoku reads it before an agent acts.
rules:
- resource: openai.com
actions: [api_call, purchase]
verdict: approved
maxAmount: 50
maxDailyAmount: 200
# Refunds up to $100 on their own; a bigger one waits for a human.
- resource: paypal__create_refund
verdict: approved
maxAmount: 100
overLimit: pending_approval
budgets:
# Everything this agent spends, across every vendor, per day.
- actor: support-agent
maxDailyAmount: 1000
defaultVerdict: pending_approval
Every decision is recorded to data/decisions.jsonl. JSONL means "one JSON record per line," so the ledger stays easy to inspect.
Shotoku fails closed: if the policy is missing, invalid, or the ledger cannot be trusted, the agent is not approved. A request with no amount against a rule with a limit is held for a human, never counted as zero. An authorization layer should never guess.
maxDailyAmount is a rolling 24-hour limit, not a midnight reset. If an agent spent $20 at 3pm yesterday, that spend counts until 3pm today.
A human approval lets through the agent's next identical call, once: same agent, same tool, same arguments, same amount, within 15 minutes. It never lifts a denial and never spends past a budget.
The ledger is hash-chained: each record stores a hash of the previous record plus itself. Edit a past line and later reads fail, because the chain no longer matches. You can also create a signed snapshot of the current policy and ledger head:
export SHOTOKU_SNAPSHOT_SECRET="use-a-long-local-secret"
shotoku snapshot create --out shotoku.snapshot.json
shotoku snapshot verify --snapshot shotoku.snapshot.json
Shotoku does not store the snapshot secret. Provide it through your environment or secret manager.
Signed receipts make approvals enforceable: with SHOTOKU_RECEIPT_SECRET set, every approved decision carries a compact HMAC-signed token (decision ID, actor, action, resource, amount, 5-minute expiry). Downstream infrastructure — a payment proxy, a CI job — verifies it before executing, so an agent cannot skip the check:
export SHOTOKU_RECEIPT_SECRET="use-a-long-local-secret"
shotoku authorize --actor my-agent --action purchase --resource openai.com --amount 5
# ✓ APPROVED … Receipt: rcpt.eyJhY3Rvci…
shotoku receipt verify rcpt.eyJhY3Rvci…
See Writing policies for rules, limits, and matching in depth.
A pending decision waits for a human. Every channel does the same thing, and the ledger records which one was used.
shotoku approve dec_… or shotoku deny dec_….shotoku tui, a live queue you answer with the keyboard.shotoku ui serves a local page on 127.0.0.1: pending approvals with Approve and Deny, budgets against limits, the full history, and whether the ledger's hash chain still verifies. See Dashboard.shotoku telegram sends each pending decision to your Telegram with two buttons. Only your taps count, and nothing listens on your machine. See Approve from your phone.An agent cannot approve its own decisions: the MCP server does not expose the approval tools and refuses them if called.
Shotoku ships an MCP server (shotoku-mcp) for any MCP-compatible agent. It works two ways.
Wrapping, the one that cannot be skipped: list the MCP servers your agent uses, and Shotoku sits in front of them. Each tool is exposed as <server>__<tool> and every call is decided by your policy before it is forwarded. With a pricer, the call gets the amount it sends out of the account, so limits and budgets apply to tools that move money. "pricing": "paypal" prices PayPal's own MCP server (@paypal/mcp) and mints its access token from your app credentials at startup.
Advisory: the agent calls authorize_action itself before it acts, and get_decision / get_pending_approvals to follow up. Useful for agents you write yourself; an agent can forget to ask, which wrapping rules out.
See the MCP integration guide.
When an agent hits an HTTP 402 Payment Required, Shotoku authorizes the payment after the amount is known and before the wallet signs — the only safe point to decide. It judges the host the agent actually requested, not what the 402 response claims to be. Shotoku never signs or settles a payment; it only decides whether it is allowed. See the x402 integration guide.
Should this agent be allowed to perform this action?
Shotoku answers it with a structured decision: approved, denied, or pending human approval — each with reasons and a plain-English explanation.
Add maxAmount (per transaction) and maxDailyAmount (rolling 24 hours) to a policy rule for that vendor, and a budgets entry for the agent's total. Over a rule's limit, a request is denied with a reason naming the cap, or held for you if the rule says overLimit: pending_approval. Over a budget, it is always denied.
No. Shotoku never holds funds, stores private keys, or signs or settles payments. It only decides whether an action is allowed and records the decision. The agent's own wallet or payment provider moves the money.
No. Shotoku is local-first. The policy, the ledger, and the authorization path all run on your machine. Phone approvals send the notification through Telegram; the decision itself stays local.
Any MCP-compatible agent, plus a command-line interface, an HTTP gateway (alpha) and a TypeScript API (@shotoku/core) you can call directly.
No. x402 and PayPal are the first payment rails. Shotoku authorizes any agent action — API calls, code execution, emails, MCP tools — across any rail.
The defaultVerdict applies — pending_approval unless you set otherwise. It fails toward human review, never silent approval.
core/ — authorization, policy, ledger, approvals, and x402 primitives (@shotoku/core)cli/ — command-line interface, TUI, dashboard and phone approvals (shotoku-cli)mcp/ — MCP server: advisory tools, wrapping, and pricing (shotoku-mcp)gateway/ — local HTTP enforcement proxy (alpha)web/ — the shotoku.dev siteexamples/ — policies and runnable demosdocs/ — guides, architecture, and decisionspnpm install
pnpm build
pnpm test