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
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
赤神青空
PRO
August 23, 2026
Video
Programming
32
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 赤神青空
【AWSのログ周りを整理する】第6回 選び方 ── 結局ど う決めるのか
akagami
PRO
0
6
【AWSのログ周りを整理する】第5回 調べる ── 貯めたログに問い合わせる
akagami
PRO
0
14
【AWSのログ周りを整理する】第4回 貯める ── コストの大半はここで 決まる
akagami
PRO
0
14
【AWSのログ周りを整理する】第3回 運ぶ ── 発生源と置き場のあいだ
akagami
PRO
0
11
【AWSのログ周りを整理する】第2回 出す ── ログはどこで生まれるか
akagami
PRO
0
19
【AWSのログ周りを整理する】全体像 ── 4段に分けて 位置づける
akagami
PRO
0
21
【ORM不要論の歴史】で、AIは新しい根拠なのか
akagami
PRO
0
32
【ORM不要論の歴史】反論と、噛み合わなさの正体
akagami
PRO
0
44
【ORM不要論の歴史】2026年の不要論は何を言っているのか
akagami
PRO
0
34
Other Decks in Programming
See All in Programming
テストを司るデーモンに会いに行く 〜隔離した仮想マシンでテストを通すまで〜
h1d3mun3
1
430
WebMCP Challenge に星空観察アプリで参加した話
okajun35
0
180
マイコン向けの軽量Ruby「PicoRuby」で各種デバイスを制御するネイティブアプリの実現手法
bash0c7
0
410
新卒PdEのリアル
ryu1013
1
500
AIエージェント時代のコードレビューを設計する
nogu66
6
2.7k
wkhtmltopdfの次どうするか問題2026
willnet
2
1.2k
LL言語やWebフレームワークのPostgreSQL対応 〜DBの機能がユーザーに届くまで〜
kentaroutakeda
1
150
『寄り添うラジオ』をAIで作る 体験価値から逆算した、会話しないUXと品質設計
theoriatec2024
3
180
すこし踏み込む CancellationToken
htkym
0
300
速習iPhone Duo対応
yuukiw00w
1
520
技術的負債の返済は、AI時代の複利で効く投資 — 経営としての意思決定とその遂行
curekoshimizu
0
1.4k
AWS DevOps Agentで インシデント対応をAIに任せたい
honmarkhunt
7
3k
Featured
See All Featured
Everyday Curiosity
cassininazir
0
320
Building a A Zero-Code AI SEO Workflow
portentint
PRO
0
720
The Pragmatic Product Professional
lauravandoore
37
7.4k
The browser strikes back
jonoalderson
0
1.7k
We Are The Robots
honzajavorek
0
380
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
10
1.3k
Code Review Best Practice
trishagee
74
20k
Skip the Path - Find Your Career Trail
mkilby
1
230
Bootstrapping a Software Product
garrettdimon
PRO
306
120k
Why Mistakes Are the Best Teachers: Turning Failure into a Pathway for Growth
auna
0
290
[SF Ruby Conf 2025] Rails X
palkan
3
1.4k
Applied NLP in the Age of Generative AI
inesmontani
PRO
4
2.5k
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