不正決済・promo abuse・credential 盗用・AI compute abuse を、正当売上を壊さず制御する

Technical Summary

• 目的は「fraud を当てる」ことではない。 outcome 前に凍結した eligible exposure cohort へ一つの control revision を割り当て、不正・abuse の損失だけでなく、正当 conversion、誤検知、異議申立て、復旧、provider 原価、dispute、銀行 cash が成熟した後の差分を判断する。
• signal、action、label を分離する。 IP、device、velocity、bot score、risk score、3DS result、provider decline は観測信号であり、人物の同一性や不正の確定ではない。個別 action は ALLOW / STEP_UP / LIMIT / HOLD / DENY / RESTORE、cohort 判断は STOP > PAUSE > UNKNOWN > REMEDIATE > PROPOSE_BOUNDED_CONTROL とする。
• 六つの lane を一つの contract で接続する。 identity / recovery、trial・promo・referral、payment・dispute、entitlement、API key・AI / infra cost、case review・appeal・restore を abuse_control_contract_id / contract_version で束縛する。
• provider の防御を自社の hard limit とみなさない。 OpenAI の通知型・default Project monthly budget は soft threshold で、超過後も request は継続する。optional な enforced / hard spend limit を利用できる場合も別 control として scope、反映 lag、小額超過、429 の影響を検証し、高原価 action には app / tenant / credential / job 単位の認可、予約、hard ceiling、kill switch、reconciliation を持つ。
• 最初の action は fully synthetic な14日 rehearsal である。 live block、account suspend、refund、dispute response、顧客連絡を自動実行せず、shadow 計測、期限付き hold のシミュレーション、case review、victim-safe recovery、appeal / restore、成熟後採算を通して NEXT_CONTROL_PROPOSAL_ONLY を作る。

基準日: 2026-08-03
対象: Codex 等で Web app、subscription、API、AI feature、trial / promo / referral を一人または小規模で運用する technical founder
判断単位: seller / product / offer version × protected action × route / jurisdiction × frozen eligible cohort × assigned control revision × exposure window × maturity rule × loss / review / false-positive cap × environment

本章は product、security、決済、計測、運用の一般教材であり、個別の法律・決済・犯罪対応助言ではない。カード情報、本人確認、個人データ、通信監視、account 停止、証拠保全、外部報告、dispute は、適用法、契約、provider、地域、事故の事実に応じて専門家と確認する。

本文、運用パック、SQL companion の account、payment、credential、IP / device signal、金額、件数、incident、review、appeal はすべて fully synthetic である。実在者の不正判定、攻撃手順、検知 benchmark、推奨閾値ではない。raw card data、secret、password、session token、完全な device fingerprint、本人確認書類、support 添付を公開物や生成 AI prompt へ入れない。

Findings: 既存の点対策を「事業判断」へ閉じる空白がある

既存章は必要な部品を持つ。本章はそれらを上書きせず、unfair loss + false positive + legitimate conversion + appeal / restore + provider / cash + maturity economics の接続だけを正本にする。

正本	既存章が受け持つこと	本章が追加する接続
03章	friction、onboarding、accessibility、誠実な行動設計	challenge / hold が正当利用者の完了と信頼へ与える harm
05章	auth、Webhook、冪等、3DS、rate / cap、障害対応	exposure assignment、late label、case、appeal、reconciliation の状態系
06章	account takeover、secret、privacy、事故・法務の入口	victim と悪意ある owner を短絡せず、復旧・redress まで閉じる
10章	PSP / MoR / store、rail economics、責任	pre-payment control と正当 conversion、dispute、cash の差分
12章	AI provider usage、品質、完全負荷後原価	stolen key、quota bypass、compute abuse の hard ceiling と帰属
13章	threat、eval、review、release evidence	control revision を exact artifact / config / reviewer へ束縛
18章	referral / affiliate の契約、commission、maturity	end-user Sybil、self-referral、stolen-card conversion、related-party uncertainty
19章	time zero、assignment、ITT、harm、uncertainty	control 固有の late fraud label、false-positive loss、appeal correction
20章	crawler / agent identity、edge、402、resource rights	credential stuffing、card testing、compute theft の入口 signal だけを参照
21章	authorization 以後の settlement、dispute、bank cash	control cohort から下流 cash bridge へ一度だけ引き渡す
23章	offer、trial、discount、契約・表示	一人一回等の eligibility と abuse recovery。表示義務は23章を正本にする

