Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
【AWS Dogwood入門】一語だけ違うポリシー
Search
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
赤神青空
PRO
August 23, 2026
Video
Programming
42
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
【AWS Dogwood入門】一語だけ違うポリシー
赤神青空
PRO
August 23, 2026
Video
More Decks by 赤神青空
See All by 赤神青空
【基本情報対策】CPU・メモリ・キャッシュ
akagami
PRO
0
9
【AIニュース】Anthropic が Git から Scion に移った理由
akagami
PRO
0
16
【AIニュース】Grok Voice 3.0 とは何か
akagami
PRO
0
18
【基本情報対策】探索・整列と計算量
akagami
PRO
0
14
【AIニュース】GPT-6 の Intelligent UI とは何か
akagami
PRO
0
21
【基本情報対策】スタック・キュー・木
akagami
PRO
0
16
【基本情報対策】AI・機械学習の基礎
akagami
PRO
0
22
【基本情報対策】浮動小数点と誤差
akagami
PRO
0
23
【AIニュース】Claude for Google Workspace とは何か
akagami
PRO
0
33
Other Decks in Programming
See All in Programming
GemmaをJevのように使ってみる / Use Gemma like Jev
kishida
5
790
PumaからFalconに移行したRailsアプリケーションでの実践
falcon8823
0
170
コーディング自動化の次へ。人の介入をゼロにするファクトリーとサポートAIによる実践
timakin
4
3.5k
TechTown - Creating Composable Callables in Contemporary C++
rollbear
0
130
S3 TablesのIcebergデータに、AIエージェントからアクセスしてみた / 20261016developersio2026joetsu-accessing-iceberg-in-s3tables-via-agent
kasacchiful
PRO
0
150
AWS CDKのカスタムリソースでContinuum(旧Security Agent)を実装した話 | Implementing Continuum (formerly Security Agent) via AWS CDK Custom Resource
akihisaikeda
2
150
SalesForceを内製化!? ~ HR事業を支える顧客管理基盤のインフラを大公開 ~
oku053
0
180
AIで開発が速くなった先で、開発チームは何を目指すか
shihochan
0
920
iOS 27でニュースアプリはどう変わる!? 〜日経電子版の新機能対応と、開発事例から〜
lynnswap
7
13k
Verilogで学ぶCPU自作入門
uyuki234
8
4.1k
FactoryBotをやめればRSpecは速くなるのか?
yuta_onishi_97
0
290
AIに “答え“を書かせるのを やめてみた
___akari11
0
120
Featured
See All Featured
Measuring Dark Social's Impact On Conversion and Attribution
stephenakadiri
2
310
Lessons Learnt from Crawling 1000+ Websites
charlesmeaden
PRO
1
1.6k
The untapped power of vector embeddings
frankvandijk
2
1.9k
Impact Scores and Hybrid Strategies: The future of link building
tamaranovitovic
0
460
Organizational Design Perspectives: An Ontology of Organizational Design Elements
kimpetersen
PRO
1
850
Visualization
eitanlees
153
17k
A Soul's Torment
seathinner
8
3.8k
Everyday Curiosity
cassininazir
0
350
Crafting Experiences
bethany
1
380
Navigating Algorithm Shifts & AI Overviews - #SMXNext
aleyda
1
1.7k
Leo the Paperboy
mayatellez
10
2.4k
B2B Lead Gen: Tactics, Traps & Triumph
marketingsoph
1
280
Transcript
2026年8月 一語だけ違うポリシー AWS Dogwood 入門④(全7回)── 上限が上限にならない話 赤神 青空
▪履歴が変われば、同じリクエストでも答えが変わる 前回までのおさらい 前回は参照実装のCLIで実際に判定を動かしてみました。 validate / replay / lower の3つで一周できる 履歴が変わるだけで、同じリクエストの判定が変わる
今回は、その履歴の数え方でやらかす話です 今ココ おさらい 2/9
▪sum_within 一語だけ違うポリシー の1語を response に変えただけ すでに着金した額が $5,000 を超えていたら拒む。そう読めます。一見よさそうです。 dogwood forbid
(principal, action == AgentCore::Action::"Transfer", resource) when temporal { sum_within(a, 1h, AgentCore::Action::"Transfer"::response{ input.amount: a }) > 5000 }; 今ココ 落とし穴 3/9
▪判定が起きるのは、送金を頼んだ時点 返事を待たずに投げると素通りする 上限は直近1時間で $5,000。2,000ドルの送⾦を、返事を待たずに3回頼む ← ここまでで3件とも判定ずみ。返事はまだ1件も返っていない 返事 1件⽬ 2件⽬ 3件⽬
✕ 返事 判定が起きるのは、この3か所(送⾦を頼んだ時点) 返事 sum_within( ... ::response ) ◯ sum_within( ... ::request ) 1件⽬ 合計 $0 → ALLOW 2件⽬ 合計 $0 → ALLOW 3件⽬ 合計 $0 → ALLOW 1件⽬ 合計 $2,000 → ALLOW 2件⽬ 合計 $4,000 → ALLOW 3件⽬ 合計 $6,000 → DENY 着⾦が済んだ送⾦だけを⾜す 頼んだ送⾦を全部⾜す(返事待ちも含む) 実際には $6,000 が出ていく 返事を待たずに投げれば、上限は素通りできる 3件⽬で⽌まる いま頼んでいる送⾦も、合計に⼊るため 違いは1語だけ。::response と書くか、::request と書くか 3件とも「まだ何も着金していない」状態で判定される 今ココ 落とし穴 4/9
▪判定中のリクエスト自身を数に入れるかどうか 数えるのは request 着金した分だけを数えると、着金する前に次が通ってしまいます。 response で数える 上限は「守られたことになる」だけ request で数える 返事待ちの分も合計に入る
同時に何本も飛ぶのは前提。どちらを数えるかは、そのつもりで決めます。 今ココ 落とし穴 5/9
▪同じトレースに、1語だけ違う2本を当てる 実際に replay した 1件目 2件目 3件目 4件目 結論 $2,000
$2,000 $2,000 $2,000 3件目で割れた 今ココ 落とし穴 request版 ALLOW / response版 ALLOW request版 ALLOW / response版 ALLOW request版 DENY / response版 ALLOW request版 DENY / response版 ALLOW 説明どおりに再現できた 6/9
▪同じ理由で起きる、もう一つのずれ 自分も1回と数える 集計はいま判定中のリクエストも含む。だから数が1つずれます。 つい書いてしまう 「3回まで許可」のつもりで >= 3 と 書く 実際に起きること
3回目の要求そのもので止まる 対処 しきい値の境界は replay で確かめ てから出す 返事待ちを数に入れるからこそ、境界が1つずれます。原因は同じです。 今ココ 落とし穴 7/9
▪同じトレースにしきい値だけ変えて当てる 境界を振ってみた >3 >= 3 >2 結論 4回目で DENY 3回目で
DENY 3回目で DENY 自分も1回と数える 今ココ 落とし穴 実質3回まで許可 実質2回まで許可 実質2回まで許可 境界は replay で確かめてから出す 8/9
▪この回の持ち帰り まとめ 01 数えるなら request を数える 着金した分だけ数えると、着金する前に次が通ってしまいます。 02 自分も1回と数える 「3回まで」のつもりで
>= 3 と書くと、3回目で止まります。 03 境界は replay で確かめる しきい値は机上で振ってから本番に出すのが安全です。 今ココ おわりに 9/9