Upgrade to Pro — share decks privately, control downloads, hide ads and more …

【AWS Dogwood入門】手元で動かしてみた

Sponsored · SiteGround - Reliable hosting with speed, security, and support you can count on.

【AWS Dogwood入門】手元で動かしてみた

Avatar for 赤神青空

赤神青空 PRO

August 23, 2026

Video

More Decks by 赤神青空

Other Decks in Programming

Transcript

  1. ▪Rust 1.96.1 参照実装のCLI / dogwood 1.0.0 で確認 検証 再生 変換

    生成 validate replay lower schema mcp 今ココ 手元で動かす 構文・型・スキーマを検査する 履歴を流して判定の変化を見る Cedar に落とした姿を見る tools/list からスキーマを作る 3/16
  2. ▪機密を読んだ後のメール送信を禁止する 題材:読んだ後は送るな 既定拒否かつ forbid 優先なので、全許可+例外禁止の2本立てで書けます。 dogwood // 基本すべて許可し、例外だけ禁じる permit (principal,

    action, resource); @id("no_send_after_secret_read") forbid (principal, action == Agent::Action::"SendEmail", resource) when temporal { formerly within 24h Agent::Action::"ReadDocument"::response{ input.doc: "customer-secrets" } }; 今ココ 手元で動かす 4/16
  3. ▪流したのは7イベント。判定が出るのは5行 replay の出力 頭の @ は秒、隣の time point は何番目のイベントかの通し番号です。 console

    $ dogwood replay policy.dw \ --policy-schema schema.cedarschema \ --trace trace.log @0 (time point 0): ALLOW @10 (time point 1): ALLOW [rules: 0] [rules: 0] @20 (time point 2): ALLOW @30 (time point 3): ALLOW [rules: 0] [rules: 0] @40 (time point 4): DENY [rules: 1] 今ココ 手元で動かす 5/16
  4. ▪見よう見まねで書いたら動かなかった trace が最初は通らなかった 記事で見かけた形をそのまま書いても通らず、公式 examples 準拠で2つ足しました。 イベント行に足したもの request_context(input: { ...

    }) を付ける requestId の指定 そこで学んだこと 記事の抜粋は、動くトレースの全体ではない リポジトリの examples が一番正確な仕様書になる dogwood --help の出力は最初に保存しておくとよい 今ココ 手元で動かす 7/16
  5. ▪この言語が中で何をしているか lower すると見える 書いたもの(Dogwood) 実際に評価されるもの(Cedar) forbid(..., action == "SendEmail", ...)

    when temporal { lower forbid(..., action == "SendEmail", ...) when { formerly within 24h ... context.policy_1__temporal_0 }; }; 時相条件は、ただの真偽値のフィールド1つに置き換わる イベント履歴 request / response / error セッション単位で蓄積される Dogwood がやること 履歴から真偽を計算して context に詰めて渡す Cedar が判定する 評価エンジンは元のまま ALLOW / DENY やっていることは「アプリ側で集計して context に渡す」と同じ。置き場所が移った temporal を含まないポリシーが Cedar と同じ答えになるのも、評価している主体が同じだから 時相条件は Cedar の context フィールド1つに置き換わる 今ココ 手元で動かす 8/16
  6. ▪どの記事にも書かれていない挙動 連番が何を指すか temporal 節を持つポリシーを2本書いて lower すると、こうなりました。 dogwood @id("rule_a") forbid( ...

    ) when { context.policy_0__temporal_0 }; @id("rule_b") forbid( ... ) when { context.policy_1__temporal_0 }; 命名規則そのものは公式には未確認。「lower するとこうなる」までが言えること 今ココ 手元で動かす 9/16
  7. ▪「できなかったこと」が可能になったわけではない 移ったのは置き場所 Cedar でも、履歴を自前で集計して context に渡せば判定自体はできた。 これまで 記録・集計・相関をアプリに作り込 む これから

    言語と実行基盤の側が引き受ける 効いてくるのは 条件分岐がレビューできる形になる こと 埋もれていたガードレールを、監査できるポリシーとして切り出せます。 今ココ 手元で動かす 10/16
  8. ▪validate演算子は全部通った だけを順に流した結果 OK OK OK NG NG プリミティブ3つ 標準マクロ4つ 生のMFOTL

    AWS記事の生MFOTL eventResource 今ココ 手元で動かす formerly / previous / since count / distinct / sum / bind examples 準拠の形式なら通る そのままではパースエラー AgentCore 専用のフィールド 11/16
  9. ▪参照実装とマネージドで、書ける範囲が違う 通るものと通らないもの ◯ 参照実装で通る プリミティブ3つと標準マクロ4つ examples 準拠の生MFOTL schema mcp のスキーマ

    素のCedar条件との混在 ✕ AgentCore 側の書式 eventResource フィールド AWSの記事のままの生MFOTL AgentCore::Action:: の名前空間 7つの型は手元では動かない 記事のコードを写して動かないとき、まず疑うのはどちら向けの例か。 今ココ 手元で動かす 12/16
  10. ▪同じ流れで、読み取りの結末だけを変えた error は response ではない 成功 失敗 無害 含意 読み取りが

    response 読み取りが error 公開文書を読んだだけ DENY と error は別物 今ココ 手元で動かす 後続の送信は DENY 後続の送信は ALLOW 後続の送信は ALLOW DENY は request に付く判定 13/16
  11. ▪実サーバーなし。JSON MCPマニフェストから 1つで一周できた 生成 検証 再生 含意 schema mcp validate

    replay 手前で試せる 今ココ 手元で動かす Drupe::Action::"print_label" ができた そのまま通った 3回まで ALLOW、4回目で DENY ツール定義があれば書き始められる 15/16
  12. ▪この回の持ち帰り まとめ 01 AWSアカウントは要らない cargo build して CLI を叩くだけで、判定の変化まで見られます。 02

    lower すると正体が見える 時相条件は Cedar の context フィールド1つに置き換わっていました。 03 参照実装とマネージドは書式が違う eventResource など、AgentCore 側にしかない記法があります。 今ココ おわりに 16/16