Definitions and scope

fraud、abuse、compromise、dispute を同義語にしない

語	この章での意味	単独では言えないこと
FRAUD / ABUSE SIGNAL	velocity、relation、network、payment、behavior、resource 使用等の観測	本人が不正者であること、損失が確定したこと
POLICY ACTION	allow、step-up、limit、hold、deny、restore の実施記録	action が正しかったこと、損失を防いだこと
BUSINESS OUTCOME	signup、payment、entitlement、accepted AI job、refund 等の状態	最終 cash、fraud / legitimate の成熟 label
PROVIDER OUTCOME	authorization、decline、challenge、settlement、usage invoice 等	issuer / provider の結果が ground truth であること
COMPROMISED	credential、session、account 等が正当 owner 以外に使われたという reviewed label	account owner 自身が悪意を持つこと
DISPUTE / CHARGEBACK	cardholder・issuer・rail 上の異議と資金移動	merchant fraud の確定、同じ principal loss を refund と二重計上してよいこと
MATURED LABEL	事前定義した期限と evidence を満たす reviewed outcome	将来の dispute が絶対にないこと
FALSE POSITIVE	mature legitimate action に control harm が生じた reviewed outcome	challenge を出した全件、decline 全件が誤検知であること

Stripe の card testing 文書は、盗まれたカード情報の有効性確認に小額・失敗 authorization 等が現れ得る一方、単一 IP だけでなく login/session、CAPTCHA、rate limit、異常行動、継続監視を組み合わせるよう説明する。retry や dunning も似た形になり得るため、failed payment = attack としない。Radarの risk / 3DS / review / block rule も provider signal と action であり、正当 conversion と dispute の実測を不要にはしない。

exact control contract

abuse_control_contract_id / contract_version:
seller / product / offer_version / protected_action_class:
route / jurisdiction / environment:

frozen eligibility definition / exclusion / time zero:
reference policy / candidate policy / assignment method:
exposure window / follow-up end / maturity rule version:

maximum principal loss / compute cost / review load:
maximum legitimate harm / false-positive rate / restore delay:
minimum maturity / label / provider / cash reconciliation coverage:

incident owner / case owner / appeal owner / cash owner:
hard-stop owner / rollback artifact / customer remedy:
authority cap: NEXT_CONTROL_PROPOSAL_ONLY
live action authority: NONE

contract ID は join key であり、安全性や合法性を作らない。policy、route、offer、maturity rule、threshold、data collection、review capacity のいずれかを変えたら version を上げ、古い approval を継承しない。

minimum grain は outcome 前の一 business action

risk_exposure_id
= one pre-outcome eligible business action
  (SIGNUP | LOGIN | RECOVERY | PROMO_REDEMPTION | PAYMENT_ATTEMPT |
   REFERRAL_CLAIM | API_AI_JOB | ENTITLEMENT_USE)

retry identity
= business_action_id + attempt_sequence

attempt 件数と unique business action、account、credential、payment instrument、beneficiary / referrer を別々に表示する。HTTP request をそのまま顧客や fraud 件数にしない。account、credential、payment instrument、beneficiary、referrer、device / network signal は別 entity とし、推定 relation だけで destructive merge や「同一人物」認定をしない。

event spine は append-only にする

