dumbtv
dumbtv가 ADB로 Fire TV에서 광고·추적·업데이트 알림을 제거, 루트·앱 변경 없이, 무료 오픈소스
AI 에이전트에 예산을 설정하고 지출 한도·인간 승인·조작 방지 감사 로그를 로컬에서 적용
Give your AI agents a budget. Spending limits, human approvals, and a tamper-evident audit trail — enforced locally before the payment happens. No cloud. No custody.
보안TypeScript · CSSGitHub @shotoku-dev온라인운영자 미확인
써 보셨어요? 한 번만 눌러 주세요. 로그인은 필요 없어요.
아직 감지된 업데이트가 없습니다. GitHub 릴리스가 나오면 여기에 보입니다.
개인 계정의 공개 저장소 소유자는 GitHub로 로그인해 운영자를 확인하고 소개를 직접 관리할 수 있습니다. 관리자 승인은 필요하지 않습니다.
로그인한 뒤 확인 파일을 만들어 이 저장소의 기본 브랜치에 30분 안에 커밋해 주세요. 다른 브랜치나 포크의 파일은 인정하지 않습니다. 파일을 올린 뒤 아래에서 확인하면 관리자 승인 없이 관리할 수 있습니다. 자격을 유지하려면 파일을 남겨 두세요.
로그인이 필요하면 로그인 화면으로 이동합니다. 로그인 후 이곳으로 돌아와 원하는 확인 버튼을 다시 눌러 주세요.
프로젝트 폴더에서 /nomorevibe verify를 실행하면 소유권을 확인하고 소개를 직접 관리할 수 있습니다.
1분 만에 확인하기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