ELIGIBLE_EXPOSURE_FROZEN
→ SIGNALS_OBSERVED_AS_OF
→ POLICY_ACTION_RECORDED
→ BUSINESS / PROVIDER OUTCOME
→ CASE REVIEW
→ APPEAL / REMEDIATION / RESTORE
→ SETTLEMENT / DISPUTE / CASH / COST RECONCILIATION
→ MATURITY_SNAPSHOT
→ CONTROL DECISION

late dispute、victim report、appeal accepted、refund、provider invoice correction は過去 row の上書きでなく correction event として結ぶ。Stripe PaymentIntent lifecycleのように payment は複数状態を通り得る。Webhookは重複し得て順序も保証されないため、署名確認、event ID の重複排除、非同期処理、object 状態の再取得を行い、idempotency keyを business action と結ぶ。

occurred_at / observed_at と、信頼するledgerへ入った recorded_at を分ける。判断snapshotへ含めるのは両方がcutoff以前のrevisionだけであり、snapshot後に届いたbackdated correctionで過去のfalse-positive率や採算を書き換えない。late evidenceは次のsnapshotで再評価する。

incident と dispute も同じである。状態行をUPDATEせず、stream内の sequence / supersedes / recorded_at でcontainmentや提出済み状態を追記し、decision-as-ofで最新のrevisionだけを読む。resource guard evidenceはcandidate policy IDだけでなくdigestとpolicy freeze後のfreshnessへ束縛する。

Threat model: 15の壊れ方を control より先に書く

#	failure case	入口で見る証拠	fail-safe / remedy
1	一 account / IP から多数カード・小額 authorization を行う card testing	unique instrument、attempt sequence、decline reason、velocity	payment だけでなく session / challenge / limit、PSP 連携、containment
2	proxy、IPv6、複数 account の distributed / low-and-slow testing	account・instrument・beneficiary relation、長い window	IP 一点依存を避け、coarse relation と行動の組合せ、人 review
3	auth 成功後に entitlement / AI compute を消費し、後日 dispute	payment intent、entitlement、accepted job、usage、dispute	high-cost fulfillment の段階化、reserve、maturity 後に採算評価
4	Webhook replay、逆順、timeout retry で二重 charge / entitlement / refund	provider event ID、business action、state transition	signature、dedupe、idempotency、明示 state machine、reconciliation
5	海外利用、法人 NAT、旅行、端末変更、複数カードを誤検知	shared-network context、prior trusted session、appeal	step-up の代替、hold 期限、human review、迅速 restore
6	3DS / challenge 障害や accessibility 不備で正当 conversion を失う	challenge availability、completion、WCAG review、arm conversion	fail mode を事前定義、代替確認、status page、harm cap
7	alias、複数 tenant、invite、device reset、instrument 変更で trial / promo を反復	eligibility basis、benefit owner、tenant relation、prior redemption	server-side eligibility、benefit hold、正当 multi-tenant exception
8	self-referral、related party、code stuffing、duplicate claim、stolen-card conversion	referrer / beneficiary / order relation、refund/dispute maturity	commission holdback、dedupe、clawback、partner appeal
9	credential stuffing、session theft、password-reset abuse	login / recovery velocity、known session、phishing-resistant factor	MFA / passkey、reauth、session revoke、victim-safe recovery
10	support social engineering で email / MFA / key recovery を奪う	immutable recovery events、operator、evidence class	high-risk change delay、dual review、out-of-band notice、restore path
11	key が repo、frontend、log、support 添付から漏れ、別 tenant で利用	key ID、project / tenant / region / model、rotation events	server-side secret、least privilege、separate keys、revoke / rotate
12	multi-key / account、retry fan-out、巨大入力、tool recursion で quota を迂回	tenant-wide reserved cost、job depth、payload、concurrency	application hard ceiling、reservation、timeout、bounded tool graph
13	provider budget / alert の lag・soft limit・scope 違いを hard stop と誤認	provider config、app counter、invoice / usage export	provider alert と app hard stop を別 control として検証
14	edge と origin の policy drift で人を遮断、または origin cost だけ発生	edge action、origin auth、protected action、deployment digest	log-before-block、contract test、origin enforcement、rollback
15	IP / device / geography / language proxy の過収集・差別的影響・誤関連	purpose、retention、access、groupwise harm、appeal correction	data minimization、coarse signal、redress、削除・訂正、専門家確認

この表は検知 rule ではない。攻撃者に合わせた threshold や bypass 手順を公開せず、守る business flow、許容損失、誤検知上限、復旧責任を先に固定する。OWASP API6は referral 等の sensitive business flow 自体を abuse 対象として扱い、Business Logic Security Cheat Sheetは price / permission の server-side 再導出、明示 state machine、concurrency control、feature-level rate limit を勧める。

Methodology: 六つの lane に control と evidence owner を置く

1. Identity、session、recovery

OWASP Credential Stuffing Preventionが示すように、MFA、breached-password 対策、rate limit、device / connection intelligence 等を defense in depth で組み合わせる。password 成功を本人性、API key を end-user identity としない。OWASP API2は login だけでなく password reset / recovery、reauth、rate limiting も authentication surface とする。

NIST SP 800-63B-4では WebAuthn / FIDO2 等の phishing-resistant authentication と rate limiting を区別できる。ただしこれは米国連邦 digital identity guidance であり、全 consumer SaaS の一律法的要件ではない。session の device / IP / velocity monitoring には privacy implication があるため、NIST の session guidanceを設計材料として、収集目的・保存期間・利用者通知・誤停止時の救済を決める。

高リスク recovery の最低線:

• recovery 前後の actor、factor、session、contact change、key rotation を append-only にする。
• email、MFA、payout、API key、owner role を同時変更できる万能 support path を作らない。
• trusted session が残る場合の victim path、全 session revoke、key rotate、entitlement restore を一つの runbook にする。
• account 削除や永久停止より先に期限付き hold と evidence review を使い、appeal の入口を通知する。

2. Trial、promo、referral eligibility

discount code を秘密にするだけでは eligibility control にならない。benefit を得る主体、払う主体、紹介者、tenant、invoice / payment instrument、過去 redemption、返金・dispute maturity を別 entity として結ぶ。

eligibility = offer_version
            + eligible actor / tenant / benefit owner
            + one-time / period / region / channel rule
            + exclusion and legitimate exception
            + evidence as_of exposure time

• client の表示値ではなく server が current offer と eligibility を再導出する。
• referral conversion は signup や authorization で確定せず、accepted value、refund / dispute window、cash、holdback を経る。
• self-referral や related party は relation signal とし、正当な同一法人内紹介や複数 tenant の exception / appeal を用意する。
• benefit を取り消すときは、subscription、invoice、entitlement、partner commission を別 event で訂正し、同じ principal を重複控除しない。

commercial rule、commission base、clawback は18章、offer 表示と同意は23章を正本にする。

3. Payment、step-up、settlement、dispute

クレジット取引セキュリティ対策協議会（事務局: 日本クレジット協会）が策定した現行クレジットカード・セキュリティガイドライン6.1（2026年3月）は、EC 加盟店の不正利用対策を、決済前の不正 login / account、決済時の EMV 3-D Secure、決済後の対応を一続きの「線」として捉える。EC加盟店はEMV 3-D Secureを導入し、原則すべての決済で本人認証を行う枠組みをbaselineとし、risk-based authentication、会員登録時の本人認証、非導入にはそれぞれ定められた条件・例外がある。自社がどの条件に該当するかをPSP / acquirerと確認し、例示や特定providerの数値を全SaaSのuniversal thresholdにしない。カード情報を保持しないEC加盟店にもWeb siteの脆弱性対策は必要である。

PCI DSS v4.0.1の対象と検証方法も current integration で確認する。PCI SSC の SAQ A iframe FAQが示すように、payment form を第三者 iframe へ委託しても、merchant page 上の script 等に関する全責任が自動で消えるとは限らない。PSP、acquirer、card brand、必要に応じ QSA へ scope を確認し、「カード番号を保持しない = 決済security義務なし」としない。

payment attempt
≠ authorization success
≠ capture
≠ settlement / provider balance
≠ payout initiated
≠ bank cash
≠ mature legitimate contribution

• PaymentIntent 等を一 cart / session の business action に対応させ、retry を新規売上へ膨らませない。
• 日本向けcard paymentでは、EMV 3-D Secureの導入・適用coverageと、issuerがfrictionlessに通すかchallengeを要求するか、さらに自社が追加step-upを課すかを分ける。baseline / 例外の適用はPSP / acquirerと確認し、issuer challenge availability / completionと正当conversionを測る。追加step-upの無差別適用はfrictionを増やし得る。
• Stripe dispute guidanceのように response deadline、提出回数、issuer decision、長い outcome window は provider / region で異なる。期限・evidence owner・cash reserve を snapshot する。
• test は provider の test mode / test card を使い、live card data で試さない。Stripe testing

4. Entitlement と protected product action

payment だけを守っても、free export、expensive report、AI job、invitation、coupon issuance、payout change が無制限なら損失は残る。action ごとに次を置く。

control	役割	fail-open / fail-closed の判断
authorization	actor が action を実行できるか	account login 成功だけで tenant / role entitlement を与えない
idempotency	同一 business action の再実行を抑える	provider retry と user retry の key を区別する
reservation	実行前に quota / budget / inventory を確保	timeout 時の解放と二重予約を test する
concurrency / depth	fan-out、recursive tool、parallel export を抑える	tenant 全体と job 単位の両方を持つ
graduated fulfillment	irreversible / high-cost value を段階的に渡す	正当顧客の価値到達時間を同時に測る
audit / restore	誰が何を止め、戻したか	manual override に期限・理由・reviewer を付ける

5. API credential、AI compute、infra cost

OpenAI の API key safety guidanceは、client への key 埋込を避け、secret management、key 分離、監視、漏えい時の rotation / revocation を求める。Project-based keysで環境や利用を分離しても、authorization、tenant attribution、hard cost ceiling は自社で持つ。

特にOpenAI Projects の monthly budgetは soft threshold であり、超過 request を止めない。alert は evidence であって enforcement ではない。

account でenforced spend limitを利用できる場合も、通知型 alert とは分ける。反映 lag、小額超過、scope、429 による正当 production job の停止可能性を確認し、provider limit 一つへ安全と可用性を預けない。

request admission:
  authenticated project key
  + authorized tenant / user / feature
  + idempotent business action
  + reserved worst-case cost
  + per-job token / time / tool-depth ceiling
  + tenant / key / model / day hard balance
  + cancellation and rollback path

OWASP API4は timeout、payload、records、operations、第三者 service spend 等の limit を明示する。provider usage export と自社 accepted job、key / project / model、invoice / credit を照合し、unattributed / unreconciled usage をゼロ原価にしない。

GitHub の credential guidanceに沿って least privilege、expiry、secret manager、rotation plan を持ち、push protectionは重要な予防層として使う。ただしsecret scanning の scope / limitationsがあるため、scan green を漏えいなしの証明にしない。

6. Case review、appeal、restore、customer remedy

control の品質は block rate でなく、誤った harm をどれだけ見つけ、戻し、再発を減らしたかでも測る。

case_id / risk_exposure_id / opened_reason:
reviewer / evidence_as_of / victim-or-abuser uncertainty:
decision / reason category / expiry:
customer notice / appeal channel / accessibility alternative:
appeal received / independent review / correction event:
restore target / restored_at / entitlement and cash correction:
retention / deletion / legal escalation:

NIST SP 800-63A-4 の redress guidanceは、誤った suspension 等について理由と再有効化の選択肢を示す設計材料になる。ただし米国連邦 identity proofing の文脈であり、全 SaaS の法的義務を一律に定めるものではない。日本で personal data 漏えい等が疑われる場合は、個人情報保護委員会の漏えい等対応と06章を参照し、対象・期限・本人通知を事実に即して確認する。

Edge control は origin の代替ではない

Cloudflare rate limitingは login、API、resource exhaustion 等の入口を守れる。best practicesの path、response、operation / complexity の考え方を使い、例示 threshold や plan-specific feature を自社 benchmark にしない。

• Turnstile は client widget の表示だけで完了しない。Siteverify による server-side validationが必須で、token は5分・single use である。business action との idempotency も検証する。
• Bot scoreは自動化らしさの signal であり fraud label ではない。granularity と availability は plan に依存する。
• API Shieldの JWT validation、schema、mTLS、sequence analytics 等は defense layer である。まず log / shadow で legitimate traffic を確認し、origin の authorization、quota、idempotency を残す。
• edge rule revision、origin policy revision、deployment digest を同じ control contract へ結び、片側だけ更新されたら UNKNOWN または PAUSE とする。

Measurement: 防いだ件数でなく成熟後の差分を測る

Primary KPI

matured_risk_adjusted_contribution
= matured legitimate settled contribution
  - fraud / refund / chargeback principal loss and dispute fee
  - unearned promo / referral / trial cost
  - AI / infra / edge / PSP variable cost
  - review / support / remediation / restore cost
  - measured or explicitly estimated false-positive lost contribution

matured_risk_adjusted_contribution_delta
= candidate per eligible exposure - reference per eligible exposure

principal loss は refund、chargeback、fraud write-off の排他的な loss group で一度だけ計上する。dispute fee、support、AI usage は別 component とする。blocked attempt は「回避できた損失」ではなく avoided exposure と呼び、counterfactual がなければ realized savings へ入れない。

必須 denominator と guardrail

metric	numerator / denominator	UNKNOWN 条件
maturity coverage	maturity 到達 exposure / eligible exposure	cohort cutoff、maturity rule が未固定
label coverage	reviewed label あり / matured exposure	provider decline や risk score だけ
legitimate completion	legitimate accepted action / mature legitimate exposure	legitimate label が未成熟
false-positive harm	control で失敗・遅延した mature legitimate / mature legitimate	appeal / case と join 不能
abuse control rate	deny / hold / limit 後も成熟 abuse と判明した exposure / mature abuse	block を abuse label と循環定義
restore completion	期限内に entitlement / access / cash を訂正 / accepted appeal	restore receipt、期限、対象が欠落
resource reconciliation	provider usage と自社 action が一致 / provider usage line	project / key / model / invoice join 不可
review load	review minutes / eligible exposure、queue p95	owner 作業を無料・ゼロ時間扱い
risk-adjusted contribution	上式 / eligible exposure	component missing、unmatured、unreconciled

小標本では点推定だけで expansion を決めず、reference / candidate の absolute count、rate、期間、missingness、late labels、range / sensitivity を併記する。assignment と ITT の詳細は19章を正本にする。

fully synthetic arithmetic example

次は計算を検査するだけの架空例であり、14日、200 exposure、金額、率は推奨値でも実績でもない。両 arm の全 exposure が contract 上成熟し、provider / cash / cost が照合済みという仮定を置く。

component	reference	candidate	candidate - reference
eligible / matured exposure	200 / 200	200 / 200	0
legitimate settled contribution	¥240,000	¥252,000	+¥12,000
fraud / refund / chargeback principal + fee	-¥72,000	-¥36,000	+¥36,000
unearned promo / referral / trial	-¥18,000	-¥12,000	+¥6,000
AI / infra / edge / PSP variable cost	-¥54,000	-¥60,000	-¥6,000
review / support / remediation / restore	-¥12,000	-¥18,000	-¥6,000
false-positive lost contribution	-¥30,000	-¥18,000	+¥12,000
matured risk-adjusted contribution	¥54,000	¥108,000	+¥54,000
per eligible exposure delta	¥270	¥540	+¥270

candidate が利益を増やしても、secret compromise、cross-tenant exposure、hard cost breach、未対応 dispute、restore failure 等の veto を相殺しない。逆に loss が減っても legitimate conversion や review capacity を壊す control は拡大しない。

Decision state と authority

STOP
> PAUSE
> UNKNOWN
> REMEDIATE
> PROPOSE_BOUNDED_CONTROL

state	代表条件	work order
STOP	active secret / session compromise、cross-tenant exposure、hard cost ceiling 超過、live authority 昇格	STOP_AND_CONTAIN。key revoke、session containment、境界修復、証拠保全を人が実行
PAUSE	incident 未封じ込め、dispute deadline / review queue / rollback が危険、new exposure を安全に受けられない	PAUSE_NEW_EXPOSURE。既存顧客の remedy と containment を優先
UNKNOWN	policy / evidence stale、maturity / label / provider / cash / cost coverage 不足、join drift	COLLECT_MISSING_EVIDENCE。missing を0にしない
REMEDIATE	false-positive / restore / privacy / accessibility cap 違反、成熟後 contribution が floor 未満	REMEDIATE_CONTROL。対象と期限を狭く修正し再測定
PROPOSE_BOUNDED_CONTROL	veto なし、coverage / economics / harm / review capacity 合格、独立 review と署名 ref が exact snapshot に一致	PROPOSE_NEXT_CONTROL_VERSION。live 適用は別承認

SQL や Codex の実行上限は NEXT_CONTROL_PROPOSAL_ONLY、live_action_authority = NONE とする。自動 block、account suspend / delete、refund、dispute submission、commission clawback、顧客連絡、regulator / law-enforcement report、key revoke を判断出力から直接起動しない。

14日 synthetic rehearsal

day	action	exit evidence
0	contract、protected action、eligible cohort、reference / candidate、caps、maturity を凍結	versioned contract、owner、rollback、authority cap
1–2	exposure / signal / action / outcome の shadow logging	raw secret・card dataなし、business action / retry join test
3	provider / cash / AI usage の reconciliation dry-run	unmatched line と correction procedure
4	15 failure case の defensive coverage review と、別建ての executable rule / decision assertion	catalog coverage、assertion result、expected state、owner、containment plan
5–7	candidate を fully synthetic または shadow で評価し、hold / deny はsimulateする	assignment、action revision、expiry、simulated override log。live holdはこのrehearsal外の別human-approved change contractが必要
8–9	case review と victim-safe recovery drill	evidence class、reason、session / key / entitlement restore
10	appeal / accessibility alternative を試す	contactability、independent reviewer、restore receipt
11–12	late dispute、refund、provider credit、cost を追記	principal loss exclusivity、bank / provider / usage join
13	maturity snapshot と sensitivity	missing / pending を明示、arm別 absolute count
14	independent review と bounded proposal	exact snapshot hash、signature ref、NEXT_CONTROL_PROPOSAL_ONLY

実データへ進む前に、fraud / abuse control packを複製し、fully synthetic SQLite companionの 15-case defensive coverage catalog と executable rule / decision assertions を確認する。catalog は各 failure case の防御意図・expected state・owner を文書化した coverage であり、15件すべての攻撃を end-to-end で再現・実証した test result ではない。実行可能な assertion では state priority、principal-loss exclusivity、maturity、appeal / restore、provider reconciliation、authority cap の境界を別に壊して確かめる。

Codex へ渡す境界

任せられること

• event schema、state transition、idempotency、quota reservation、reconciliation query の実装案
• synthetic card-testing / promo / recovery / leaked-key / fan-out fixture と negative test
• control config diff、deployment digest、coverage / false-positive / cost readout の生成
• raw secret や個人データを除いた case packet の整形
• missing evidence、stale policy、cross-tenant join、principal loss 重複の fail-closed lint

任せないこと

• risk score から「不正人物」を確定すること
• raw card、password、session、API key、本人確認書類、support 添付の prompt 投入
• live rule、refund、account 停止、dispute response、顧客通知の無承認実行
• provider alert を hard ceiling と宣言すること
• IP、device、地域、言語等の proxy だけで本人同一性・違法性を断定すること

repository では control contract、threat case、synthetic fixture、expected state、rollback、observability、privacy review を同じ change_id へ結ぶ。rule threshold は secret / restricted config とし、public docs には目的、上限、測定法、authority boundary だけを出す。

Limitations and robustness

• 本章は検知モデル、card network rule、PSP 契約、KYC / AML、刑事対応、個別 privacy impact assessment の代替ではない。
• provider feature、plan、risk rule、budget、fee、dispute window、3DS liability、Cloudflare availability は変わり得る。実装時点の account / region / plan / contract で再確認する。
• 14日では長い chargeback / refund / renewal を成熟させられない場合がある。その場合は historical eligible cohort、長い follow-up、reserve、UNKNOWN を使い、14日を万能 window にしない。
• false-positive lost contribution の counterfactual は直接観測できないことがある。appeal、holdback、randomized / phased control、bounded estimate と sensitivity を使い、ゼロにも精密値にも偽装しない。
• bot / fraud detection は適応的であり、過去 fixture の pass は将来安全の保証ではない。control performance、groupwise harm、attacker adaptation、provider drift を継続監視する。
• SQLite companion は文字列・時刻・参照・集計・期待状態を検査し、対象event rowのUPDATE / DELETE禁止と追記訂正を模擬するdisposable modelである。実logの完全性、artifact hashの再計算、cryptographic signature、reviewer identity / competence、本番storageの追記耐久性は証明しない。本番では権限制御されたevent storeと独立したartifact / signature検証を置く。
• chart は掲載しない。実測時系列や分布がなく、synthetic count の図示は経験的傾向や benchmark を暗示するためである。exact mapping と算術表を使う。

Recommendations

1. 今週もっとも高価または不可逆な protected_action_class を一つだけ選ぶ。
2. outcome 前の eligible exposure と reference / candidate assignment を凍結する。
3. signal、policy action、provider outcome、reviewed label、appeal、restore、cash / cost を別 event にする。
4. provider alert の外側に tenant / key / job の hard ceiling と cancellation を置く。
5. false-positive と restore を loss prevention と同格の release gate にする。
6. control を14日のfully synthetic / shadow rehearsalで評価し、maturity不足ならUNKNOWNのまま止める。live bounded pilotは別contractとhuman approvalでのみ行う。
7. 独立 reviewer が exact snapshot を確認した NEXT_CONTROL_PROPOSAL_ONLY だけを次の human approval へ渡す。

Further questions

• 一件の abuse が最大損失になる action は、payment、export、AI job、payout、invite のどれか。
• legitimate customer が challenge を完了できないとき、期限付き代替と contactable appeal があるか。
• payment / promo / referral / AI usage の maturity window は別々に定義されているか。
• provider budget が soft、遅延、project 単位だった場合に止める app-side hard control は何か。
• support operator 一人が identity、MFA、email、key、payout を同時に変更できないか。
• false positive、review queue、restore delay、privacy / accessibility harm をどの cap で止めるか。
• refund、chargeback、fraud write-off、provider credit、commission reversal の principal を二重計上していないか。
• next control が失敗したとき、どの exact config / artifact へ、誰が、何分で戻せるか。

この問いへ証拠付きで答えられない場合、必要なのは高度な fraud model ではなく、まず decision contract、event grain、hard ceiling、reconciliation、appeal / restore の整備である。